Ep.01: Node.js Back-end Frameworks Comparison: Market share

This article is part of a series where we will compare the top Node frameworks (as of 2024), covering various aspects: market share, learning curve, ecosystem, security, actual code implementation of the same project, and more. It is an in-depth comparison, 20+ episodes planned, probably the most detailed comparison you will find out there. I have not yet seen anything going into the level of detail I intend to go into, but if you know of any, do let me know in the comments. I will try to make the series valuable to anyone intermediate to advanced in Node.js, while providing enough explanations so that even someone just getting started could replicate everything on their own.

Table of contents

1. Market Share Distribution Analysis: Picking the most used frameworks
2. Planning Phase: Use cases, Minimum Viable Product requirements, Architecture
3. Tools & Setup: Getting started and setting up the tools and environment
4. Scaffolding: Project Settings and Configuration, Common template repo
5. Express: basic app (MVP)
6. Koa: basic app (MVP)
7. Express Flavors: basic app (MVP) in multiple variants: OOP, FP, TypeScript, single-file etc
8. Nest.js: basic app (MVP)
9. Fastify: basic app (MVP)
10. Next.js: basic app (MVP)
11. Vanilla Node: basic app (MVP)
12. Functional testing with Postman + Newman

Before we start: this article series has a purely educative purpose, to help you better understand the differences between the many frameworks available. It will not nominate a King or Queen of the Backend or tell you the One framework to rule them all. When you choose your tools for a project, you should pick the best tools for the job, not the best job for your tools. A backend framework is one of the tools you'll need, and you should select it based on a complex set of requirements and available resources.

Yeah, I know, can I be more vague than that? Let's pick some random examples. Say your project requires a live chat option, peppered with the ability to send files over chat and say costs are a concern while storing data securely or accurately is not. You're gonna want to pick either something with native support for real-time communication (like Socket.io etc), or minimalistic frameworks with lots of available add-ons (Koa, Express, etc), while you'll want to stay away from 'batteries-included' or complex solutions (Nest, Strapi, etc). On the other hand, if your project's requirements are more around creating a microservice-based app where performance monitoring, swift error handling, fast scaling, load balancing, security, and managing a large team are the real concerns, going for something minimalistic like Express will help you get started quickly, but has the potential to get you into technical debt just as quick. You'll probably want something more structured, with strong support for Aspect Oriented Programming, well maintained, a framework that will not disappear off the face of the Earth when that one super-active contributor that published it suddenly gets hit by a bus. So, that Nest.js we avoided in the other project suddenly sounds like the much better option.

In short, NEVER pick your tools based on 'Top 10 blah blah' articles! I want to say that again in all caps, just to drive the point across, but my cat is watching, and I don't want to make any sudden moves. Hope you get the point.

That being said, let's get to comparing stuff. We'll start with the least important aspect: Market share. Why? Well, at least two reasons: the 'bus factor' and curiosity. What's the 'bus factor' you ask? Well, it's a tongue-in-cheek measurement of how many people from the active contributors' team would have to be hit by a bus for that project to go stale. If it has a low 'bus factor' of 2-3 (i.e. if the key 2–3 contributors lose interest in the project or leave it), the framework will fall behind others, bugs will stay unfixed for longer, new features will linger, and so on. So, you either need to fork it and take on the responsibility to maintain it yourself just to fix that 'little bug' you wanted to squash, or move on.

Unless the framework you're looking at is backed by Big Money, market share and traction are actual factors to consider when considering a framework, because they correlate well with larger communities, active support and development, and lower risk of that framework dying off.

So, how do we actually measure market share? Let's find a reliable source of comparable data. Yeah, I can already hear the laughter in the back-rows, but let's at least try...

Data sources

There are a few sources out there, and the first one that comes to mind is the number of downloads from npmjs.com itself (npmtrends.com does a great job in comparing them, you can get similar data from npm-stats.org and npmcharts.com). So, these are people who download and use those packages, right? Wrong! According to Laurie Voss (NPM cofounder), "They are mostly CI machines. [...] The overwhelming majority of downloads are builds, not individual developers". In other words, most of those downloads are done by robots that download every package for analysis, automated server builds, and mirror downloading. So, yeah, lots of smoke and mirrors, and no idea how many users actually use that framework.

Another source is the number of stars on github.com, but that's little less than a vague measure of popularity, not to mention that some frameworks might be published in other repos or dedicated websites.

We could check the number of contributors, releases, forks, dependents, and so on (moiva.io is a great data source for that). While those measure things other than market share, they may give us a sense of interest in a given technology.

Another interesting source is trends.builtwith.com, which peers at websites everywhere and tries to guess what technologies they use. If we were looking at frontend frameworks, this might have been helpful, but for the backend... not so much.

There are more data sources that look at things other than popularity (security comparison by snyk.io or dependency hell by bundlephobia.com or npmgraph ) but they are not relevant at this point.

So, how do we estimate market share? In truth, I don't believe we can do that with any passable accuracy. However, if you look at all these data sources for, say... Next or Nest on one hand, Strapi or Moleculer on the other, and Adonis or Sails on the... well, someone else's hand, you can't help but notice that they are orders of magnitude apart. In the first group weekly downloads are in the millions, for the second we're talking hundreds of thousands, for the last, tens of thousands. The same pattern emerges for Github stars, forks, dependants, and so on. So, while we won't be able to get an accurate image of market share, we should be able to group them into different pools. Yay! Let's get on with it then shall we?

Framework Pools

Side note: it's important to clarify from the get-go that while all these qualify as back-end frameworks, they are different in many respects and serve different use cases, so NEVER pick a framework based on popularity, always based on your project requirements.

Ok, great! So what's the big picture?

At the top, we have the whales pod: Express, Next, Nest, Koa, Fastify, who count their weekly NPM downloads in millions. Express is in a class of its own, way ahead of the pack, keeping steady at ~30 million, so I won't add it to the chart, as it will dwarf the others. The rest are moving up, between 1-5 mills, except for Koa, which seems to have reached its peak:

Then we have the sharks shoal, who have yet to breach the 1 million threshold: Hapi and Nuxt growing up slowly, Gatsby and Restify losing steam, while Strapi & Moleculer are far from 100k downloads per week. Meteor is probably here as well, but data is not available.

Last but not least, we have the pretty coral fish pack, which may be small in terms of downloads, but offers colorful niche features you might not find elsewhere: Total, Sails, Loopback, Feathers, Adonis, Kraken, Derby, Nodal, probably more:

So, while we cannot be sure of the exact market share, we can tell that most of it is taken by the big 5 whales (Express, Next, Nest, Koa, Fastify), with the sharks (Hapi, Nuxt, Gatsby, Restify, Meteor, Strapi, Moleculer) biting hard into it and specialised coral fish (Total, Sails, Loopback, Feathers, Adonis, Kraken, Derby, Nodal) nibbling at the niche markets. Isn't that a pretty picture?

Sailing Plan

So, how do we compare these frameworks? Well, we build the same app in a bunch of them, then benchmark them till happy ever after. But didn't someone already do this? Well, yes and no. There are benchmarks out there, but they tend to compare 'hello world' kind of apps, which only exist in university fairytales. The more developed comparisons only look at some implementations that may favor one framework over the other. What do I mean by that? Well, for a benchmark, you don't really care about security, authentication, user input validation and so on, because you know you will repeat a set of actions a gazillion times, and those actions will always be the same, so you get consistent results. Real apps, however, cannot fly without, say, user input validation, because user make mistakes and they will, every now and then, go to ../users/register instead of ../user/register, as you hope they would. Why does it matter? An app built with schema-based user input validation will be faster when built with Fastify, for example, but may do the exact opposite when built with Express. Or so they claim.

It takes a lot of time to build the same app in multiple frameworks, and a lot more if you want to build progressive versions of each of them. But we need that if we want a real-life comparison. So, that's what we'll do.

Of course, before we get to coding, we need a clear plan, proper requirements, a solid project setup that will serve as a common template and more. So, strap in for a long haul, this is going to take a while!