As rails developers, we are somewhat spoiled when it comes to productivity. For every conceivable piece of work you might want to undertake, a developer somewhere will have already spent a lot of time figuring out the best way to do it and in most cases will have written a nice little gem that takes all of the donkey work out of the implementation. This, combined with the beauty and elegance of the ruby language, is the main reason that most rails developers don’t want to code in anything but their beloved framework.

Everything else just looks like a lot of faffing, right?

So when I sat down to teach myself node.js, the relatively new kid on the block (2009, with ES6 support added only in September 2015), the first thing I tried doing was tracking down the equivalent packages from NPM that would allow me to enjoy the same levels of productivity that I did in rails.

Ultimately I would realise that trying to find equivalents between these two platforms is counter to productive learning. They are different, and it is good that they are different because it means the choice of platform becomes an informed one rather than just a personal preference. That said, there are a number of de-facto node packages that mirror the rails ecosystem. Here’s a rundown (note, this is a living list and may be updated at any time);

Then there are some packages that are really only applicable to the node/js landscape but which are equally as indispensable. You can get a gist for these on the NPM site itself, which provides a list of the most starred packages (a good indication of what the community is using). Some highlights include;

Async – write cleaner asynchronous code

Moment – date manipulation / parsing

Underscore – Functional Programming library

Q – CommonJS Promises

Conceptually, here are the main differences I have noticed between rails and node.js.

Node packages tend to be smaller and do less than ruby gems. But there are more of them! The node community really seem to have embraced the concept of breaking a problem down into the smallest possible parts. Ruby gems are often accused of being bloated (rails most of all) – with node packages it’s the opposite, with ‘lightweight’ and ‘micro’ often appearing in a package’s description.

The node community is ridiculously un-opinionated. Whereas rails will try to shoehorn you into doing things ‘the rails way’, node gives you no such boundaries. In my opinion this is both a curse and a blessing. Without the constraints of convention, we are free to choose the most appropriate architecture for a given problem. At the same time, your average rails developer will join a new project already knowing roughly how the application will hang together whereas with node, you have no idea what to expect!

That said, the node community do have certain opinions that inform style and architecture decisions. These include conventions such as ‘error first callbacks‘, ‘use promises/streams if they are available’ and ‘avoid nested callbacks‘.

The node community appears to favour mongoDB over RDBMS like postgres or mysql. I can understand why – it takes the concept of doing ‘Javascript everywhere’ right back to the database layer! With disk space no longer coming at a premium, NoSQL has risen in popularity however RDBMS are still catered for by node and remain the most popular storage solutions.

This article will expand as I explore further into the Node.js landscape more fully, check back to stay up to date.