Live data from Hacker News

Ask HN: Is Express still "de-facto" for building Node back ends?

news.ycombinator.com

41–50 of 100 posts

Re: Ask HN: Is Express still "de-facto" for building Node back ends?

#41
post #23

Earlier quoted context omitted.

Could you share a bit more of your reasoning for choosing Fastify over Express and how was your experience since you switched? Express is my go-to but I'm always open to improving my ways.

Is Express.js still even maintained? Does it still adds new features? Also switched to Fastify. It has a great ecosystem and community. It's also easy to write custom plugins.

Why does it need to add new features?

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.

Re: Ask HN: Is Express still "de-facto" for building Node back ends?

#43
post #18

I mean, it depends on who your asking. Express has effectively been abandoned. In 2023 many would recommend Fastify as a go-to.

Isn’t v5 of Express expecting to drop soon (albeit, that has been the promise for a while now)?

Re: Ask HN: Is Express still "de-facto" for building Node back ends?

#45

Follow-up question: Is there any backend framework which uses the fetch API. That is, where requests are standard Request objects ( https://developer.mozilla.org/en-US/docs/Web/API/Request ) and where you send (or return, or yield) standard Response objects ( https://developer.mozilla.org/en-US/docs/Web/API/Response )? I’m teaching a highschool kid web development and it would be very nice to be able to teach the sam…

https://Remix.run embraces web standards, it's exactly what you're looking for.

Re: Ask HN: Is Express still "de-facto" for building Node back ends?

#46
post #31

Nitro is the server baked into nuxt 3. I feel like web server frameworks have all been circling around the same set of features for like 10 years though.

Until it support websocket, I think it is simply a "NO".

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)

Re: Ask HN: Is Express still "de-facto" for building Node back ends?

#48
I did the same research a few months ago. There are a lot of really cool alternatives which is fun and exciting, but at the end of the day I went with express. It's super stable, huge community, endless online tutorials and content.

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.

Re: Ask HN: Is Express still "de-facto" for building Node back ends?

#49
Not only is expressjs de-facto, it actually is a community design from before Node.js existed, with earlier implementations (connect, jackjs), including on non-Node.js SSJS-platforms; cf. [1]. Moreover, an expressjs/JSGI middleware can plug-in and directly run off the Node.js core http API, without the additional expressjs routing, etc.

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

Re: Ask HN: Is Express still "de-facto" for building Node back ends?

#50
Maybe it's still standard, but if you don't want to shoot yourself in the foot, just stay away from it.

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`.

Post reply on HN