comment 0

So, you’re a Rails developer and you want to learn “Node”?

You’ve got a few (or many) Rails apps under your belt and you’re pretty good at it, but you hear all the cool kids talking about this thing called “Node” and you want try your hand at it. Here’s some advice for getting started and for clearing up some confusion that you might have at first.


Node isn’t comparable to Rails; Node by itself is more like MRI + Unicorn/Puma/WEBrick + Rack. Learn Node and proper JavaScript with Manuel Kiesseling’s beginner and craftsman book bundle, which will be the best $9 you’ve ever spent. Then learn a web framework based on Node. I recommend Express, which is more like Sinatra than Rails, because it’s easy to master and used by a huge proportion of Node developers, way more than Sinatra or other minimalist frameworks in the Ruby community. You’ll eventually want to learn React for front end work and, if you want a Rails-like experience, you’ll want to learn Meteor, but Express will do for now (and depending on your needs, maybe for the long term).

Why learn Node and why do others use it?

Let me give you some personal background first. I started getting interested in Node when a major Rails project that I was working on finally came to a close. As I started looking around for the next project to work on, I began to realize that Node, a framework that I was aware existed and was popular, was in fact popular and existed. (Go figure!)

I’ve found that understanding why a widely-used technology is popular helps me in my learning process, since otherwise I get stuck on “but I’m so good at X and X is so good! Why can’t everyone just use X?” This is especially true since as an avid Rubyist I don’t understand for the life of me why someone would willingly choose to use JavaScript. So here’s my list of the most important reasons why people use Node:

  • Designers are driving business. A lot of product work in the web development world is driven by design agencies who are approached by clients rather than clients approaching developers directly. These agencies then either farm out the product work or assign it to in-house developers, but either way, the first point of contact for many development projects is a design agency or a designer. Since designers tend to have closer affinities to front end development and straight up HTML/CSS rather than back end engineering, they love JavaScript. Developing the back end in JavaScript with Node thus makes project management easier–not because becoming monolingual creates efficiencies (see below), but because designers become more comfortable delving in and monitoring back end development.
  • People think that monolingual development creates significant efficiencies. This argument was strong when Node was first making its way onto the scene and was, in truth, more like a prediction than a law. In my experience, being able to use just one language for a project is a perk whose usefulness has been blown way out of proportion. First of all, any ambitious web app is going to require native clients for mobile, which will inevitably require learning something other than JavaScript. More importantly, the mark of a good engineer isn’t whether they know a particular language at the moment but how well and quickly they can learn when needed. The languages you choose for your project should be determined in the same way that you choose tools for building sections of a house: the right tool for the right job, not one size fits all. Nevertheless, that doesn’t prevent people from thinking that monolingual development is sustainable in the long run or that its benefits outweigh its problems.
  • Although Rails’ performance problems are overblown, Node genuinely shines in many contexts. Maybe if people didn’t abuse ActiveRecord queries so heavily, Rails wouldn’t have such a bad reputation for slow performance. Time has nevertheless shown that Node has excellent performance in concurrency. Performance degrades when it comes to computationally-intensive tasks, but most web apps aren’t computationally-intensive (and if yours is, you should probably refactor out your cancer-crunching algorithms to something like Java and hook in where appropriate). The performance gap makes intuitive sense. The V8 engine at the heart of Node was designed by Google with performance as the primary goal whereas Ruby was conceived by Matz first and foremost as an elegant and pleasant language.
  • Node has the momentum. People rightly deride Silicon Valley for being a bubble, but for better or worse what happens in the Bay Area tends to drive tech trends (at least outside of the Microsoft world). There is a sense here in SV that Node is in and Rails is out. My personal belief is that the reports of Rails’ death are much overblown given Ruby’s sustained presence within the top tier in rankings of programming language popularity. Nevertheless, it can’t be denied that the Node ecosystem is stealing the headlines (see this Google Trends graph on searches for Ruby on Rails vs. Node.js), especially with the front-end development revolution ushered in by React. React, of course, is just a JavaScript library and can be served up by any web server, but in practice it is closely associated with Node. Isomorphic rendering is furthermore all the rage today, and in order to pre-render React-driven sites on the server you need to use Node. Finally, some of the most exciting intellectual developments right now, such as the release of ES6 and JS2015, are happening in the JavaScript world, which indirectly helps Node, as well.

What exactly is Node and what are some important differences from Rails?

Now that we’ve covered why people use Node, it’s time to discuss what exactly we mean when we say Node. I’ve created a table below that compares technologies within the Node and Rails ecosystems:

Technology Node world Rails world
Language JavaScript Ruby
Web server Node MRI + Unicorn/Puma/WEBrick + Rack
Package management npm gem + bundler
Popular minimalist framework Express Sinatra
Popular heavyweight framework Meteor/Sails Rails
Templating engine/language Jade Haml
Utility script management Gulp Rake

There are a few differences here that merit further discussion:

  • Node is not Rails nor a web framework but rather an interpreter/web server combo. Comparing Node to Rails was probably the most n00b of the n00b mistakes that I made when I first started learning the former. Node is actually three things: a language interpreter that can be used on the command line or that can run scripts (like MRI or JRuby), a web server (like Unicorn/Puma/WEBrick), and a barebones framework for stringing together middleware and interfacing with the web server (like Rack). Additionally, it provides some important utility methods that aren’t native to JavaScript. These methods (e.g., require) have in turn enabled certain conventions (e.g., modular dependencies) that have since become common throughout the JavaScript world. But despite all this functionality, you probably don’t want to make a modern web app using just Node. You will need to choose a framework to learn in addition to Node.
  • Minimalist web frameworks are way more popular in the Node ecosystem. In the world of Ruby-based frameworks, minimalist web frameworks, like Sinatra or Padrino, have always been a bit of a sideshow compared to Rails, which as been the main course. Not so in the Node ecosystem where developers have embraced minimalist frameworks, especially Express. Just compare Google trends (Express vs. Meteor and Rails vs. Sinatra vs. Padrino), GitHub stars (30.3k Meteor/12.7k Sails/21.9k Express and 28.6k Rails/7.5k Sinatra/2.6k Padrino), and StackOverflow tags (17.2k Meteor/3.8k Sails/19k Express and 226.2k Rails/4.3k Sinatra/340 Padrino) to get a sense of the relative popularity of full featured vs. minimalist frameworks in each ecosystem. When starting to learn Node, therefore, it behooves you to consider learning a minimalist framework like Express.
  • The Node ecosystem is much less tied to MVC (model view controller) than the Rails ecosystem. Rails, no doubt encouraged by parallels in iOS and Android development, enshrined MVC as the premier paradigm for architecting web apps. The MVC pattern was further entrenched through popular client-side JavaScript libraries like Angular, Ember, and Backbone. Node frameworks, however, have encouraged deviation from MVC. Meteor can certainly be used in an MVC-like fashion, but it isn’t forced upon you, and the popularity of Express means that a large proportion of Node-based projects start without any suggested or implied pattern. The degradation of MVC has been furthered by the rise of React.

In sum, just learning Node by itself won’t get you very far when it comes to becoming a Node developer. You’ll need to learn at least one web framework. You’ll also need to change some of the ways that you think about architecting your web apps, especially when it comes to thinking beyond the classical MVC pattern.

What will I need to learn in order to become a Node developer?

I am by no means the most qualified person to answer this question since I’ve just started my journey into Node, and what follows stems from my limited experience.

In broad terms, you’ll need to learn five things: “real” JavaScript, Node itself, a Node-based web framework, Node-related tooling, and new ways of thinking about and patterning your apps. In my opinion, the first and the last of these are probably the most challenging and exciting parts of the path ahead of you.

  1. “Real” JavaScript. If you’re like me, you probably started Rails development from the back end first, devoting the bulk of your energies to mastering Ruby and MVC, refactoring patterns, and so forth. JavaScript, HTML, and CSS feel secondary to you and you’ve probably used Bootstrap as a crutch for too long. Well, you can continue to avoid becoming really good at HTML and CSS, but if you want to be a good Node developer you’re going to jump into JavaScript head first.
  2. Node itself. This suggestion might strike you as a little strange since most novice and intermediate Rails developers don’t make a point of learning Rack/Ruby web servers properly. The difference is that whereas Rails generally isolates the developer from the underlying Rack API’s, Node-based apps tend to interact with the underlying Node API’s much more frequently, so you’ll need to learn Node proper early on.
  3. A Node-based web framework. Personally, I recommend learning Express first. Express has a very concise, Sinatra-inspired API, and if you’ve ever made a minimalist web app using Rails, Sinatra, or something similar, you’ll find yourself right at home. You can master Express after developing a few toy apps, and unlike learning Sinatra, mastering Express will place you in the mainstream of the developer community with highly-demanded skills.
  4. Node-related tooling. This step is pretty straightforward, and you’ll be able to pick up tooling skills as you go along. The only thing to realize is that in the Node ecosystem, the tooling options are much more varied and generally aren’t just provided to you as part of the framework. I recommend becoming familiar with gulp, which is the Node world’s answer to Rake, in particular.
  5. New patterns and ways of thinking. Closely related to the first step listed above, you’ll need to become familiar with new paradigms and idioms. I’d like to cover some of these in a subsequent post, but for now let me list a few that I’ve found to be the most confusing when coming from Rails: no MVC, asynchronous execution, prototypal inheritance, and binding/scope.

OK, enough chit chat. What’s the best way to actually start learning Node development?

My first stop would be Manuel Kiesseling’s excellent pair of eBooks, The Node Beginner Book and The Node Craftsman Book. As of writing, you can get both for just $9 from Leanpub. Kiesseling covers learning Node itself from the beginning without any frameworks as well as important JavaScript concepts, and he does a terrific job at both.

I would start from the beginning of the beginner book and work your way through the craftsman book, but I would skip the chapters in the craftsman book on MySQL and MongoDB and revisit them later if you want to use those systems. I suggest skipping those chapters because, in my experience, creating toy apps doesn’t require an in-depth knowledge of database client libraries, and you can get by with just cribbing code from the libraries’ GitHub pages and API docs. I would also skip part 2 of the craftsman book, where you learn how to create a complete AngularJS web app with Node, because you’ll cover similar information when you learn one of the Node frameworks.

You’ll probably run into difficulty with JavaScript concepts along the way. I had the most trouble with the following:

  • Asynchronous vs. synchronous execution. As you probably know already, JavaScript code doesn’t always execution synchronously, but you may not have had to pay too much attention to this aspect of the language before. In Node development, it’s critical to understand how async vs. sync works. Fortunately, Manuel’s craftsman book provides a beautiful explanation of the issue, but it may take creating a few toy apps for the lesson to really sink in.
  • “this” and binding loss. Ruby and many other languages have implicit binding, meaning that when you execute a method without a reference to an object, there is an on object to which the method is implicitly bound. Or in other words, the interpreter has a default object that it knows to go to when it goes looking for the method’s code and scope. In JavaScript, like Python, you must always specify the binding object explicitly. The rules for binding, however, can get very tricky, especially when using the “this” keyword (similar to “self” in Ruby and Python). You’ll want to read up on the subject, especially while working through the craftsman book. I found Christophe Portoneuve’s explanation here as well as the Mozilla Developer Network page on “this” very helpful. I would read through these resources once you reach the file size watcher example in the craftsman book, specifically on page 40 after the “var self = this” idiom is introduced.
  • Prototypal inheritance. JavaScript has a system for inheritance that is totally different from Ruby or most other object oriented languages. In JavaScript, there are no classes, but rather inheritance is done through objects and prototypes. The craftsman book explains this concept well, but I found the MDN reference helpful, as well.

After working your way through Kiesseling’s books, I’d learn the Express web framework by working through their getting started tutorial first and then their guide. You can easily master Express through just these resources if you’ve developed web API’s before as the API is very concise.

Having learned these concepts and technologies, you’ll be well on your way to becoming a Node developer!

Stretch goals: React

If you aren’t already familiar with a front end JavaScript framework, you should learn one. I would recommend learning React, which is changing the game. I’ll leave writing about React to another day.

Leave a Reply