For years, express.js has been the standard choice for building REST APIs with JavaScript or TypeScript. It has around 30 million weekly downloads (twice as much as React), and nearly all beginner tutorials recommend it. However, in today's landscape, there are now alternatives that offer better developer experiences and performance. In this post, we'll explore some of these alternatives and why you should consider them over Express.
What's wrong with Express?
1. It's Unmaintained
Express hasn't seen any major updates or new features in years, with its website last being updated in 2017.
2. It's Slow
Since Express is primarily written in pre-ES6 JavaScript, it misses out on years of performance-enhancing updates and concepts.
3. It doesn't work well with TypeScript
Express wasn't designed with TypeScript in mind and requires a separate types package to work with it. Despite this, you will still encounter lots of anys.
Alternatives to Express
Fastify
Fastify is a modern alternative to Express. It's significantly faster and has a vast ecosystem of plugins. It shares a similar syntax with Express, so most of your Express knowledge will still apply to Fastify. With @fastify/express package, you can even use any express middleware module with fastify. Fastify is the most similar to express out of these alternatives, and It's the easiest to switch to. Use Fastify instead of Express for your next API to get instant performance and DX improvements.
Hono
Hono is a simple and minimal web framework that is even faster than Fastify. Although it lacks many of plugins, it can still handle most use cases. The primary selling point of Hono is that it can be used with runtimes other than Node.js, like Deno, Bun, or Cloudflare Edge Workers. Using Hono with these runtimes can make it even faster, cheaper and easier to host.
tRPC
If you're building an API solely to consume it in a TypeScript client application (such as a React app), consider using tRPC. With this library, you can declare a function on your backend, and after a simple setup, call it on the frontend. tRPC automatically infers the input and return types of the function, resulting in TypeScript error messages and IntelliSense.
Top comments (14)
Another really nice alternative is Nitro nitro.unjs.io/
And if you need something lower and simpler you can try h3, also by unjs (nitro uses it below)
Good reminder. Still can see Express tutorials even on Dev.to.
There's also Koa which is designed to succeed Express, & is well maintained. The code also looks very similar to Express.
Koa is not well maintained. Commits are few and far between. 1 guy carries it vs. 4 for fastify. links here: github.com/koajs/koa/graphs/contri... and github.com/fastify/fastify/graphs/...
i would very much disagree with an opinion saying that a framework is bad because it's not actively being maintained, for example express is truthfully not being updated each month but that's because they have nothing to fix, it's reliable, working, almost 0 bug issues, i'd say express is better than any actively maintained alternative just because it doesn't need to be fixed, it's working. and no matter how shiny any other framework is until it's reliable and it's code base is rarely updated it's still going to be a second choice after express, one of the few frameworks you can use without fear.
When node changes, express has to as well. If the ecosystem moves forward, express has to as well. Stagnation leads to death.
I would still have to disagree; Node, although one of the worst languages in this aspect, doesn't change its APIs that much. It just adds to them or fixes some security issues. The serious security issues are below 60, counting since 2012, and they were all issues that all active versions and even non-active versions had. So, it doesn't really matter if you're using Node 20; you would still live through one or two vulnerability discoveries in OpenSSL, V8 memory, filesystem, and more. Of course, you would have to update to an active version just for the sake of updates. Up to 2023, v14 was still active, so v14 was just like v20 in terms of security updates and bug fixes. Now it's dead, though.
With that said, do you really think that not implementing arr.at(-1) instead of arr[arr.length - 1] matters? I don't think so. We want reliability, security, and performance. Sadly, not much is gained in these areas with each update. Let's take v20; first, they created a broken runtime, and now they want to patch it with --experimental-permission. And that's not even something Express can use. You can use it with Express if you want, but it wouldn't need any updates from the side of Express. Most other updates we had since v16 or v17 are all just additions or external changes to the runtime itself.
If you criticize Express for the lack of activity, I'm assuring you there are a lot of devs like me who are happy to see no bugs/few bugs in the issues tab. If you criticize it for not implementing the new stuff and that it's slow, then you should've used GO, C#.... The version of Node you use is your choice; Express will always be more secure than most frameworks, break less. That's what I personally want.
But if you're criticizing it for not using HTTP/2, then I'm with you. If you criticize the middlewares that attach a million unnecessary things to the req/res objects, then I'm with you. If you criticize its although rare security vulnerabilities, then I'm with you.
But just changing something for the sake of change is a problem, not a solution.
Fair point about change for sake of change being a problem.
I was reading someone's reddit comment about fastify vs. express and there are big DX benefits to fastify. I quote:
"I have used express since 2013. A year and a half ago our company began building our new services with node and I ended up selecting fastify.
I prefer fastify’s encapsulation design, the plug-in system, and it’s support for json schema and fastifys lifecycle design. It also works nicely with type box and typescript
Express isn’t nearly as featureful as fastify anymore or as fast.
Fastify wins by a long shot for me."
Source: https://www.reddit.com/r/node/comments/zwcl6j/comment/j1w379u/?context=3&rdt=41318
i agree, Fastify wins in DX, Performance and even plugin ecosystem, i used it couple of times and it's great, it offers far more than what he/she mentioned, almost all frameworks (the main ones) are great, i've only commented on this post because the writer has done a bad job at explaining why we need to abandon express and his only criticism is that it's dead, if that's true then most packages in Golang are dead and by his/her logic google is dump for using dead packages.
I agree, the post is written badly
@inerkyjad do you run Debian by any chance?
Good job
This article has no evidence, links to no evidence, and so is poorly written.
Totally agree!
I wonder why this article isn’t exploding like mine here:
dev.to/sebastian_wessel/stop-using...