Ruby on Rails vs. Node.js ─ Which Backend Technology Should Beginners Learn?

This article is based on the Codementor Hour of Code Office Hour hosted by Steve Klabnik, an active open source contributor who has made 245 commits to Rails before. The audience asks Steve about whether programming beginners should learn Rails or Node.js as their first back-end language, and Steve’s answers are as below.

One of the things you have to remember is that different people learn differently through different methods. Thus, I don’t think there is necessarily a one-size-fits-all answer to how one should learn programming or what language they should pick.

For example, I personally like to learn bottom-up, where I get familiar with all the details before I slowly build up to the abstractions. However, a lot of people also prefer learning thing top-down, where they get to know the abstractions before they understand the details.

Therefore, even if I told you to learn Rails first, there are still multiple ways you can learn Rails, so this question is quite complicated. I think the most important thing in learning if you’re a beginner is to do something that excites you. The second factor you should consider is whether or not what you want to learn has good documentation.

However, to personally answer your question, I would lean towards Ruby because it’s stable and has much more help and documentation available. For example, one of the things I really like about the Rails Girls curriculum is they have a Friday night social hour & install-fest, and on Saturday they do some coding.

Of course, Node and server-side JavaScript is getting older too so there is also a wealth of learning materials, which means it wouldn’t go wrong at this point if you chose it over Rails.

Sometimes the code in the front-end and back-end are almost the same in terms of logic and implementation. Doesn’t this mean if we can reuse the code and adhere to DRY if we use Node.js where both the front-end and back-end are written in JavaScript?

Yes, and some people actually do this. However, DRY (Don’t Repeat Yourself) is actually the short name to saying that there should only be one unambiguous representation of a concept in your system.

Personally, I like to keep a clear division between the front-end and back-end to keep them isolated from each other in the network boundary, so for me having the backend and frontend written in different languages merely accentuates that separation. If I need to repeat a logic in some places, that’s because they’re two different systems, and therefore I am not violating DRY.

Of course, I’m not the master of all programming and there are definitely people who disagree with me on this, the biggest example being frameworks such as Meteor. I personally dislike this approach since I see a papering over of a system’s boundary, and I think it’s important to pay attention to those boundaries. Moreover, even though I don’t have any direct experience with doing this sort of things, I’ve seen people in my network talking about how they ended up with problems when they tried to reuse server-side code in their client-side code.

The only instance where I think you can do such a thing is when you’re dealing with validations. I feel it’s okay to share validations across the server and client-side code, especially if you don’t want to make a network round-trip (which is a big thing everyone talks about). For almost everything else, reusing code across the boundaries seems to me like making a giant ball of mud instead of having two cleanly separated systems.

This is not to say that you shouldn’t use Node.js. One of the best things I think Node has done is enabling people to write backend code, even though they have never done it before. So, that aspect of only having one programming language on both sides is really appealing and brings a lot of new people to programming, so there is definitely some value for having the same language for the frontend and backend.

With over 200 repositories on GitHub, Steve Klabnik is known for his contribution to open source projects, where he has made 1900+ contributions in 2014 alone. He is currently ranked #36 on the all-time Rails Contributors list, and has written the guide Rust for Rubyists. As of June 2014, Steve has joined Mozilla to work on the official Rust Documentation.