Meteor for Front-End Engineers

By  on  

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 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 | /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.

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 build throughout our book, Discover Meteor.

<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!

Get Discover Meteor 20% Off

Discover Meteor

If you're not sure where to get started, our book Discover Meteor can be a great way to quickly get up to speed.

In it, you'll learn how to build a real-world, functional web app, including topics such as:

  • How to set up user accounts.
  • How to set up routing to different templates.
  • How to manage various data collections.
  • How to handle permissions and errors.
  • How to animate elements in real-time.
  • And much more…

What's more, if you use this special URL you'll automatically get 20% off at checkout!

Sacha Greif

About Sacha Greif

Sacha Greif is a designer/coder/author currently living in Osaka, Japan. He's the creator of Telescope, a Meteor open-source social news app, and Sidebar, a newsletter of the 5 best design links of the day (which is based on Telescope). He recently co-wrote Discover Meteor, a book that teaches you how to build real-time JavaScript web-apps with Meteor from scratch.

Recent Features

Incredible Demos


  1. I’ve never used Node or any other unified front-end/back-end setups, so bear with me…but is it confusing to maintain the mental separation between the two? For example, since the front-end code can be manipulated by the user, there are certain operations that you never want to do client-side, such as form validation. Seems like it could get confusing if both sides of the app we’re in the same language.

  2. @njbair it’s definitely something you need to get used to. But it does provide a lot of advantages.

    For example, say that you need to check if a user can perform a specific action like editing a post. With Meteor, you can call the same exact “canEdit()” function from both the client and the server, so it saves you from wasting time on duplicating features.

  3. A bit offtop, but am I the only person who is “a little” worried of `curl | /bin/sh` -alike things trend?

  4. @Sacha Greif, canEdit() will be executed on server side both times? Because we can’t trust any front-side checks of permissions.
    Also I’m worried about lock to certain DB and certain backend language (and not the best programming language in the world).

  5. To give you an example, you could call the canEdit() function client-side to show or hide an “edit post” link, and call it server-side to actually validate the edit operation. In this scenario, it doesn’t matter if the client-side call is not secure since it only affects the UI.

    The lock to MongoDB is a problem, but more DBs are on the way (MySQL and Redis I think). And if you’re not a fan of JavaScript, well, I have to concede Meteor is probably not for you then :)

  6. Sumit

    i’d love to try it out but it’s just plain stupid that there is no Windows support. I mean… seriously..?

  7. There is unofficial support for windows, at least:

  8. Another win user here … since the NodeJS runs cross-platform, I don’t really get why Meteor does not (by default). I hope this changes soon…

    I have my ‘unofficial Win’ installed now, it it seems to work good so far (at least better than the version I installed 4 or 5 months ago), let’s see how far I can go with it …

  9. Great article……..

    Thanks for posting

  10. Peter

    What about ssl or security issues?

    You know, data going back and forth server/client client/server.

    Or is that just standard. I am concerned about about really sensitive date like SIN numbers, Bank accounts etc

  11. Vic

    Meteor is a back end.

  12. I want to build a mobile app with meteor – are there are any frontend UI frameworks/libraries that you would recommend? Something that would make the app feel native, or take care of some common UI practices used in mobile apps (a bootstrap for mobile :) ).

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!