Express.js vs. Rails

Why I Am Comparing These Frameworks

I am about to start working on a mobile application with another developer. We decided to use React Native for the front end since I already have experience with React. However, we have been trying to figure out what framework to use for our back end. Since I have never used Express before, I wanted to dive into the differences between Rails and Express. Additionally, during my job search I have seen more companies listing Node and Express in job descriptions rather than Rails. It seems like Express would be a good tool to learn and I really enjoy programming in JavaScript, however I also enjoy the simplicity of Rails.

What is Express?

Express is a web framework for creating the server-side of web applications. It utilizes Node.js and just like Rails, it uses an MVC pattern to control back end application logic. It contains HTTP utility methods, a wide variety of middleware that can be included, and many other features to make building a web application with JavaScript easier. Some people have even compared Express to Sinatra which is more of a lower-level Ruby framework than Rails.

Comparing the Frameworks

On first glance, it was pretty obvious to me that Express was much more minimalistic than Rails. Rails is a very large framework and is very opinionated about the way an application should be built. There are model files, controller files, view files, a routes file and much, much more. Express is much more lightweight and there is more flexibility on how you structure your application.

Rails Pros and Cons

Pros

Rails comes with everything you need to create a web application out of the box, including built in support for a SQLite database. Since it is optimized for web applications and has a lot of packages included, creating a standard web application is super fast for developers. Ruby syntax is very intuitive and easy to understand for developers. Since the framework is opinionated, if you look at another developer's Rails application it will be relatively simple to understand how it works.

Cons

Because Rails comes with so many packages, it can be quite slow and heavy. Additionally, since it is quite opinionated about the structure for your application, there is little flexibility and it can be frustrating to work outside of that box. Along with that, the highly abstracted code in Rails can be difficult to debug since the developer is so far removed from the underlying functionality of the framework. One more thing to note, is that it sadly appears that Rails is not being used by companies much anymore.

Express Pros and Cons

Pros

Express is super lightweight and fast. It comes with minimal packages out of the box and developers can add middleware as needed. It is highly customizable and flexible, unlike Rails which keeps the structure of applications relatively similar. It is one of the most supported Node frameworks, so developers can ensure that improvements are being made frequently.

Cons

Due to the fact that Express is lightweight, it can require more lines of code than Rails to create the same application. Rails comes with generators that allow you to build out models, controllers, serializers and more super fast. Express will require more time to code the application how you want it to be.

Decisions

I think after all of my research, I am leaning towards using Express. Since it is lightweight, super fast, and built on top of Node, I think it will be a great tool to learn. We will probably end up using MongoDB / Mongoose along with Express to align with the MERN stack.

Let me know if you guys have created applications with Express and Rails and what your thoughts are on these frameworks. Thank you for reading!

Additional Resources

• Medium Blog
• Express Docs
• Node JS Info

Comments

[leastbad]

Hey Rachel!

It really depends on what you want to build, right?

Express isn't a 1:1 comparison with Rails, which comes with an opinionated set of frameworks. If you are looking for the Ruby equivalent to Express, you should check out Sinatra. That example on the homepage isn't a fragment; it's a complete application and it should be quite familiar because Express is based on it.

Rails is an abstraction from the Basecamp project management system, so out of the box it comes with all of the building blocks you'd end up wanting if you were building a typical SaaS product; it also supports an "API mode" and supporting React (if you must) is as simple as a command-line flag. It's distinctly possible that Rails is the fastest way to get a server-backed React app running and deployable.

However, very few people want all of the frameworks that come with Rails, and there are several paths people take to pare it down. Experts are likely comfortable enough manually skipping or removing frameworks they don't need. There's rapid progress being made on a Rails interactive installer as I type this. Today, you have two really excellent starting points: railsnew.io/ lets you quickly build your own custom rails new command. And the RailsBytes project allows you to pick and choose modular functionality and merge it into your project.

The thing is that if you're playing around with new tools, chances are Sinatra (or express) are a great way to stand up a project really quickly. However, if you're building something more significant, you're going to end up adding in a huge amount of what makes Rails feel bloated if all you need is server-side template rendering.

In the end, it really should come down to which tools make you happy and productive. There are some people who love writing JS, but did you know that Ruby was designed to optimize for developer happiness as a primary design goal? It's not some feel-good, throwaway motivational idea for our community; we defend it vigorously.

On the Rails side, all of the decisions that have gone into the framework are informed by The Rails Doctrine. Give it a read. Does it resonate with you?

In the end, I hope that I can keep your mind open to the possibility that working in Rails is kind of amazing. The community isn't toxic and the libraries are mature. There isn't the constant churn of new build systems and throwing everything out every few months. All of that "excitement" comes at a real cost to productivity and, over time, contributes to depression and burnout just trying to stay on top of this week's new thing.

[Noel Miller]

Rachel,

I've had the opposite experience while job hunting here in the San Francisco Bay Area. Very few ExpressJS and mostly Rails for back-end requirements. The comparison to Sinatra is valid and I was able to spin up a quick/easy POC using in recent years. Your comparison makes sense to me and I share you preference for ExpressJS. When considering the old adage "choose the right tool for the job" I have to say that Rails is a better option when you want to do old-school CRUD operations using a SQL DB. There is no denying that activerecord fills a need that is pretty straight forward with very little pain or code (from our engineer) required. Apparently, there are similar solutions for the nodeJS world, but I have no experience with them and can't recall seeing job reqs that list them. 
Finally, I want to point out that the "serverless" cloud solutions that I have seen, namely Google "Cloud Functions" and Amazon "Lambda" appear to have embraced nodeJS tech like Express, while rails lags behind. They do support Ruby, but that won't help you with your ROR app.