Ruby on Rails vs. Node.js & Express
I wrote my first Node app, with Express, a few months ago. At the time it seemed very similar to the process I would normally go through when building a Rails app, with more dials to configure. Rails is famous for the saying: Convention over configuration and it was through building this Node.js app that I truly came to appreciate that proverb. I wanted to dig around and appreciate some of the differences between Node.js and Rails to better understand when it may be appropriate to use one over the other.
Rails contains a consistent structure, using the MVC architecture exclusively. The core files and folders are going to look very similar project-to-project. Rails is very opinionated. It assumes you are going to write code a particular way. The major advantages to this approach is that it makes errors easier to spot and understand; makes for cleaner code; it’s easier to write and read. A morbid, but accurate, way to think about Rails is that it limits the rope you can use to hang yourself. While other frameworks offer less opinions about how to interact with them, they often invite problems you can all together avoid with Rails. An example of this was when I was setting up a Node.js app with MongoDB, just to get the database talking with the application was a hassle, whereas in Rails it comes by default with Postgres, making it much more streamlined and easy. Rails has great database migration and functionality for editing and creating columns in our database without having to manually go in and add or change attributes. With that said, Node does have packages, such as db-migrate, but it is not as easy to use and doesn’t offer as much as compared to what comes standard on a given Rails application. When it comes to prototyping and rapid development Rails is hard to beat. You can CRUD full applications with a few scaffold and configuration commands. Database migrations are a big contributing component of this efficiency. Node and Express can also be fast, but again requires more configuration to provide the same functionality that Rails does out of the box.
The Ruby language itself is great. It is very expressive, making it easier to read relative to other languages. This contributes as another factor for speeding up development, as a lot of Ruby frankly looks like plain English. It has tons of helpful methods built into the language that make it easier to write than many other languages. Lastly, RubyGems is Rails package management tool, used to extend the core functionality of the framework. Since the Rails ecosystem has reached maturity, there are tons of helpful gems that keep us from having to reinvent the wheel in our applications — e.g. Devise for user authentication and authorization.
Rails is relatively slow compared to Node and Express. Rails comes out of the box with a lot of things we may not even need in our application. At Rails Conf 2017, I heard a talk by DHH, the founder of Rails, in which he talks about understanding the community’s frustration with having so many tools that go unused in Rails projects, and contribute to slowing down the application. Rails automates so much for us that a beginner developer who starts with Rails is at high risk for not actually understanding how it works. Rails abstracts away so much for us that we don’t need to think critically about components that otherwise might be considered in depth with another framework. Working with Rails on big projects comes with its own set of headaches and can have issues scaling as a user base grows. With that said, here are some companies that use Rails: Hulu, Groupon, Urban Dictionary, Soundcloud, Bloomberg, Basecamp (founded by DHH), Shopify, and Living Social. Twitter did use Rails for a long time, but has since made the transition to Java and Scala.