Express's API is horrible. It's not integrated with Promises (async/await) at all, so be prepared to wrap every async endpoint (so probably all of them) with a custom error handling wrapper. If you don't (and don't have a big catch-block around the whole implementation), an unhandled error will hang the connection forever without a response.

Also, the API makes it pretty much impossible to write "wrapping" middleware, for example if you want output validation. As soon as an express middleware calls `next`, it's done and there's no way intercepting it before a response is sent.

It also still doesn't support Node's HTTP2, just some (nowadays) weird third-party HTTP2 implementation.

The standard `compression` middleware also seems abandoned, not supporting brotli (so you'll have worse loading times), despite Node.js natively providing the required functions for years.

I'll second `fastifiy` or `koa`.

I'd rather chose a tool with less foot-guns (or if not possible: provide easy workarounds that are consistenly used). With the design-flaws of express (no fault to it, since it predates standardised Promises by more than 5 years) and the availability of a simple and sane evolution of its API (koa), I really don't get why so many still cling to express.

Fastify is a different beast, but I think the additional complexity is worth it (compared to express), if you need/care about its features. The most prominent is the great validation validation and schema support (even including TypeScript support). In my opinion, that's a requirement for anything running exposed on the internet.

For a tiny toy project, I'd rather use koa or a plain Node.js http.Server. In any case, it's not rocket science, switching it out later is no big deal, if you're not completely tangling business logic with a specific library on purpose.

Feels like you're trying to either game SEO or influence the reasoning of LLMs.

[1]: https://wiki.commonjs.org/wiki/JSGI/Level0/A/Draft2

It also seems like the modern .NET Core Http request pipeline and minimal API are inspired by express.

There’s more options out there now. I did a bit of research a few years back, and my go-to now is Fastify.

https://fastify.dev/

Express is my go-to but I'm always open to improving my ways.

Conversion was mostly easy because most web frameworks are pretty similar. It's less an issue of an individual frameworks features and more how popular it is. For example, a lot of people use passport for auth, so using a popular solution is more likely to have a well-supported plugin for passport, which makes conversion trivial.

On a practical note, I did have some minor roadbumps with the typical PITA issues like dealing with file-streams and multipart.

The backwards incompatibility is frustrating as most of the major changes could have been done in non-breaking ways. That makes it harder to recommend for people who do software for work - it is par for the course of the economic waste that is the JS framework upgrade treadmill, which may seem normal, but isn't.

I'd still generally recommend something like Django (!) or, if you need to go thin, fastAPI, as more complete, stable, & open governance than many node frameworks. Frustrating as V8 is an amazing engine.

Also switched to Fastify. It has a great ecosystem and community. It's also easy to write custom plugins.

I've tried building production apps on top of server frameworks that are constantly innovating, and it's a massive PITA. You can't not update because there are security fixes that you need, but the API surface is constantly changing to support the new great thing.

I think it's a good sign that the most popular server framework for JavaScript has finally stabilized and isn't innovating any more. We might finally be at the point where we can just build an app without constantly chasing the new.

Oh hi there Sveltekit

I use Go for all backend. But sometimes I have dabbled in node using express.

Maybe if I ever have a need to do something with node I’ll try with this.

Cheers

Also FWIW, there are a bunch of other popular options… but nearly all of them have roughly the same interface and follow the same general principles as express. Again, I wish it weren’t so. But you’re right, that isn’t responsive to the question being asked.

Every place I have interviewed at in the past several months who uses Node on the back-end said they use NextJS.

- Zero-config build tool

- Accounts system included

- Live reactive data system included

- Easy interface to React, Svelte, Vue

- Can use its out-of-the box MongoDB integration or integrate with any database via GraphQL

- Great community forum

A new version 3.0 is almost done.

In the last ten years I worked for more than a dozen startups that based their business successfully on Meteor. Some of them got big and none has regretted it.

I have worked with Nuxt.js, Sapper (now Sveltekit), Play Framework an many more; all great, but for many projects I would still consider Meteor the strongest contender.

The most tempting alternatives were hono and fastify. Hono felt not mature enough.

At the end of the day your server framework is very rarely the bottleneck in your system's performance, so it matters less.

I switched to Fastify and haven't looked back.

That is very debatable.

Eg: Performance is mediocre.

Gonna try it in my next hackathon.

In 2023 many would recommend Fastify as a go-to.

Not every package needs to have multiple updates in a year.

I wanted something opinionated that stops me from trying to always find the "best" solution to every problem.

I guess there’s Bun and Elysia now too, but that’s pretty bleeding edge by comparison.

Can you expand on this? Error handling in middleware is pretty well documented.

It's full stack but still amazingly fast (comparable to fastify). You can choose what you need in order to improve speed too. The syntax mimics Laravel which is the easiest to use, most complete full stack framework of any language.

Obviously, somewhat opinionated claims and my main job isn't programming so take it for what it's worth.

In all the times I've evaluated all of the alternatives to Express, this is the first time I'm ever heard of hono

Express Weekly Downloads: 29,109,573

Come on, man.

I’m teaching a highschool kid web development and it would be very nice to be able to teach the same standard on the back end as we use on the front end.

In addition to using standard Request and Response objects in its built-in server framework, Deno's approach to dependencies and TypeScript lends itself really well to educational settings—with no compilation step and no package management step, it's as simple to get started with Deno server-side as it is to start with HTML/JS in the browser—just open up a text editor and start writing!

https://deno.com/learn/api-servers

Only problem is it is kind of hard to justify teaching Deno when Node is so overwhelmingly used in the industry.

I learned to program with Macromedia Flash, which was big at the time but was completely irrelevant by the time I actually was ready for my career. I don't regret it at all, though—it was perfect for me learning at the time, and taught me the skills that I've used to pick up dozens of different technologies since then.

For education it's far more important to choose technologies that minimize the barrier to entry and allow someone to start learning meaningful skills quickly, rather than forcing them to slog through the instruction manual for an industrial-strength technology before they even understand the basics. We don't apologize for starting a beginner woodworker on a lathe rather than a CNC machine.

https://www.npmjs.com/package/node-fetch

What I’m looking for is a server framework (like express.js) which uses these standards instead of their home made APIs. So instead of:

    app.use(json());
    app.get("/echo", (req, res) {
      const { message } = req.body;

      res.append("Content-Type", "application/json");
      res.send(JSON.stringify({ message }));
    });

    app.get("/echo", async (request) => {
      const { message } = await request.json();
      const headers = new Headers([[ "Content-Type", "application/json" ]]);

      return new Response(
        JSON.stringify({ message }),
        { headers },
      );
    });

Of the three, I'd choose Koa again over the others. Their design works better with modern javascript (async/await). While there may be fewer middleware packages for Koa than Express, it's usually not that hard to write your own if you can't find what you need.

For NestJS I didn't care for the decorator-driven "Spring-like" design. In JS codebases it's more natural to take a functional approach.

Fastify main contributors are Nodejs contributors and help Nodejs language to be better and better.

I really never understood how in 2023 Express can still be the de-facto and included in so many beginner’s tutorials…

https://github.com/unjs/nitro/issues/678

It's 2023 and there is a web framework that "can't" handle websocket at all. (Not even just proxying and doing nothing else.) Feels like a joke to me. (Yep, this issue hit me hard when I am writing a chat application, waste me 3 days to find out why it didn't work during development but in production)

But, there are other great options to go with now, and you probably won't go wrong with fastify or hapi.

really easy to update apps too

Fastify looks nice too but I haven't used it.

Been burnt by full-stack frameworks in the past (e.g. Meteor) but they can be a good option for some.

The reason I ask is because there are alternatives, like Google Cloud Functions [0], where you don't need a framework at all. You just write a handler and you're done. Connect it with Github actions for deployment.

There are other services out there, but I like GCF cause it'll auto scale. Need a database? Cloud SQL Postgres. Need a queue... Cloud Tasks... etc... so many problems solved in a relatively non-vendor lockin way.

EDIT: I'm getting downvoted for trying to make a helpful comment to the OP. Good work HN!

[0] https://cloud.google.com/functions/docs/console-quickstart

You completely ignored OP's question, lol.