Why the future of the web is real-time (6 months w/ Meteor)

When Meteor was first announced in April 2012, the announcement’s Hacker News thread quickly rose to the first spot on the homepage and remained there for a good while.

It ended up being one of the site’s most popular posts ever, gathering more than 1300 points. For those unfamiliar with Hacker News, you can usually count yourself lucky if your link gets more than 20 points with this hyper-critical audience. Of course, virtual points are no guarantee of real-world success, but this at least illustrates Meteor’s, ahem, meteoric rise to fame.

So one year later, what’s the verdict? Was there any substance behind all that hype? Since I’ve been using Meteor for the last 6 months (I released Telescope, one of the main Meteor open-source apps), I thought I’d take a moment to share my impressions.

First of all, a disclaimer: while I code with Meteor every day, most of my time is spend making Telescope more usable rather than digging deeper into Meteor’s guts. So I don’t pretend to be an expert on the underpinnings of the framework, and this overview will probably reflect that. But then again, I believe this also shows how effective Meteor can be even if you don’t master all of its intricacies.

A Smarter, Simpler Framework

If you’ve heard about Meteor at all, it was probably in the context of real-time web apps. But even though real-time is what Meteor is best known for, it’s far from its only advantage. When you first start using Meteor, the first thing you’ll notice is how it wants to make your life easier.

Installing Meteor only requires a single command line, and so does creating your first app.

Even deploying is made easy, thanks to Meteor providing you with free hosting so you can quickly push your experiments online.

Other small touches contribute to making getting up and running faster: for example, any JavaScript or CSS file included in your project directory will automatically get loaded, and Meteor also provides you with built-in user management, complete with a drop-in UI widget.

The Future is Real-Time

Of course, real-time is the framework’s big selling point. But while “real-time web-app” calls to mind images of multiplayer games and live collaborative document editing, using Meteor I quickly realized that real-time also had much more pragmatic applications, and in fact could very well become the default way we build web apps within a couple years.

To give you an example, think about the way your desktop file system works. If you open the same directory in two windows and delete a file in one of them, you’ll see the file disappear from the other one as well, without the need to “refresh” it.

In the context of the desktop, we don’t think of this as “real-time”. Yet it’s exactly the kind of interaction that frameworks like Meteor are making trivial to implement on the web as well.

Thinking in real time also influences your coding style. You no longer need page refreshes or specific callback logic to make your app react to changes: every single piece of data is now automatically monitored for you, and any UI element that depends on that data will be affected accordingly.

Here’s how this principle (known as reactivity) translates in practice. In this case we want to give a “disabled” class to an upvote button once somebody has voted:

Here is the template code (Meteor uses Handlebars):

<div class="post">
  <a href="#" class="upvote btn {{upvotedClass}}">⬆<a />
  <h3><a href="{{url}}">{{title}}</a></h3>
</div>

And here is the matching controller code:

Template.post.helpers({
  upvotedClass: function() {
    // test if user is logged in, and if their userId 
    // is included in the 'upvoters' array
    var userId = Meteor.userId();
    if (userId && !_.include(this.upvoters, userId)) {
      return 'upvoteable';
    } else {
      return 'disabled'
    }
  }
});

The beauty of this approach is that if the user’s userId is removed from the upvoters array for any reason (for example, we implement a “cancel upvote” button somewhere else), the change will automatically be reflected in the UI without writing any additional code!

Is it production-ready?

By now, you’re probably thinking something along the lines of “OK, this looks awesome, but can it be used for real-world apps?”.

The answer, as always, is “it depends”. Meteor can certainly be used for real-world apps. Telescope and Sidebar (which is based on Telescope) are perfect examples of it.

But Meteor can’t be used for all real-world apps just yet. Meteor doesn’t have server-side rendering yet, so it’s not ideal for sites that need to load very fast (like e-commerce sites) or work on underpowered devices (like older mobile phones).

Meteor obviously also has a lot more moving parts than static HTML templates. So there are more points of failure and more uncertainties, although the Meteor team generally does a good job of addressing any problem that crops up.

So I would say right now Meteor will be a perfect choice for a few apps (anything that strongly depends on real-time interactions), a great choice for most of them, and a very bad one for a few specific cases.

But the good thing is that since getting started with Meteor is so easy, you should be able to know pretty quickly in which bucket you fall.

The Meteor Book

Of course, I’m not totally impartial in all this. Along with Tom Coleman (one of the main contributors to the Meteor open-source ecosystem and creator of Meteor package manager Meteorite), I’m currently working on The Meteor Book, a book that will teach you the fundamentals of getting an app up and running with Meteor.

The book is not quite ready, but we’re regularly publishing tutorials and articles on the site, so go check it out and let us know what you think!

---

Discuss at Hacker News