Summary: Meteor is an incredibly accessible web framework for beginners. Its ease of setup, deployment, and Javascript-only configuration are game changers compared with competing frameworks like Django or Ruby on Rails that require learning an additional programming language, more complex setup, and much more complex deployment. Over the month of January we were able to teach undergrads everything from HTML and CSS to Meteor and Github. Motivated students without prior web experience can make huge strides in a short period of time.

CSCI16 - Web Development with Meteor

Ben Cohen and I recently finished co-teaching a month-long class, at Williams College on web development with Meteor. Of the 18 students, only half had previous programming experience and only 2 had built any kind of website before. Our curriculum therefore focused on bringing beginners quickly up to speed with HTML, CSS, Javascript, the command line, and Meteor. Along the way we also introduced git and Github, which the students used in their final group projects, Bootstrap, and basic SEO. It was a lot of material for 8 2-hour sessions but we were blown away by how quickly our students picked things up. And crucially, how Meteor facilitated all of this.

Why Meteor

Ben and I have been using Meteor professionally for over a year. After meeting at a nearby co-working space, Cloud85, we quickly decided to join forces to create an app that addressed a pressing local need: simple online signups and payments for small businesses. We called it SimpleSignup. Ben came from a Ruby on Rails background and I had most recently been working with Django. Because we wanted to quickly prototype the app—and neither of us really wanted to do a deep dive into Rails or Django at the time—we decided to try Meteor. Very quickly we were hooked by the speed with which we could MVP our product.

When the opportunity arose to teach a class on web development at Williams College, Meteor was our first choice. It provides several major advantages over competing frameworks that makes it a great fit for teaching beginners:

1) Javascript only so we wouldn’t have to also introduce Python or Ruby

2) Local development setup, including the database, is done with one command line instruction. curl https://install.meteor.com/ | sh That’s it!

3) MongoDB means students don’t have to learn, yet, about schema, migrations and the like

4) Free one-line deployment to Meteor’s hosted servers (EDIT: as of March 2016 Meteor has eliminated their free hosting tier in favor of Galaxy)

These assumptions proved true in practice. Within one hour our students—again, largely total beginners—had installed Meteor, modified the default website, and deployed to their own custom, Meteor-hosted URL. Pretty amazing!

Class Structure

During the class we mixed short lectures with frequent, interactive projects. This was important since we figured the students’ attention span would drift off after about 15 minutes. And given we were introducing so much new, technical information, we wanted to make sure the students stayed engaged and worked alongside us on the exercises.

Having two instructors also turned out to be crucial. While one of us spoke up front, the other roamed the class and could respond to individual students who had a specific question or problem. Since we worked through many exercises as a group, this helped the students not fall behind and, if they had an interesting programming issue, we’d pause and talk it through with the whole class.

Class 1 - HTML

We started off by showing the students about View Source and then played around with Inspect Element so they could modify an existing webpage. This was a big hit and an easy way to demonstrate HTML and CSS. It’s easy to forget how cool this is for beginners.

Next we discussed the Front-End vs the Back-End, since it’s a core part of web development and also not intuitive for beginners. Finally we dove into HTML itself, talking through the basics and having students work through examples on their own in JSBin.

For the second hour of class students downloaded Atom and created a webpage in HTML. To open the HTML file in a browser, we had them simply save the file to their desktop and then double-click on it, which opened in their default web browser. There was an audible “a-ha” from many students when this happened and reinforced our feeling that it was important to use a real text editor and web browser right away.

While working in JSBin gives quicker feedback, it doesn’t feel as tangible and real to students as turning text editor code into a live webpage. This, by the way, is a common complaint we heard about interactive sites like Codecademy. One student had worked through the entire Codecademy Javascript course but became lost when it came time to use an actual text editor and web browser.

After the initial rush of seeing their code on a web page, the students quickly became familiar with the standard web development flow of coding, saving the file, and refreshing the web browser. (Fun fact: Meteor does live reloads, so students only spent a few classes having to save/reload manually like this.)

We ended class with some fun slides discussing what to do when they became stuck on a coding issue. The mindset of a developer is not the same as the mindset of undergrdas at a liberal arts college, so we wanted to have the students become comfortable with making mistakes, being clueless, and using Google and other resources for help.

For homework students created their resume in HTML, with the promise that we would show them how to put it online and style it better with CSS in class 2.

Class 2 - CSS & Introduction to Meteor

We covered a ton of material in this class. Looking back on it, I’m surprised we accomplished so much in just 2 hours. To begin, we showed the students the sample resume we were going to build in class thanks to CSS and custom fonts. Since students already knew about View Source, they could go and find the complete code for this file to double-check their work at any point.

We dove into an Overview of CSS and CSS Colors and ran through group exercises first in JSBIN and then with Atom/Chrome. Generally this involved asking them to make specific changes: increase the font size here, change the color there. We were able to talk about CSS Class and ID selectors as well, though it’s frustrating that IDs work just the same as Classes in CSS. We had to tell the students to just trust us on this until we started implementing Javascript for the Class vs ID distinction to be actionable.

Going over Google Fonts was a big hit. Students immediately understood why it was beneficial, how to do it, and had a lot of fun on their own tweaking fonts. When it came time for group projects later in the course, the less-technically-savvy members of the group did fantastic work updating the CSS and fonts, while other members dove into Javascript and Meteor internals.

The final CSS/Google fonts exercise we built with students was to update their resume from the homework to look more like the initial sample resume.

In the second hour we showed students How to Create a Google Analytics Account and demonstrated live Analytics for a site with real traffic. It was definitely creepy/cool for the students to see the data that’s available out of the box with Google Analytics, especially location mapping, search queries, browser/device versions, and content drill downs.

Next we wanted to install Meteor. But to install Meteor you must use the command line, which is a full-stop barrier for most beginners. On the official Meteor site there are good installation instructions and tutorials, but they are designed for developers already familiar with web development and the command line. This probably makes sense given that Meteor sees itself as a cutting-edge platform for professionals, but it’s a lost opportunity, in our view, to make Meteor more accessible to first-timers.

In any event, we covered the Command Line with slides and interactive exercises. We had the students create, via the command line, a “code” folder on their desktop for all their work so far, mainly just HTML/CSS files. The most common confusion for students was getting lost in the directory structure. So sometimes when they tried to run Meteor locally, which requires typing meteor it wouldn’t work because they were up/down a level. It really is a mind-bender the first time you think of your computer in terms of directories and not a mouse-driven GUI.

But with the command line covered, we were on to Installing Meteor, which is just a simple one line example. Meteor helpfully installed a demo app and so students could run Meteor locally and interact with it in their browser. Then we played around with modifying the default html/css code a bit. And finally students replaced the default code with their existing online resumes from homework the night before. We added in a custom Google Analytics tag for each student and deployed with Meteor’s one-line deployment to their hosted servers.

Over the weekend students could both share their work with friends/family/fellow students, they could track it too! This built up a lot of excitement and enthusiasm for class 3 the following week.

Classes 3 & 4 - Introduction to Javascript & Meteor

We started doing “real” coding, introducing Javascript and going through the now-familiar flow of JSBin exercises and then Atom/Chrome work. While we did Introduce Javascript Concepts there was a lot of handholding here as we didn’t have the time to dive deeply into Javascript. The good news is that Javascript is intuitive enough that students could follow along with the simple examples we covered.

Then we dove into the Creating a Meteor Guestbook example together. This gave us the chance to cover forms, templates, events, collections, publications, and subscriptions. Heady stuff! This ended up taking the rest of class 3 and all of class 4. You can see the 59(!) slides here.

I’m sure the students didn’t fully grasp all of these concepts on this first go round, but they live coded along with us and got things to work. The slides and code were online so they could review on their own after. And, since there were two teachers, while one us was upfront live coding and explaining the other could roam the class and help students who became stuck.

If there were only one of us, this amount of material might have been too much. But students plugged along and asked questions when needed. Before this session of classes we had considered doing more of the same structure for future classes on Meteor concepts: lectures, interactive exercises, small projects. However the enthusiasm and aptitude students showed convinced us to let them start the following week on group projects and we would work in additional materials as needed. Again, with two instructors, we could provide adequate one-on-one help to the groups as they started working on their ideas during class time.

Class 5 - Git, CSS Preprocessors

As students started more complex projects, we needed to introduce git and Github. We had many internal discussions around if we even wanted to get into this; certainly git is essential to professional developers, but it can be confusing and deep waters for beginners. If we had stuck to individual projects, we likely would not have tackled git. But for group projects, we felt it was essential and so we dove in.

The Intro to Git lecture went down smoothly and students were able to use it themselves and create/connect to Github. In hindsight, we should have done more here since we didn’t really cover git in groups, how to do git merges, adding permissions on Github, and other topics that came up quickly.

Next we covered CSS Preprocessors, specifically SCSS, and showed how using variables saves a lot of time in CSS by using a simple example its colors. Meteor packages are easy to install, so the exercise went well. However finding Meteor third party packages is not a highlight of the framework. To do so you must use Atmospherejs.com which is not a great experience: it’s hard to navigate, has no search filters, and it’s a mixed bag what you get as a result. For example, when you search for “bootstrap” there are, as of this writing, 523 results and no easy way to discern the proper package. Meteor Development Group does maintain a small number of official packages that are guaranteed to be up-to-date, but for most packages there is little documentation and the process is poor. In general, we advised the students to use Google when looking for 3rd party packages by Googling something like “bootstrap atmospherejs” which would usually return the top result.

In the second half of the class students divided into groups and began brainstorming and sketching out projects for the final week and a half of the class. Their homework was to work on these further.

Class 6 - Responsive Design & Routing

In hindsight, we covered Responsive Design too quickly. The concepts made sense to students, but media queries, breakpoints, and thinking in pixels is a lot to digest the first time around. To throw in Bootstrap on top of that was probably too much. It would have been better if we devoted a full class to all of this rather than only 30 minutes. Our thought was that we could show students how if only they used containers, rows, and columns, they could quickly achieve responsive sites. And then we highlighted some Bootstrap navbar examples. But it was too much and students had to piece a lot of this together on their own time.

The Introduction to Routing was more successful. We decided to use IronRouter and not tackle FlowRouter or the debates in the current Meteor community around what routing package to use. This is another aspect of Meteor that could be improved; routing should be a core part of the framework, not a third party package.

On a related note, we had students just use Meteor’s built-in tempting engine, Blaze. For homework some of the CS students worked through Meteor’s To-Do list app in React, but we left React out of the classroom discussion. If we teach this class a year from now, we may have to tackle React as Meteor has signaled its intent to move away from Blaze permanently. While we understand Meteor must listen to its core users, this is disappointing to us as Blaze+Spacebars is fantastic as a simple templating solution and much more accessible to beginners than React.

Students were tasked with making their projects responsive, which again provided a nice way for the less-technically savvy to get involved by installing and updating the design. At this point most groups had divided duties pretty well amongst front and back end code.

The rest of the class students worked on projects and we went around helping them debug issues. In general we avoided giving straight answers, instead talking them through how to solve issues, usually by using Google, experimenting themselves, and only helping them with actual code when they appeared truly on the wrong track.

Class 7 & 8 - Hosting Options and Group Presentations

The last two classes were primarily in-class coding sessions where Ben and I would help groups with their coding and product issues. It turned out that students were primarily interested in ride-sharing or music-sharing apps! There were two students groups on each project. Login for all projects is restricted to Williams students only, but you can see screenshots of the apps below.

Conch (YouTube-powered collaborative music app)

Herd (short distance ride sharing app)

PartyUp (Spotify-powered collaborative music app)

ClunkerU (longer distance ride sharing app)