Node.js is still on track to take over the open source community. Big players from multiple enterprise-level organizations are either implementing it or considering it for their next platform. LinkedIn, Mozilla, Netflix, the list goes on. They all have bet on Node due to its scalability, performance, and twice-yearly releases (including one annual long-term service release).
Its growing popularity, however, does not necessarily mean that everyone should go with Node right now. After all, it shouldn’t matter how popular a technology is or whether one name seems more familiar than another—what should matter is making educated decisions about your stack.
And in this post, we’ll be outlining how we make these sorts of decisions here at Monterail.
Although Ruby on Rails is our mother tongue, it doesn’t mean we can’t speak other languages as well. But what did actually bring us closer to Node.js?
For the last couple of years, we stuck by RoR for a number of reasons:
- high market demand,
- it works great for MVPs due to fast pace of development,
- it is easy for developers to move between different Rails projects,
- it teaches developers good coding habits,
- Ruby code is very readable and mostly self-documenting,
- it’s a well-proven, full-fledged technology
Rails is obviously not going to fade away. It’s a stable, mature technology that has a lot to offer to businesses. But it’s still just a tool that needs skilled craftsmen. Combining even an imperfect tool with perfectly skilled programmers will make a great app. After all, your users won’t care what’s under the hood, only if their app is useful and intuitive.
Most popular languages on GitHub by open pull request
Node.js From a Developer’s Perspective
Node.js has been there for a while, but began gaining real traction only in 2011 when LinkedIn launched its mobile app. Right now, Node.js is the most popular kid on the block—98% of Fortune 500 companies use Node.js regularly. It also wins as most loved framework (73.4% of developers love Node) and it’s the second most-demanded coding skill by employers right now.
As a technology company, it’s paramount we stay up to date with all tech news and trends. We seem to be nearing peak demand for Node, so it was high time for us to find out what all the fuss was about. Additionally, more and more clients were approaching us asking about Node, but we decided that we would ultimately add it to our stack only after getting approval from our programmers.
After some research and feedback from the team, we recognized that Node could be a viable alternative for our backend:
- using the same language on the server side and the client side is a key advantage that enhances internal communication and understanding of the product as a whole,
- Node.js provides a non-blocking IO system that lets you process numerous requests concurrently,
- Node.js has a great number of unpolarized libraries enabling considerable development freedom,
- our team was really fired up by Typescript which provides the tooling that Ruby lacks—although Typescript is opinionated especially at the beginning, it helps a lot later down the line, making testing much smoother,
- it’s been verified by the market—there are more and more apps out there based on Node. We have been receiving a bunch of inquiries for projects in this technology, too.
Hence, stemming from real business needs, the decision to incorporate Node.js into our backend stack was not exactly a game changer, but rather a natural next step in our growth.
We’ve already worked on a few Node.js-based projects, including Guild—a private messaging app for professionals, and multiple apps for one of our enterprise-level client. Detailed case studies with know-how and lessons learned are on the way, so stay tuned.
So, Is Node.js the Solution You Need in Your Product?
Although Node.js has many valuable virtues and works well for these clients—it might not be the best choice for every project. Node.js should be considered for any real-time applications intended to run on various devices. If your product requires fast prototyping or performs CPU-intensive tasks (like generating graphics) there are other technologies, including Rails, that will do a better job. By choosing Node for heavy computation tasks, you will actually lose most of the advantages it offers. Use it in scalable, fast network apps, however, and Node will shine.
Where does Node.js fall short? In terms of out-of-the-box solutions. Contrary to RoR, many things need to be done from scratch, which in turn increases the project’s overall duration. On the other hand, however, if you’re planning an app with a long lifespan, the time and costs invested in the beginning offer considerable returns in the long run—you gain a number of tools that will streamline the addition of features in the future. Doing this with out-of-the-box solutions might be more troublesome. Therefore, Node.js is perfect for custom-tailored software.
All in all, it’s not bad news.
Rails is mostly recommended for small projects, MVPs, and product validation, but it doesn’t necessarily mean you have to follow that pattern. You might opt for what Twitter did: launch on Rails and move to a new platform once you start making money and need to scale. You can also stick to Rails like Airbnb did and do just fine.
At the end of the day, it is not about the tool, but about who uses it.