What Did Node.js Provide that Rails Didn't?

When I graduated with a Computer Science degree at the end of 2012, Ruby on Rails was at its peak popularity with the startup crowd. It seemed like every hot startup was using it.

Since I was (and still am) a big fan of startups, I applied to various startups and my first job out of college ended up being at a nine-person company as a Rails programmer.

I dove headfirst into Rails and learned how to make web applications quickly.

To me, the appeal of Rails was and is simple: Trust the default standards that the framework sets for you, and you’ll be able to quickly create web applications.

In my experience, Rails largely fulfills this promise. The default settings are sensible. There aren’t too many gotchas.

Plus, with hosting providers like Heroku, you can deploy your application for the world to see in minutes.

Switching to Node.js

Four years after graduating (near the end of 2016), Rails was still popular but Node.js had become the hot new fad for programmers as this graph of Stack Overflow questions shows:

I ended up with a job doing Node.js work. It was a good change for me to see how another language and framework could create web applications. I ended up doing Node.js for the next two years.

In my opinion, there were/are two ideas that made Node.js popular.

First, nonblocking I/O meant that your applications could scale much quicker than frameworks with blocking I/O like Rails.

Second, you could write code on both the client and the server in javascript, allowing you to reduce the amount of code you had to write.

For the first benefit, Node.js beats Rails easily. There have been many words written online about how well Rails can scale or not, so I’m not going to continue that debate here.

All I want to state is that scaling on Node.js is much easier than on Rails. There are libraries and features to help Rails scale, but by default, Node does scale much better.

This shows because not only is Ruby generally a slower language than javascript:

But, a Node server can generally process many more requests than a Rails server:

Node’s nonblocking I/O really shines when you have to create real-time applications (like chatrooms). WebSockets on Node scales right out of the box. WebSockets on Rails does not scale easily.

Node feels like it was made for real-time applications. Rails was made for synchronous HTTP requests and had real-time functionality added on later.

For the second benefit, I didn’t feel like having javascript on the server and client made much of a difference.

Code on the client and code on the server are different. The code you save by using the same language on the server and client is minor at best.

One feature that I thought would be easier in Node than in Rails was single-page applications. Instead, I found that wiring up a single page to a backend took a similar amount of work in both.

In the end, I’d say having the same language on the client and server is neither a pro nor a con.

What Rails got Right that Node Didn’t

So, what’s the issue with Node? Simply put: Developing a web application on Rails always felt easier and faster than with Node.

I have set up several new Node.js projects and I ran into quirky issues every time.

The default package system (npm) causes all sorts of issues. I have talked with several programmers with years of Node experience and they all have npm horror stories.

The fact that Yarn had to be created as alternative tells you all you need to know. Here's a simple graph showing how much quicker Yarn is than npm:

For some reason, programmers who create open-source javascript libraries frequently make major changes. I can’t count the number of times I’ve run into issues with upgrading packages in Node applications.

I’m pretty sure I’ve run into compatibility issues with Rails less than five times in my career. I’ve run into compatibility issues at least fifteen times in Node.

Also, since Node isn’t a complete framework, there are a lot of important technologies for you to choose from.

Do you use MongoDB or PostgreSQL or MySQL as a database? Do you use React or Ember or no front end framework?

This is just the tip of the iceberg. I estimate you have to make choices on at least five important technologies in your application.

What is worse is that if you choose an unusual combination (which is likely), then you’re less likely to find Stack Overflow answers to any issues that you might have.

For Rails, it felt like I almost always could get a solid Stack Overflow answer to any issue that came up. I felt like I rarely could get a solid Stack Overflow answer for any Node issue that I faced.

I can almost guarantee that some programmers will call me out and say that I don’t understand Node or that I’m not a good programmer.

Even though I’m not a great programmer, my skill and understanding are beside the point. What I do know is that I was always much more productive in Rails than in Node.

Ruby and Rails feel well thought out and simple in a way that javascript and Node never did.

My Final Thoughts on Rails vs Node

As I’ve reflected on my time with both, I can’t help but cynically feel that the real reason Node is so popular is because the programming world got bored with Rails.

It’s not that I think Node is bad technology. In fact, I think it’s great when you use it for the right purpose: Creating scalable, real-time web applications.

But, if you want to create web applications quickly without too much hassle, I still haven’t found a better choice than Rails.

Even if you have an application that requires a small bit of real-time functionality, I’d pick Rails over Node. The hassle of adding bits of real-time functionality to Rails would be less than the general hassle of Node.

It’s only if I needed to create an application with a major real-time component that I would use Node (like a Slack clone).

I’m not saying that “old” and “boring” technology is always better than “new” and “sexy” technology. 

Instead, choose the technology that will help you to create maintainable software as quickly as possible. That’s what matters in the end.