Node is here to stay. When people first started talking about extending JavaScript into the backend, it was met with confusion at best and derision at worst, but it’s now one of the tentpoles of tech. It’s often the default backend pick for real-time applications and with good reason: its single-threaded and event-driven nature makes it almost unparalleled at handling a high volume of real-time traffic. Unlike other web application technologies like PHP, ASP.NET, JSP and Spring MVC, which instantiate a new thread for a client request, NodeJS apps use the “Single Threaded Event Loop Model”, where the main event loop is on a single thread, and most of the I/O uses different threads.
Today, we’ll be going over the six biggest Node frameworks: their strengths, their weaknesses, and when it’s the right time to use them.
Express.js
Yep, still the champ, and with good reason. Express is a simple, lightweight framework that has—in JS terms—stood the test of time. It has a powerful and versatile middleware interface that few other frameworks can match; since Express has been the default framework for so many years, basically any third-party NPM module you can think of is going to be compatible. Express has built up a tremendous momentum, and it doesn’t look to be slowing down any time soon.
On the other hand, it’s a bit of a blunt instrument. It often results in awkward, buggy code and lays down landmines for future developers. It’s a perfectly respectable framework for most jobs, but it can struggle with specialist work.
That said, it’s not going anywhere. Express is to JS what Bootstrap is to CSS or Google is to search engines—it’s not always the best choice, but it’s usually the best choice and that’s more than enough.
Meteor.js
Meteor’s popularity has declined with each passing year, and I’m not sure it’s going to stick around for much longer. I’d be strung up if I didn’t include it, but it feels like a bit of a dinosaur, getting constantly outmaneuvered by newer, more streamlined frameworks.
It’s still a very powerful framework, with power being the operative word; Meteor has a ton of features and a thriving NPM ecosystem. The other big frameworks are all stripped-down and built for speed, but Meteor boasts that it’s a full-stack package. It hasn’t entirely been obsoleted because there’s nothing else that has quite the same amount of functionality right out of the box. Its Isobuild automation tool makes mobile app construction a breeze.
Meteor is big, solid, heavy and inflexible. If it’s the right fit then it’s a perfect fit, but it doesn’t have the maneuverability or versatility of Express.
Sails.js
Sails has the wonderful Waterline ORM, which is similar to Mongoose ORM commonly used with Express but can work with a broader range of databases. Express is very tightly integrated with the MEAN stack, but Sails lets you use SQL databases and a broader range of noSQL databases. Sails also has a great team and great documentation, though I haven’t found the community as good at answering questions as larger frameworks like Express. Sails is also famously good at handling callbacks and keeping you out of callback hell.
One downside is that Waterline doesn’t support nested objects. It also lacks transaction support, and you’re probably going to need to sort out your own interface for that.
Its popularity has been waning over the last few years and—like Meteor—a lot of that seems to just be because it feels old. It’s often seen as outdated and clumsy, and people are moving onto newer and shinier things.
Next.js
Next is a weird one: it’s a frontend Node framework, if that makes sense. To quote one of its contributors:
“next.js is not supposed to replace your backend. Next is a client-side framework that happens to have a server-side component to allow features like HMR and SSR.”
It’s not strictly in competition with the other frameworks (except sometimes Meteor) because it’s occupying a totally different space. It’s a framework for developing SPAs in React/JavaScript, and it’s very good at that job. Next is still relatively underutilised in the javascript community, but it seems to be building up steam: the developers working with it speak highly of it, and a lot of the community have expressed interest. If you’re trying to put together a single-page app, it could be worth a look.
Koa
Koa is a super tiny framework, designed and maintained by the same developers as Express. Unlike Express, it hasn’t really taken off. It’s so stripped down that it barely feels like a framework at all, that’s its greatest strength and greatest weakness. It’s lightweight, flexible, highly expressive middleware but it lacks the sort of NPM support that a framework needs to survive, especially a framework that is designed to have a small footprint—if you can’t rely on modules to fill the gaps, then you’re going to struggle getting certain jobs done.
If you’re accustomed to operating outside of the NPM ecosystem and want a framework that’s not going to get in the way, then Koa is a solid choice. Otherwise, its lack of community and support might cause problems.
FeathersJS
Feathers is your go-to if you’re building REST APIs. It’s built around two pillars:
- Services are JS objects that implement core methods. Say a user wants to set up an account, you want a service using Object.create(). But should users be able to set up that simply? That leads us to:
- Hooks are ways of modifying services. You can customize your user account creation with hooks like validation emails, while still using the same service.
I can’t really speak to its utility outside of the API space, but I’ve found it handy there. I’m not sure I’d use it for anything else, though I’m curious to hear any reports from developers who are using it more broadly.
In 2019, Express.js is still dominating JS backend and I imagine that—short of a massive failed overhaul a la Angular—it’s going to stick around for a while. Meteor seems to be on the way out, though it lacks any proper competition in the fullstack Node space and I think it’s going to hang on until something better comes along. Sails and Koa are also on the way out, though in both cases it seems more like a failure to launch—they were never that big to begin with, and they’ve slowly bled developers over the last few years.
If you’re looking to read more, why not check out the other side of the equation? Frontend JS is even more competitive than the backend. If you’re a fan of the classics, check out jQuery vs AngularJS, or if you want to see the bleeding edge, take a look at JavaScript Frameworks 2019: reviews and predictions. If you’re a little lost in all the change, you might want to read about how to beat the JavaScript churn.
