Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 100 posts

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

#71

Post by preommr »

omneity wrote: post #23
jcpst wrote: post #2

I 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/

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.

Fastify has a nice modular architecture, decent popularity, growth trending upwards (so more future proof), first-class support of async and typescript (it's not cobbled on like it is with express).

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.

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

#72

Post by lolinder »

runarberg wrote: post #70
lolinder wrote: post #64

Earlier quoted context omitted.

I 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…

Yes, this is exactly how I want to write my servers while teaching web-development. Only problem is it is kind of hard to justify teaching Deno when Node is so overwhelmingly used in the industry.

I think high school is too early to be thinking too hard about what is used in 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.

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

#73

Post by mardifoufs »

tannhaeuser wrote: post #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

What happened to common.js?

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

#74

Post by gentleman11 »

NylonMeltdown wrote: post #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…

Could you elaborate on why Koa and fastify are better? Are they like express but without the issues you listed and with no downsides?

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

#75

Post by runarberg »

lolinder wrote: post #72
runarberg wrote: post #70

Earlier quoted context omitted.

Yes, this is exactly how I want to write my servers while teaching web-development. Only problem is it is kind of hard to justify teaching Deno when Node is so overwhelmingly used in the industry.

I think high school is too early to be thinking too hard about what is used in 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 educat…

Indeed a very good point. Perhaps I’ll pick up Deno for my next set of students

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

#76

Post by lwhi »

gentleman11 wrote: post #74
NylonMeltdown wrote: post #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…

Could you elaborate on why Koa and fastify are better? Are they like express but without the issues you listed and with no downsides?

What is this questioning.

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

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

#77

Post by NylonMeltdown »

gentleman11 wrote: post #74
NylonMeltdown wrote: post #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…

Could you elaborate on why Koa and fastify are better? Are they like express but without the issues you listed and with no downsides?

I consider Koa to be a sensible evolution of express (even by the some of the authors).

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.

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

#78

Post by NylonMeltdown »

lolinder wrote: post #54
NylonMeltdown wrote: post #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…

The 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…

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

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

#79

Post by catlover76 »

ThrowAway1922A wrote: post #44

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

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

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

#80

Post by tannhaeuser »

mardifoufs wrote: post #73
tannhaeuser wrote: post #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

What happened to common.js?

Nothing 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.
Post reply on HN