Meteor - An Exciting Development

If you haven't seen the Hacker News post about Meteor being funded $9M this month, then let me tell you a little about this framework since it is the first web-framework I have been excited to use in practice in a long time.

Rapidly develop Web-Applications

The premise is quite simple -

• A pub/sub model
• A (locally cached) DB API from the client
• Template data-dependency driven updates

But what does that mean in practice?

• Create Collection Objects (Mongo Tables) on your Server and Client
• Create event hooks in your client code that update your DB and your Session appropriately
• Define templates that render your objects (and others to render the page-chrome)
• Create dynamic subscriptions to data
• Create parameterised data publications on your server

That's about it for a basic app. I have created a small example app at mathfriends.meteor.com.

So what do each of these practical steps involve?

The MathFriends Example App

"Create Collection Objects (Mongo Tables) on your Server and Client"

This is achieved by using the Meteor API to create new Collection objects:

Defining 'Snippets' and 'Users' Collections

"Create event hooks in your client code that update your DB and your Session appropriately"

This involves listening for an event and updating your DB or Session accordingly. Logging out the current user is as easy as you might expect:

Listen for a 'logout' click - Set the user to null.

"Define templates that render your objects (and others to render the page-chrome)"

The templating engine used by default is Handlebars. The variable scope is determined by the data collections being looped over, and the functions bound to that template in your client-side js:

Showing the list of MathFriends users.

"Create dynamic subscriptions to data"

Subscriptions to data-sources can be handled manually, however, Meteor provides a way to automatically update the subscription when the dependencies change:

Adding a dynamic data-subscription.

"Create parameterised data publications on your server"

Every subscription references a corresponding publication. These may be parameterised arbitrarily:

Creating a data-publication parameterised by the currently selected user.

What does this buy us?

It means that when your data-store is updated, the changes are propagated to the clients and re-rendered automatically. Thanks to a local-cached subset of the data-store, interface affecting changes are re-rendered instantly on the client that made them.

Does this mean that your entire page is rendered every time you make a small change? No.

The changes are diffed against the dom and spliced in without updating large sections of the page unnecessarily.

Quite amazing.

There are currently a couple of major caveats, but the main one is:

• Auth is a work in progress

This is currently being addressed in the auth branch on Github.

If you would like to take a look at the example site I was demonstrating, it is also available on Github.