7 ms·
Ask HN: Is Express still "de-facto" for building Node back ends?
It's been a while since I've last used node to build a backend, and the last time I did Express was the go-to solution. Is that still the case?
I don't have much time to do too much research and I usually default to the most popular solution in such cases.
- tootie 3y agoNitro 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.
- mmis1000 3y agoUntil it support websocket, I think it is simply a "NO". https://github.com/unjs/nitro/issues/678 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)
- lolinder 3y agoI tried Nitro soon after Nuxt 3 came out and was very unimpressed. The whole thing felt half-baked, with missing features and essentially zero documentation.
- jcpst 3y agoI used to do more node work, and that was mostly pre v4. Express was the go-to. 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/ https://fastify.dev/
- afidrya 3y agoFastify is absolutely fantastic. It has the concept of "type providers", allowing you to pair it with fastify-type-provider-json-schema-to-ts (for JSON schemas) or another typing system of choice, such as Zod, to obtain strongly typed queries, request bodies, and responses in handlers with TS types derived on the fly at compile time. It also validates data returned from handlers to conform to schemas, reducing the likelihood of accidentally leaking sensitive information. And it's faster than Express, even with validation.
- omneity 3y agoCould 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.
- lmeyerov 3y agoWe like fastify for structure, types, perf, and maintainer responsiveness. I can count how many bugs we have had. 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.
- dutchdev 3y agoIs 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.
- lolinder 3y agoWhy 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.
- kibibu 3y ago> I've tried building production apps on top of server frameworks that are constantly innovating, and it's a massive PITA Oh hi there Sveltekit
- lgkk 3y agoNice. First time I hear about fastify. 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
- holden_nelson 3y agoIf you don’t have time to do research then surely you don’t have time to learn a new tool, right? Just use Express.
- scsteps 3y agoWoah that’s a very valid point
- vore 3y agoOr maybe you want to figure out what the best thing to learn is before committing to it?
- IAmGraydon 3y agoAsking others isn’t research?
- lwhi 3y agoI think the reference relates to the actual words used in the submission.
- lwhi 3y agoIf I were a cynical man, I'd say this whole submission reads like an advert for fastify.
- pier25 3y agoIt's still the most popular but for the past couple of years it hasn't seen any major updates and some people question if the project is abandoned. I switched to Fastify and haven't looked back.
- dsauerbrun 3y agosome people use the word abandoned... some people use the word "finished"
- pier25 3y agoHaven't the team been working on v5 for years?
- jwlake 3y agoindeed. I hate projects that make changes for no reason. If it does everything its supposed to do and does it well, it's just done. Go work on something else.
- pier25 3y ago> and does it well That is very debatable. Eg: Performance is mediocre.
- eyelidlessness 3y agoIt’s neither. There are still occasional commits to its pre-release branch, last I checked. It’s more fair to say it’s stable than anything else.
- invitrom 3y agoProven, reliable and still good.
- roblh 3y agoIt seems like it. There are alternatives like Koa and Fastify, but none of seem to strike quite the balance that express does. I pray that one day express 5 will get released and they’ll finally fix the whole async middleware not handling errors properly thing though. That’s gotta be one of the most annoying quirks that has just been quietly sitting there untouched for years at this point. Maybe one day. I guess there’s Bun and Elysia now too, but that’s pretty bleeding edge by comparison.
- contextnavidad 3y ago> async middleware not handling errors properly thing though Can you expand on this? Error handling in middleware is pretty well documented.
- roblh 3y agoAnytime an error happens inside an async middleware in express, you have to explicitly catch it and pass it directly to the `next` function, otherwise it'll just disappear and any kind of error logging middleware you have later on will never see it. In synchronous functions any error is passed automatically. You can write more middleware to address this, or just manually catch everything, but it just means more boilerplate. There's no reason to expect different types of middleware to have different behaviour unless you already know. It's not catastrophic, but I expect more consistent design from such an established library, especially considering how long this has been an issue.
- Zealotux 3y agoYes it is, Bun is promising but still in early stage. If you're looking for a battle-tested framework I would suggest Nest.js, which supports both Express and Fastify in a virtually transparent way.
- k__ 3y agoI read, Elysia is the hot thing on Bun right now Gonna try it in my next hackathon.
- jokull 3y agoNo - please check out Hono https://github.com/honojs/hono https://github.com/honojs/hono
- bdcravens 3y agoThe presence of alternatives doesn't mean something isn't the "de facto". In all the times I've evaluated all of the alternatives to Express, this is the first time I'm ever heard of hono
- _9hey 3y agoHono is the new hotness. It can run across , deno, bun, cf workers, etc etc it’s not locked to node
- jjordan 3y agoHono Weekly Downloads: 46,831 Express Weekly Downloads: 29,109,573 Come on, man.
- zigzeira 3y agoI believe this is not an appropriate comparison. Hono is a relatively recent project when compared to the age of Express.js.
- luastoned 3y agoExpress is outdated (in terms of active development). I prefer Fastify since it has very good schema validation and error handling built in.
- jdhehxhsv 3y ago[flagged]
- deleted 3y ago[deleted]
- colesantiago 3y agoLast I checked, Express is extremely slow and will significantly impact your SEO if you're a content business and doesn't really scale very well if you get huge amounts of traffic like I have. These days I use Go, Deno or Crystal which is much faster. For hosting I recommend Cloudflare Pages, Vercel, (maybe Netlify) and Render.
- bdcravens 3y agoThe frontend impacts your SEO way more than your backend, especially if you're using a typical framework. Additionally, things like your database (more specifically, your schema and your queries) will impact the speed of your backend more than any particular library.
- luastoned 3y agoExpress by itself isn't slow at all, neither does if affect your SEO. You completely ignored OP's question, lol.
- colesantiago 3y agoAnd the answer is that express and node is 'de-facto' slow. Nobody building a serious application in 2020 should consider express anymore for building a production grade application.
- bjablonski 3y agoI'd definitely suggest at least considering Nest.JS. There's totally nothing wrong with Express (or Koa or Fastify) projects, but Express based projects tend to share problems with all others based on minimalistic-based frameworks - no skeleton means tons of discussions about favorite ORM, Logger, Validation, whole story about service vs helpers etc. If I can skip it, I always do. Decision paralysis can be a killer.
- WXLCKNO 3y agoNest is definitely more polarizing than fastify/express etc but I love it. I wanted something opinionated that stops me from trying to always find the "best" solution to every problem.
- Rapzid 3y agoI mean, it depends on who your asking. Express has effectively been abandoned. In 2023 many would recommend Fastify as a go-to.
- lolinder 3y agoHas it been abandoned or is it just done? It's still sitting at 29 million downloads a week, so while it doesn't get frequent updates I wouldn't call it abandoned unless there are major security flaws that are being left unaddressed. Not every package needs to have multiple updates in a year.
- russianbandit 3y agoIsn’t v5 of Express expecting to drop soon (albeit, that has been the promise for a while now)?
- Rapzid 3y agoWho knows. They were working on http2 6-7 years ago and it hasn't arrived. I was under the impression the primary dev stopped working on it and some people were able to get maintainer access for security updates but that's about it. Maybe some people re-started development but not sure and Fastify has an express compatibility layer so it's not compelling to me. 2023 I'm only thinking about express if a legacy app using it falls in my lap.
- husarcik 3y agoI'd say adonis is the best now as you can iterate to a full product very quickly. 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.
- douglasisshiny 3y agoNot a fan of the class-based approach.
- husarcik 3y agoFair enough. Most JavaScript code seems to avoid classes so it can be a little jarring if you're not use to it.
- shados 3y agoEven being used to it (from other languages), it's super jarring in JavaScript because it's redundant. JS has other, better ways to achieve the same result, so it's generally a step down just to be more familiar for non js devs
- johnchristopher 3y agoWait... wasn't koa supposed to replace express ? What happened to it (and hapi) ?
- mjmasn 3y agoI tend to use hapi (https://hapi.dev https://hapi.dev) instead of Express if I need to write a quick backend for something these days. 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.
- zigzeira 3y agoI've never used Hapi, but I followed the process when Walmart wanted to discontinue the project. Unfortunately, even though it's quite an interesting backend framework, I don't see the need to use it with the existence of other solutions.
- runarberg 3y agoFollow-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 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 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 same standard on the back end as we use on the front end.
- chrisweekly 3y agohttps://Remix.run https://Remix.run embraces web standards, it's exactly what you're looking for.
- lylejantzi3rd 3y agoIsn't that what node-fetch is for? https://www.npmjs.com/package/node-fetch https://www.npmjs.com/package/node-fetch
- runarberg 3y agoThe fetch API is implemented in node and is provided as globals since node 18. So node-fetch is effectivly obsolete at this point. 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 })); }); I could write something like: 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 }, ); });
- lolinder 3y agoI think Deno could be a good choice for that—it's an entire server side JavaScript runtime built around the idea of using web standards instead of server-specific code. 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 https://deno.com/learn/api-servers
- chrisweekly 3y agoIf you're sure you want a traditional strictly-serverside backend, Fastify is like an improved Express. But your project's success might depend on going beyond a hasty sanity-check that presupposes app architecture. What's your front-end look like? For React, using a framework like Remix (or Next.js) that spans client and server runtimes, could make Fastify/Express potentially moot.
- KomoD 3y agoThere's Fastify but I still prefer Express.
- jjordan 3y agoWhat is it about Fastify specifically that makes you lean more toward Express?
- ThrowAway1922A 3y agoI love threads like this, it's so stereotypical JS. OP asks if it's the de-facto choice which it objectively is, but everyone recommends their pet project or favourite library instead.
- elaus 3y agoTo be fair for me the first 10 root comments almost all recommend Express or Fastly, no obscure pet projects or anything. So there does seem to be a pretty clear consensus.
- eyelidlessness 3y agoFWIW I was planning to respond “yes, it is the de facto solution, even if I wish it weren’t” and probably leave it at that. Granted I don’t have my pet project to recommend (I left it behind with previous employer), and maybe I would if I had it to recommend. But I’d still acknowledge first that express is the de facto solution. 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.
- preommr 3y agoDemonstrably untrue. Out of the 21 top level comments, all but two mentioned one or more of: fastify, express, kora, hona, adnos, bun/elysia Half of them recommended Fastify. Other results: 3 express, 2 hono, 2 bun/elysia, 1 adnos
- catlover76 3y agoBy what measure is it objectively standard? I can't imagine someone starting an ExpressJS application today. Every place I have interviewed at in the past several months who uses Node on the back-end said they use NextJS.
- flagged24 3y agoNext.js doesn't exclude ExpressJS. It's actually not that uncommon for self hosted Next.js instances to have a custom server setup with ExpressJS.
- willsmith72 3y agoI 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.
- tannhaeuser 3y agoNot 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 https://wiki.commonjs.org/wiki/JSGI/Level0/A/Draft2
- jcpst 3y agoIt’s an approach I really enjoy. Back in the day express referred to itself as a sinatra-style library (ruby). It also seems like the modern .NET Core Http request pipeline and minimal API are inspired by express.
- mardifoufs 3y agoWhat happened to common.js?
- tannhaeuser 3y agoNothing really, it completed its mission of a portable environment across SSJS, and saw quite some implementation effort. The commonjs module loading convention (but not necessarily the particular core modules such as for fs, http, etc.) became a standard for bundling in browsers even, before ECMA standardized ES modules, and their dynamic nature make them being used on Node.js until today, such as for expressjs. But around 2010, Node.js became the leading, then the only relevant SSJS platform.
- NylonMeltdown 3y agoMaybe 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`.
- lolinder 3y agoThe thing is, express's foot guns are well known and well documented, and you basically just enumerated them. If you pick another framework then you'll be left exploring its footguns on your own. That may or may not be worth it to you, but it's not obvious to me that choosing the well-known framework is a worse choice than choosing the ones that try to solve its problems but don't yet have the rough edges discovered and documented.
- NylonMeltdown 3y agoI think there's a slight difference between doing something that nobody's ever done before and just choosing a less travelled path. In any case, I'd rather not use the tool with well-known foot-guns, hoping that all developers in the project (and future ones!) do know these foot-guns as well. 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.
- gentleman11 3y ago
- latchkey 3y agoAll of the responses talk about a framework and I know you're thinking you need one too. But, I'm more curious about your plans to host things. 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 https://cloud.google.com/functions/docs/console-quickstart
- debug-desperado 3y agoI've been on various projects that utilized Express, Koa, and NestJS (which wraps Express or Fastify). 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.
- citrusx 3y agoExpress is still the "go-to" now, because it's the rare case of a Node library that's stable, battle-tested, and doesn't change much. (Yes, the maintainers having not been able to release v5 has actually been a sort of advantage.) But, there are other great options to go with now, and you probably won't go wrong with fastify or hapi.
- austin-cheney 3y agoI just use the native Node APIs and write the tools I need when I need such tools. The really tough problems I would need something like Express to solve for are not solved by something like Express.
- jeromemacias 3y agoFastify is definitely the new Express for me. I use it in production since many years ! 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…
- vikR0001 3y agoYou might want to look at https://www.meteor.com/ https://www.meteor.com/. There aren't a lot of alternatives to it that do such a good job of providing its benefits: - 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.
- eluck 3y agoI wouldn't consider Meteor a "backend" tool, but it is still great for a quick start and rapid development. If you're just establishing your project and there's no strong development expertise and culture in your company, Meteor will suit you quite well as it removes the hurdle of making a ton of decisions that will affect your productivity.
- softwarerero 3y agoMeteor is fullstack, so you can reuse code on the front- and backend, which is nice for validation and business logic. 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.
- maxsavin 3y agohttps://www.hackernewsdaily.com https://www.hackernewsdaily.com is built on Meteor - haven't touched it for years and its working great really easy to update apps too
- thehutchery 3y agoI feel like it's a matter of the beast you know vs working with something new. A lot of packages of been created to work with express so when working with it you get a larger ecosystem available to you. However, I think it's akin to React for frontend where just because it's the standard for node these days doesn't mean it should be