(Note: this blog post originally appeared on David Walsh’s blog)

As part of my daily web browsing routine, I follow a number of front-end blogs. I’m always amazed at how far good front-end engineers can push JavaScript and CSS, and how well they are able to master the intricacies of web browsers.

Yet I also can’t help but notice that a lot of front-end developers seem to limit themselves to, well, the front-end.

Front to Back

On one hand this makes sense. With new JavaScript frameworks and browser versions popping up every day, client-side development already offers more than enough to keep you occupied for a lifetime.

Yet the fact remains that it’s often hard to build functional web apps without involving a back-end environment at some point, if only to communicate with a database.

Up to now, adding a back-end to your app meant learning a back-end language such as Ruby, Python, or PHP. And that new environment came with its own set of patterns and quirks that had to be learnt from scratch.

But things are changing. Node.js introduced JavaScript on the server, and for the first time developers could code their whole app in a single language.


Meanwhile, backend-as-a-service offerings like Parse and Firebase now make it possible to add persistent data to an app with little more than a few lines of JavaScript.

But to day I’d like to talk about yet a third approach: Meteor, an up-and-coming JavaScript framework that bridges the gap between client and server.


I discovered Meteor about one year ago, and quickly fell in love. I went on to build a popular open-source app with it, used that app to power a very successful project of mine, and even ended up writing a book about it!

Meteor might still be quite new, but I think a lot of front-end engineers and designers would quickly fall in love with Meteor if given the chance.

So here’s a quick introduction to Meteor written for people who already live and breathe JavaScript in the browser, but haven’t yet crossed over to the “dark side” of server-side JavaScript.


Let’s start with the basics: Meteor is a JavaScript framework based on Node.js. Unlike most other JS frameworks, Meteor runs both on the server and the client, meaning you can manage your whole app with a single code base, and that both parts can seamlessly talk to each other.

Meteor’s other selling point is that it’s fully reactive and real-time, meaning that any data change on the server will get immediately reflected on the client, without any extra work on your part.

In practice, this means you can build single-page JavaScript appextremely fast, since most of the server-client plumbing will be taken care of for you.

You Already Know Most Of It

The reason why I think Meteor is a great match for front-end engineers is that the typical JS coder will already be familiar with a decent chunk of a Meteor app’s code, even if they’ve never laid eyes on the Meteor documentation before.

Of course, the fact that Meteor uses JavaScript everywhere is a big help: unlike with Rails or Django, you won’t have to learn a new programming language. What’s more, Meteor also makes use of all the libraries you’re already familiar with (jQuery, Underscore, Handlebars), and they even come included by default with every new Meteor app (although you’re also free to replace them with your favorite alternatives).

So instead of learning new patterns from scratch, you can simply jump in and put your existing JavaScript knowledge to good use right away.

Simple Setup

One of the big obstacles to crossing the client/server chasm is the need to set up a local development environment. After all, all you really need to handle client-side code is a web browser, and maybe a local instance of Apache if you really want to get fancy.

On the other hand, setting up most full-stack environments require installing new languages, frameworks, modules, and probably version managers as well.

The good news is that Meteor bundles all of that stuff in a single-command super easy install. Just type:

curl https://install.meteor.com | /bin/sh

And you’ll be good to go. So if you can open a terminal window, you can probably install Meteor.

Collections and Reactivity

So if you’re already familiar with JavaScript and setup is so simple, what do you actually need to learn to build a Meteor app?

For me, the two key concepts to understand when starting out with Meteor are Collections and Reactivity.

Collections are the MongoDB equivalent of SQL tables, i.e. a way to group similar data together. Meteor exposes a powerful API to publish and subscribe to these collections, and this API lets you control which subset of your data to make available to the browser.

For security as well as performance reasons, you probably don’t want to send your whole database over to every client! So mastering collections is one of the first steps to building robust Meteor apps.

Diagram taken from the “Publications and Subscriptions” chapter

The other key Meteor concept is Reactivity. Simply put, any change to a reactive data source will be immediately reflected anywhere this data source is used in the app. These data sources include not only the data stored in your database, but also things like Session variables or routing filters. What’s more, you can also make any variable of your choosing reactive.

Reactivity is extremely powerful, and also a little magic. And like most magic, it can sometimes have unintended side effects if you’re not careful. So there’s a bit of a learning curve there, but after mastering these concepts you’ll quickly see the rest of the framework fall into place.

An Example

Now that you know what Meteor is all about, let’s take a look at a quick example of Meteor code.

Here’s the code for two of Microscope’s templates (in this case, for user notifications).

Note: in case you’re wondering, Microscope is the example social news app that you’ll build throughout our book.

<template name="notifications">
  <ul class="notification">
    {{#if notificationCount}}
      {{#each notifications}}
        {{> notification}}
      <li><span>No Notifications</span></li>
<template name="notification">
    <a href="{{postPagePath postId}}">
      <strong>{{commenterName}}</strong> commented on your post

And here’s the accompanying JavaScript code that powers these templates:

  notifications: function() {
    return Notifications.find({userId: Meteor.userId(), read: false});
  notificationCount: function(){
    return Notifications.find({userId: Meteor.userId(), read: false}).count();

  'click a': function() {
    Notifications.update(this._id, {$set: {read: true}});

I’m willing to bet you can already get an idea of what this code does, without having ever laid eyes on a Meteor app before.

The first code sample contains two handlebars templates. The first notifications template iterates over the notifications, including the notification for each iteration.

The JavaScript code can then simply fill in the blank, by defining the object to be iterated on. In this case, return Notifications.find({userId: Meteor.userId(), read: false}); simply means “return all unread notifications for the current user”.

And of course, this is all reactive, meaning that your list of notifications will be automatically updated as soon as the underlying data changes!

If you’d like to learn more, checkout this quick introduction to Meteor templates.

Why Not Give It A Try?

Now I don’t want to make it sound like learning Meteor is a trivial undertaking. It’s a new framework that introduces many powerful concepts, and like every new technology it has a learning curve.

But it’s not a coincidence is Meteor is getting picked up more and more in hackathons and in education settings: it provides a low-friction environment that makes it easy to get started.

So if you have an hour or two ahead of you, I’d suggest you give it a try. After all, if you’re looking to learn a server-side development environment, you could do worse that pick one where you’ll have a big head start!