Here are the slides from my JS.Chi() talk on Meteor. I will follow up with posts expanding on most of the slides in the presentation. This post, however, is for the benefit of all those who are feeling like they might be missing a step with frameworks like Backbone, Ember, (and now Meteor), et. al. It is an overview of the types of problems they’re solving and includes recommendations for further reading.
First a brief note about MVC
The Model-View-Controller application architecture (MVC) is used in most modern applications to separate an application’s data from its business rules and user interface. Briefly, Models represent an application’s data and functions to access it. Views represent information presented to the user. Controllers represent intermediary resources required to generate Views. The MVC pattern isn’t new (it can be traced back to Smalltalk), but it was popularized , along with the REST style of client-server API design, by server-side web frameworks such as Rails and Django.
If you think of the screens – or pages – in your application as different “states” in your application, server-side frameworks require a round trip back to the server when the user goes from one application state to another. This is fine for content-heavy apps or websites. Or if you’re accessing the pages via an ethernet cable or 802.11. But when you move to high latency connections and along the continuum — and I believe it really is a continuum — from a web site to a web app, you can deliver a much better user experience if you avoid the server round trip for each state change, and instead switch from state to state on the client, within a single browser page load cycle.
You would still need a server to authenticate users and perform other privileged operations, and to store the “official” version of the data that different clients synchronize with, but instead of sending dynamically created HTML to the client (a la aforementioned server-side frameworks) the server would send as much data as needed (typically as JSON) to the client, and the client would create all of the different application states dynamically. The problem with this approach — and I’ve been writing apps this way since 2008, without the benefit of any client side frameworks — is that they quickly turn into a mass of spaghetti code.
Addy Osmani’s articles, and especially his Backbone Fundamentals book are a great place to start reading more about this. Although it’s focused on one specific framework (Backbone), it has a good overview of MVC and how the pattern has moved from server side frameworks (like Rails, Django) to the client side (Backbone, et. al.).
And this is a useful comparison of various front-end frameworks, although the conclusions should be taken with a grain of salt (it’s one persons’s perspective, and things are not quite as quantifiable as the article suggests).
So, all of these are client side frameworks, which solve the problems of a) separating client side code into MVC, and b) optionally, allowing views to “observe” client side models, so that views get updated automatically as the data in the models is updated or as new data arrives from the server.
This gets you pretty far, but all of these applications have something else in common which the previously mentioned MVC frameworks don’t address: They need to send data back to the server and know if data has changed on the server. In other words, they need to synchronize client side models with the server side models.
For more on the problems Meteor solves, read the meteor docs from the intro section through to as many of the detailed concepts you’re interested in. Or come to my talk at JS.Chi() and we will work through it together.