Switching from Rails to Node: A Comparison

Posted by AdamT213 on August 2, 2018

Before I begin, a brief aside on my CS Basics for Coding Bootcamp Students Series: As you may have noticed, I have ceased making posts about these topics, rather suddenly and abruptly, and have not made one for some time. Rest assured, this is not because I believe there is nothing else bootcamp grads need to know about CS, and it’s not because I believe I am now a CS expert that no longer needs to improve my understanding through teaching. The truth is, I started a new job not too long ago, and among the things that fell by the wayside, was my weekly commitment to writing posts in the series. I may still occasionally blog about new and interesting CS concepts, and I have a vague notion of one day doing a series about either cryptography or blockchain, as I learn more about them, but for all intents and purposes, that series is done. Nonetheless, I feel that the 10 or so posts I did write serve as a reasonably complete intro to CS, and if you found them useful, I encourage you to keep studying and learning. I know I have been!

Okay, that aside, let’s get to talking about Node vs. Rails. As a student at the Flatiron School, my intial exposure to server-side web programming (indeed, programming in general) came through Ruby, and eventually, Ruby on Rails. I liked it, and found it plenty challenging, but soon after I began learning JavaScript, and found the learning curve from Ruby to JavaScript steeper than the one from no coding experience to Ruby. As I began learning various front-end JavaScript frameworks (Jquery, React), and expanding my knowledge of the language, I found myself making great strides as a developer. While Ruby had served as a great introduction to programming, it was simply too abstract and high-level to give me an in -depth understanding of many topics that I knew would be essential for a career as a programmer.

So, as I began to write app after app with a front-end written in some JavaScript framework or library and a backend written in Rails, I intuitively knew that there were gaps developing in my backend abilities. So, I vowed that before long, I would learn another backend framework, in another language, to complement and expand my understanding of the server-side. Around this time, I began hearing more and more about Node.js, and while applying to companies, saw it come up again and again as a required or preferred skill. Since I enjoyed programming in React so much, I figured that learning node would be the perfect way to continue my path as a developer.

Fast forward to actually beginning to program in node, on the Learn.co platform. The early material was easy enough, as early material is wont to be, and I found node a refreshing transition from React, since it was built around the npm library manager I had become so accustomed to. But soon enough, between configuring express servers and writing knex migrations, I was thoroughly confused. On several occasions, I experienced test suites that would pass sometimes, and fail other times, under the same conditions! I found myself initially unable to complete many lessons, instead needing to view the solution to see how it worked, rather than coming up with it myself. This had never happened to me before, and I knew that my suspicions had been confirmed: Ruby on Rails had ill prepared me for the challenge of a less abstract framework.

Fast forward another month or so, during which time I have had the chance to play around much more with the Node and Express frameworks, and I am finally beginning to feel somewhat comfortable with writing backend JS. In fact, I now feel that I have, perhaps, been too hard on Ruby and Rails. In my opinion, writing code in Node.js and writing code in Ruby on Rails are, in fact, very similar. In both cases, packages (whether they be modules or gems) are installed to a single file. Then, migrations are written to conceptualize models. In fact, I find knex to be quite similar to ActiveRecord, with the only main difference being that the actual code for migrations must be written by hand, and cannot be handled by the generator (that, of course, and the fact that knex.schema can return promises, but we’ll get to that later). Things become more complex when you actually create the models, and I will certainly admit that bookshelf operates at a much lower level than activeRecord methods like foo belongs_to: :bar. This was initially one of the more difficult aspects of transitioning to node, and it wasn’t until more recently than I would like to admit that I fully grasped the fact that the bookshelf model relationships must match the table relationship names EXACTLY, but now that this has all finally clicked, I see that it was never all that complicated. Beyond that, the controllers in node are much lower-level than Ruby, but since I already had experience working with promises thanks to React, they were not too difficult to catch on to.

It has been said that the main draw of Ruby is how quickly and easily it allows developers to prototype and build. That being said, I have found developing in Node to be relatively quick and easy as well, since I got the hang of it. My recent node app(https://github.com/AdamT213/hand-trackerAPI) took me no longer than any of my previous Rails apps, and it was the first time I took significant time to write a personal test suite! This may be, in part, thanks to the fact that I am a better and more experienced developer than the last time I wrote a Rails backend (and this is, no doubt, due in some part to my having expanded my abilites by learning node), but it is also, at least partly, due to the fact that node is fairly quick and easy to code in, in its own right. For one thing, I like the way node apps (and JS apps in general) are organized. I always found going to the Routes.rb file to be a pain, and I like that in node, the routes are defined in the same files as the controllers. In general, almost everything I ever touch in development resides in the app folder, whereas in Rails, things I needed regularly were all over the place.

Add to this the fact that apps written in node are known to be much faster, more scalable, and more efficient than those written in Rails, and it comes out the clear winner. Node is known for its non-blocking I/O, meaning that, while in Rails, the computer can only handle one process at a time, in node, it can start a process, then another, then another, via the same asynchronous rendering I used with React. The ability to use promises is node’s greatest strength, and the thing that most greatly contributes to its learning curve. That said, it is worth the investment of time and frustration.

In sum, I will double down on my previous statement: learning node has given me a deeper appreciation for Rails. I see how similar the two are (and can only imagine how similar other backend frameworks must be, too), and I am glad that my first programming experiences came via this simple, elegant framework. But, I like operating at this lower level of abstraction.