Opinions Forming on Rails – More on Node.js
I have an opinion forming about Rails. It does seem to handle everything, but Rails is making the hair on the back of my neck stand up.
If one could compare Grails to a carrier battle group, Rails might be seen as a rickety pirate ship. Although Ruby (the language) is fine, Rails seems clunky, somewhat dated. It reminds me of Oracle: cumbersome install, heavy reliance on command line. It took quite a bit of set up to get through the tutorial. I had to assign very specific version numbers to all of the gems (plugins) in order to get through the tutorial as written. That bothered me.
Moreover, the Rails stack is a little scary because there is so much magic going on. I’m sure it works great on the happy path, but what if you have to stray? Also Ruby on Rails feels like a cult. Rates for Rails developers are high. The phrase The Ruby Way makes my skin crawl. My wild-wolf instincts say run.
I’m of the opinion that model-driven design and MVC will save money if done right. This is evidenced by the fact that many popular frameworks revolve around a domain model. Although all of the full-stack frameworks claim to conform to MVC (or MVVM), they appear to have different ideas about what this means.
This diagram depicts a pattern that I call Absolute MVC, a phrase we coined at Corticon. A user action, such as inserting a new row into a table, triggers a message to the model authority in the back end. The model authority knows how to change the model correctly in response to the user action. A single message may result in substantial changes to the model in a transactional manner.
Full-stack frameworks often refer to the combination of the view authority plus the model authority as a controller.
In Absolute MVC, we formally separate the model authority from the view authority. The view authority is concerned only with refreshing the view, and only in response to state-change notifications from the model authority.
Unfortunately, the full-stack frameworks don’t actually work like this, notwithstanding that they claim to implement MVC. The key reason is technical, and it boils down to this: there was no convenient way for the browser to receive an asynchronous notification from the back end. In other words, there was no reliable way for the model authority to notify the view authority that the model state had been changed. Until now.
As of this writing, there is standardized way to do this called Websockets (RFC 6455). Moreover, there is a cutting-edge framework called Meteor (which works with Node.js) that takes advantage of this new capability. Meteor is the first (and only) framework that I have encountered that implements Absolute MVC with the browser.
If you’re used to traditional web development (e.g., PHP, JSP, ASP), you have to see Meteor with your own eyes, but consider this. The browser views are bound to a shared data model. If any user changes the data model, all browsers update instantly. There is no polling. The function is driven by an asynchronous message from the server to the browser(s).
This architecture avoids a lot of the clumsy implementation issues that surround the traditional request/response/redirect patterns that plague JSP and the like. The code to access data is simple, and you have to see the Meteor screen cast to fully appreciate this. The server delivers data to the front end, and HTML rendering is done in the browser.
However, one drawback to consider is that Meteor and Node.js are new, and many subsystems are still in their zero (beta) releases. The good news is that Meteor apparently had a recent injection of financing which should keep them around for a while.
It is no exaggeration to say that Node.js combined with something like Meteor could become popular very quickly, because the potential savings are enormous.
I’m currently working on a “spike” to get a Hello World application up on this stack to see it with my own eyes, and I’ll post my findings here.