{"id":2725,"date":"2013-09-30T02:51:43","date_gmt":"2013-09-30T02:51:43","guid":{"rendered":"http:\/\/13.52.125.237\/?p=2725"},"modified":"2014-09-18T16:26:16","modified_gmt":"2014-09-18T16:26:16","slug":"why-im-sold-on-meteor-and-node-js","status":"publish","type":"post","link":"https:\/\/sotaenterprises.com\/?p=2725","title":{"rendered":"Why I’m Sold on Meteor and Node.js"},"content":{"rendered":"

It has been almost two weeks since my last blog post. \u00a0During this time, I’ve been working hands-on with Meteor, Node.js, MongoDB and Twitter’s Bootstrap framework. \u00a0One of my main objectives was to find gotchas that might disqualify Meteor as a viable solution for upcoming projects.<\/p>\n

During this time, I spent quite a bit of time working with HTML5 and CSS3 in the context of Bootstrap. \u00a0Meteor, \u00a0Node.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.<\/p>\n

I broke down and purchased the fine book Discover Meteor: Building Real-Time JavaScript Web Apps:<\/em><\/p>\n

\"Meteor\"<\/a><\/p>\n

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. \u00a0Now 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.<\/p>\n

A meteor application is comprised of two “things” that must be developed in tandem:<\/p>\n

1. \u00a0Templates<\/em>, which are HTML plus special Handlebars tags.
\n2. \u00a0JavaScript<\/em> template functions, helpers and event handlers.<\/p>\n

Meteor templates are cleaner than traditional template-based development approaches like JSP, because there is never any JavaScript code in the template, and the interplay between the template and JavaScript code follows well-defined rules. \u00a0Microsoft has gone in this direction with ASP.NET using the so-called code behind<\/em> philosophy, where most C# or VB code can be in a separate file.<\/p>\n

When Meteor processes your template, it will call into your JavaScript code at key control points to retrieve necessary data. \u00a0 For data-centric applications, the JavaScript code will typically call MongoDB to retrieve data, and that data will be cached in the browser-side Mini-Mongo\u00a0<\/em>as JavaScript objects. \u00a0The\u00a0Mini-Mongo data is directly accessible to the templates and is in the necessary format to feed the templates. \u00a0There is no conversion overhead.<\/p>\n

Now here is the magic: after Meteor processes your template, the system is smart enough to detect whether any of the data referenced by your JavaScript code has been changed, and to dynamically re-render<\/em> the corresponding template(s). \u00a0 This automatic update occurs without a single additional line of coding, and is the key to Meteor’s so-called reactive<\/em> behavior. \u00a0Please take note of the word reactive<\/em>, because I suspect that you’ll be hearing that more frequently in coming years. \u00a0This is because Meteor, and similar platforms such as Derby, are poised to change user’s expectations regarding how web apps should behave, and there is no turning back.<\/p>\n

But there was one central mystery: how can Meteor know if any of the data elements that happen to be referenced<\/em> by my JavaScript code might have been changed, requiring that my template(s) be re-rendered? \u00a0Meteor solves this problem in an elegant way that is transparent to the developer; moreover, by mastering a few simple concepts, developers can control the underlying machinery to connect to new data sources that are not known to Meteor.<\/p>\n

Whenever Meteor calls into your JavaScript code, it first constructs an object called a Computation<\/em>. \u00a0\u00a0 \u00a0The Computation contains many\u00a0Dependency<\/em> instances. \u00a0Each Dependency instance represents a single data source that might dynamically change after your template has rendered. \u00a0In practice, most of these Dependency instances correspond to MongoDB collections. \u00a0The relationship between Computation and Dependency is many-to-many, so a given Dependency may be contained inside any number of Computation instances.<\/p>\n

At any point in time, there is a so-called\u00a0current Computation <\/em>which is\u00a0“active” at the time your JavaScript function is executing.<\/p>\n

Meteor getter functions, particularly those that involve retrieval of MongoDB data, will automatically add<\/em> Dependency instances to the current Computation. \u00a0 These Dependency instances are listeners<\/em> for any changes in the underlying data source, and each Dependency knows the set of Computations that might be affected my underlying data changes.<\/p>\n

Together, the Computation and its Dependency instances comprise a complete record of all reactive data sources that your template references, both directly and indirectly. \u00a0In other words, as a byproduct of executing your JavaScript template-rendering function the first time<\/em>, the system constructs a record of all reactive data sources that are inputs into your template.<\/p>\n

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. \u00a0With the help of Websockets, Meteor listens to data state changes, and selectively re-renders only<\/em> the affected templates. \u00a0This 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.<\/p>\n

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. \u00a0Since 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.<\/p>\n

I’m particularly excited about the possibilities using Meteor together with HTML5\/CSS3 animations, Google Charts and RIA frameworks such as Sencha ExtJS. \u00a0 Consider these possibilities:<\/p>\n

1. \u00a0Smooth-scrolling tables of data that dynamically roll as data is added similar to the ending credits of a movie
\n2. \u00a0Google Charts that dynamically update as data is changing
\n3. \u00a0Table and tree controls that are dynamically updated as user collaborate on a shared data model<\/p>\n

Such reactive<\/em> behaviors will likely become hallmarks of modern web apps. \u00a0Start-ups can take advantage of these technologies to differentiate themselves from well-established competitors, at least in the near term.<\/p>\n

So, if Grails<\/strong> is a carrier battle group<\/strong>, and Ruby on Rails<\/strong> is a rickety pirate ship<\/strong>, I would say that Meteor\/Node.js<\/strong> are the Oracle catamaran:\u00a0<\/strong>minimal, streamlined, modern and super fast to develop.<\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

It has been almost two weeks since my last blog post. \u00a0During this time, I’ve been working hands-on with Meteor, Node.js, MongoDB and Twitter’s Bootstrap framework. \u00a0One 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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_forum_subforum_count":0},"categories":[1],"tags":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/sotaenterprises.com\/index.php?rest_route=\/wp\/v2\/posts\/2725"}],"collection":[{"href":"https:\/\/sotaenterprises.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sotaenterprises.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sotaenterprises.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sotaenterprises.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2725"}],"version-history":[{"count":6,"href":"https:\/\/sotaenterprises.com\/index.php?rest_route=\/wp\/v2\/posts\/2725\/revisions"}],"predecessor-version":[{"id":2732,"href":"https:\/\/sotaenterprises.com\/index.php?rest_route=\/wp\/v2\/posts\/2725\/revisions\/2732"}],"wp:attachment":[{"href":"https:\/\/sotaenterprises.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2725"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sotaenterprises.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2725"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sotaenterprises.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2725"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}