Why I’m Sold on Meteor and Node.js
It has been almost two weeks since my last blog post. During this time, I’ve been working hands-on with Meteor, Node.js, MongoDB and Twitter’s Bootstrap framework. One of my main objectives was to find gotchas that might disqualify Meteor as a viable solution for upcoming projects.
During this time, I spent quite a bit of time working with HTML5 and CSS3 in the context of Bootstrap. Meteor, Node.js and MongoDB are so expeditious at dealing with the core issues such as data storage and retrieval that a larger percentage of time can be spent working on aesthetics, for example a responsive layout that works equally well on both hand-held and desktop clients, and also ensure that the application simply looks good and professional.
This book helped me resolve a key mystery about Meteor, namely how the system determines which templates need to be refreshed when back-end data changes. Now that I understand it, I have to say that it is awesome, but please bear with me because you’ll need a little background to understand.
A meteor application is comprised of two “things” that must be developed in tandem:
1. Templates, which are HTML plus special Handlebars tags.
Meteor getter functions, particularly those that involve retrieval of MongoDB data, will automatically add Dependency instances to the current Computation. These Dependency instances are listeners for any changes in the underlying data source, and each Dependency knows the set of Computations that might be affected my underlying data changes.
Since the relationship between Dependency and Computation is many-to-many, a given Dependency knows the set of all Computations (and associated templates) that should be re-rendered if the underlying data changes. With the help of Websockets, Meteor listens to data state changes, and selectively re-renders only the affected templates. This is in contrast to standard JSP, ASP or PHP where the entire page would have to be refreshed on demand by the user, or via AJAX and jQuery calls to patch HTML after the initial rendering, requiring two separate code paths that do essentially the same thing.
Meteor unifies the code paths: the same code that handles the initial rendering handles dynamic refresh, so making a real-time web application carries no additional cost. Since real-time behaviors are inexpensive, you’ll see them more and more frequently, and static approaches such as JSP will seem clunky and “legacy” by comparison.
I’m particularly excited about the possibilities using Meteor together with HTML5/CSS3 animations, Google Charts and RIA frameworks such as Sencha ExtJS. Consider these possibilities:
1. Smooth-scrolling tables of data that dynamically roll as data is added similar to the ending credits of a movie
2. Google Charts that dynamically update as data is changing
3. Table and tree controls that are dynamically updated as user collaborate on a shared data model
Such reactive behaviors will likely become hallmarks of modern web apps. Start-ups can take advantage of these technologies to differentiate themselves from well-established competitors, at least in the near term.
So, if Grails is a carrier battle group, and Ruby on Rails is a rickety pirate ship, I would say that Meteor/Node.js are the Oracle catamaran: minimal, streamlined, modern and super fast to develop.