JavaScript Backend Frameworks: An Honest Comparison
The question "which JavaScript backend framework should I use" has been answered the same way for almost a decade: Express for most things, NestJS if you want structure, Fastify if you care about speed. That answer is no longer wrong, but it is no longer complete. The interesting decisions have moved one level up.
I am Dimitri, the developer behind DignuzDesign. I build websites for real estate companies, architects, and property developers, and I also ship two production JavaScript backends of my own: AmplyDigest, which summarises newsletters and YouTube videos into a daily email, and the API that powers AmplyViewer, our embedded 3D property viewer. Both have made me revisit assumptions about framework choice that I had carried for years. This article is what I would tell a developer or business owner who walked in today and asked "which one should we use."
Why the framework is no longer the first question
If you only read one paragraph, read this one. Before you pick Express, Fastify, or Nest, decide where the code is going to run. The runtime - Node.js on a single box, Node.js behind a load balancer, Bun, Cloudflare Workers, Vercel Edge Functions, AWS Lambda - constrains the framework far more than the other way round. A team that picks Express first and then tries to deploy it on Workers is in for a bad week. A team that picks the runtime first usually finds the framework choice has narrowed itself to one or two sensible options.
For a real estate company serving listings to buyers across multiple countries, the runtime decision is not academic. Cold starts on a budget VPS in Frankfurt can add 600ms to a request from Singapore. The same endpoint on a global edge runtime returns in single-digit milliseconds because the response is served from the city the buyer is in. That is the kind of detail that shows up in bounce rate before it shows up anywhere else.
Express: still the default, and that is fine
Express is the framework I reach for when a project is small, the team already knows it, and the deployment target is a normal Node.js process. It is also the framework I most often inherit when I take over someone else's project.
The honest assessment: Express is mature in the way Latin is mature. It is everywhere, it is stable, and the pace of development is glacial. Version 5 shipped roughly ten years after the first pull request for it was opened, which was widely reported as a sign of how thin the maintainer pool had become. That is not necessarily a problem - mature, slow-moving software is sometimes exactly what you want under a small CRUD API - but you should pick it knowing what you are picking.
What Express is genuinely good for on the kind of projects I work on:
- An internal admin endpoint behind a marketing site, where the team has one developer and the API will probably never need more than a few requests per second.
- A WordPress or legacy backend wrapper, where you are adding a thin Node service to expose data the old system cannot serve cleanly.
- A prototype where "I need a server in ten minutes" is the entire spec.
What I would not pick Express for today: anything where I expect non-trivial growth, anything that needs typed request handlers without third-party glue, and anything destined for an edge runtime.
Fastify: the framework I wish more Express projects had been
Fastify is the closest thing to a drop-in upgrade from Express that the ecosystem has produced. Same hapi-style routing surface, similar middleware concept, but with schemas, types, and a meaningfully faster core. The official Fastify benchmarks are synthetic and the team is honest about that fact, but the headline number - tens of thousands of requests per second on a single core - is consistent with what I have seen on real workloads when I have migrated an Express app to it.
The reason I do not recommend it more often is not technical. It is that the cost of switching from Express to Fastify on an existing project is rarely justified by the latency savings alone. Most real estate websites are not throughput-bound. They are latency-bound and asset-bound. Shaving 4ms off the API response when the property image gallery is still 8MB is not where you should be spending your week.
Where Fastify earns its place: a new project, a team that already writes TypeScript, an API that needs proper JSON schema validation without bolting on a separate library, and a deployment target that is still Node.js. Schema-first development in Fastify is the closest thing the Node ecosystem has to "free" types on both request and response, and once you have used it on a project it is hard to go back to Express's hand-rolled validation.
NestJS: structure that has to earn its keep
NestJS is a framework with a strong opinion. Modules, controllers, services, dependency injection, decorators - if you have written Angular or Spring, the shape will feel familiar. If you have not, the first week is heavier than it would be with Express or Fastify.
I have shipped Nest on team projects where there were at least three developers and the API surface was going to grow past fifty endpoints. In that situation the structure pays for itself within a quarter, because new developers can find where things live without asking. The DI container also makes testing genuinely pleasant once the team is over the learning curve.
I have also seen Nest used on a two-person team building a small marketing API, and in that situation it was a mistake. The framework gives you scaffolding for a problem that small team does not have yet, and the cost is a deeper stack trace, a slower cold start, and a developer who has to learn a vocabulary they did not need. If you are curious about how Nest compares to a full-stack framework people sometimes confuse it with, I wrote about that in Next.js vs NestJS, and about squeezing the framework when you do commit to it in NestJS performance optimization techniques.
The honest rule I use: pick Nest when the team is big enough that "where does this go" is a recurring conversation. Below that team size, the structure is a tax.
Hono: the framework that changes the conversation
This is the section the original article did not have, and the reason I am writing this rewrite. Hono is a small, fast web framework built on Web Standards rather than on Node-specific APIs. It runs on Cloudflare Workers, Bun, Deno, Vercel Edge, and yes, Node. The router benchmarks are eye-catching on Workers, but the more important property is portability: the same handler runs in the runtime that fits the project.
I use Hono on AmplyDigest's API. The endpoints that fetch a user's daily digest, accept newsletter subscriptions, and process incoming emails all run on Cloudflare Workers with Hono. The whole worker bundle is under 1MB. There is no server to provision and no cold-start anxiety in the part of the world where my paying users live, because the request is handled in the data centre closest to them. A minimal handler looks like this:
import { Hono } from 'hono'
const app = new Hono<{ Bindings: { DB: D1Database } }>()
app.get('/digest/:userId', async (c) => {
const { userId } = c.req.param()
const { results } = await c.env.DB.prepare(
'SELECT id, subject, summary FROM digest_items WHERE user_id = ? ORDER BY created_at DESC LIMIT 50'
).bind(userId).all()
return c.json({ items: results })
})
export default appThat is the entire route. The types on c.env.DB are inferred from the generic. There is no separate validation step because Hono integrates with Zod or Valibot via middleware that I add only on endpoints that need it. The bundle is small enough that the Workers free tier handles many projects up to a non-trivial scale.
For a real estate website where the front-end is Astro and the backend is "a handful of endpoints" - contact form intake, lead scoring webhook, signed URL generation for property documents, server-side proxies to a CRM - Hono on Workers is the choice I would defend hardest. The combination is fast everywhere, cheap to run, and deploys in seconds. I covered the front-end half of that stack in a beginner's guide to Astro.
The catch worth naming: edge runtimes are not Node. You do not have fs, you do not have long-running processes, you do not have raw TCP. If your backend needs to talk to a legacy database over a non-HTTP protocol, or run a 90-second PDF generation job, the edge is the wrong place. That is where a Node-based Fastify or Nest service still wins.
How I actually decide on a project
The decision tree I use, in plain English:
If the backend is mostly HTTP-shaped (REST, webhooks, signed-URL handlers, light glue between APIs) and there is no hard runtime constraint, default to Hono on Cloudflare Workers. The deployment story alone usually justifies the choice.
If the backend needs long-running processes, raw TCP, native modules, or a runtime your hosting provider does not offer on the edge, drop back to Node.js. Use Fastify if the project is new, Express if the team already lives in Express and the project is small enough that switching is not worth it.
If the team is larger than three developers and the API surface will grow past a few dozen endpoints, NestJS is worth the structural overhead. Below that scale it is overhead without payoff.
If the requirement is "ship a small server-side endpoint behind a marketing site" and the marketing site is already on a platform with first-class serverless support, you may not need a framework at all - one file per endpoint is enough.
This is not the decision tree that produces the longest blog post. It is the one that produces the fewest regrets. If you want a complementary read with a slightly different framing, my earlier piece on choosing the best backend framework covers some of the non-JS alternatives I deliberately skipped here, and TypeScript best practices covers the patterns I rely on inside whichever framework I end up with.
What the original article got wrong, in one paragraph
The framing that Express, Nest, and Fastify are the three options worth comparing made sense in 2020. Starting from 2026 - It does not. Half of the new backend projects I start now never touch Node directly; they ship to Workers, Bun, or a serverless runtime, and the framework choice is downstream of that. A guide that does not at least mention this is recommending the right answer to an outdated question.
FAQ
Is Express still a reasonable choice for a new project?
For very small projects, yes - particularly if the team already knows it. For anything with growth ambition, I would either pick Fastify (if the deployment target is Node) or Hono (if it can be an edge runtime). Express's slow release cadence and limited typing story are real disadvantages on a greenfield codebase.
Is NestJS overkill for a real estate website?
For the website itself, usually yes. A real estate website's backend is rarely large or complex enough to need module/DI architecture. NestJS earns its keep on bigger backends behind dashboards, CRM-style internal tools, or multi-tenant SaaS platforms - not on the public marketing site.
How much faster is Fastify than Express in real applications?
Synthetic benchmarks show Fastify serving several times more requests per second than Express on hello-world endpoints, but in production the difference shrinks once your handler is doing real work like database calls or template rendering. The bigger practical wins are the built-in schema validation and the lower memory overhead under load.
Can I use Hono outside of Cloudflare Workers?
Yes. Hono runs on Node, Bun, Deno, AWS Lambda, Vercel Edge, and Fastly. The Web Standards foundation is what makes that possible. The Cloudflare Workers integration is the most polished one because the framework's creator works at Cloudflare, but Hono is not Workers-only.
What about Next.js or other meta-frameworks - are they backend frameworks?
They include a backend layer, but I treat them as full-stack frameworks rather than backend frameworks. If your project is a website with some API routes, a meta-framework can replace both halves. If you need a dedicated backend that several front-ends will talk to, a real backend framework is still the right tool.
Which framework gives the best TypeScript experience?
Hono and NestJS are the two with the strongest built-in TypeScript stories. Hono's typing flows naturally from its routing and middleware system. NestJS leans heavily on TypeScript decorators. Fastify has solid types when you commit to its schema-first style. Express works with TypeScript but you are largely on your own for typing requests and responses.
Closing
The frameworks that get talked about in articles are not always the ones that ship in production. Pick the runtime first, pick the framework second, and be honest about the size of your project before you import a thousand lines of structure to solve a problem you do not have yet. If you would like a second opinion on a specific stack for a real estate or property developer project, that is the kind of conversation I have weekly through DignuzDesign.
