Express v5 | Hacker News Reader

Express v5

expressjs.com

149 pointssaikatsg39 comments

I just want to express my gratitude to Wes and the team of people who worked on this. I had to go back and read it twice that it's been 10 years since the PR for v5 was opened. That's wild! I can only imagine the immense amount of work it must have been to change the inertia of this project. Cheers to a new chapter!

> Unfortunately, it’s easy to write a regular expression that has exponential time behavior when parsing input

This footgun can be easily avoided without ripping out regex support altogether. Just switch to a regex engine that is actually regular, like re2.

See also "Regular Expression Matching Can Be Simple And Fast" by rsc [1].

[1]: https://swtch.com/~rsc/regexp/regexp1.html

Congrats to the Express team! I know there are many other Node JS web server frameworks out there but I've never really moved beyond Express because it does everything I need. Long may that continue.

I've probably been living under a rock, but I hadn't seen the "transfer the old to a private company to provide support" model before

https://www.herodevs.com/support/express-nes

It was for Rails.

https://railslts.com/

I think Flash is still being developed (as a fork of Adobe Air maintained by a 3rd party).

I believe it is a single developer at Harman who is maintaining Adobe Air. I don’t think there is any work being done on Flash. It is more so things like keeping Adobe Air builds working for latest operating systems, fixing old bugs, etc, just for purposes of keeping legacy apps functional.

You mean literally one guy? There's something bittersweet about that.

Yep, I’m pretty sure it’s just one guy and the bug tracker with 1000 issues. I’d be interested to know what Air apps are so important to Harman that they are keeping it (barely) running.

There's a bunch of enterprise stuff built on Flash and Air right? I heard China's train network ran on Flash. They also kept using XP for ages for similar reasons (maybe still are?)

Curiously, it still isn't `latest`:

https://www.npmjs.com/package/express?activeTab=versions

They have explained their reasoning in https://expressjs.com/2024/10/15/v5-release.html

    > Before going into the changes in this release, let’s address why it was released v5 on the next dist-tag. As part of reviving the project, we started a Security working group and security triage team to address the growing needs around open source supply chain security. We undertook a security audit (more details to come on that) and uncovered some problems that needed to be addressed. Thus, in addition to the “normal” work done in public issues, we also did a lot of security work in private forks. This security work required orchestration when releasing, to ensure the code and CVE reports went out together. You can find a summary of the most recent vulnerabilities patched in our security release notes.
    >
    > While we weren’t able to simultaneously release v5, this blog post, the changelog, and documentation, we felt it was most important to have a secure and stable release.
    >
    > As soon as possible, we’ll provide more details on our long-term support (LTS) plans, including when the release will move from next to latest. For now, if you are uncomfortable being on the bleeding edge (even if it is a rather dull edge) then you should wait to upgrade until the release is tagged latest. That said, we look forward to working with you to address any bugs you encounter as you upgrade.

I couldn’t upgrade PhotoStructure to v5.0.0 due to a showstopping error thrown deep in the new router (for a valid path spec). I haven’t tried the new patch release yet (nor even had time to properly trace where the issue in express was to file a reasonable issue).

Kudos to the team for pushing express forward!

The whole idea of having the response be part of the input for the route seems very 2010s.

Nearly everything else these days has a route that takes a request and returns a response. This matches HTTP more closely.

Curiously, the express model ends up being a more clean style when creating long lived writer streaming endpoints, which is becoming much more popular with LLM’s.

All that was old will be new again.

Are they using SSE? Or web sockets?

The standard set by openai and shared by everyone else is to use SSE when “stream: true” is set.

Personally I like to strip all the excess data as soon as possible and expose the raw response as a plain “transfer-encoding: chunked” stream. That way the client can decide if they want to accept each chunk as they come or simply await the whole response with limited code change.

Either way, being able to easily pass the response writer around and set headers, write, close, as needed without being tied to a single function’s control flow is nice. It can be done in the more modern frameworks ofc, but ends up being a bit more machinery required at each endpoint.

A generator function that yields responses would fit that scenario perfectly.

Not that perfectly. You still have the question of how to represent the one-time header data.

I'm imagining: yield the headers (Content-Type: text/event-stream) the first time, yield the newline-formatted event streams on subsequent yields.

I haven't done it though, I used to really like SSE (it's a little more REST-y) but the world seems to have decided on websockets.

I think that's how it works with nestjs's observer setup with rxjs. I just return the SSE stream and it works. I use it with fastify, not express.

That could work. Probably it’d be a very easy bit of middleware/express extension to write, it’s basically just wrapping the existing writeHeader, write, end, in the hot new syntax. Probably you’d get some benefits in composability, and lose some performance in the extreme.

Fastify has a model where the request handler takes both a Request and a Reply:

https://fastify.dev/docs/latest/Guides/Getting-Started/#your...

`return` statements are inflexible as they prevent doing stuff after them (like logging, which should not delay the response). I prefer express's way.

Express way is much better for writing async handlers -streaming, iterators, partial responses, keep-alive, early responses with further processing on background...

Appreciate your work on this, Wes & crew. Express is still my go to for nodejs, and it's really good to have this active governance.

Why did it take 10 years to release v5?

My guess is Express has been stable for a long time with no real need to evolve it. And old versions of node have effectively expired, so they can now drop support.

Maybe there are more API changes planned for v6 and v5 is the stepping stone?

Many thanks to the Express devs! It's been a reliable part of the stack for a long time.

For personal projects, I've been loving https://hono.dev/ The DX is fantastic and it runs in bun and CloudFlare workers. Shoutout to the hono developers!

For larger team projects, I end up using Fastify and NextJS. No real reason other than it's what's already running or other devs on the projects prefer it. But Express is always a great option.

[ I have used express in my last company, and I am asking this as a user who had used it and found it to be really pleasant to use ]

I am really confused by this. Is it really that stable ? For any software that was released this back, I would have thought its abandoned. Are there no features that the community had demanded in this time

There are a few features that were missing but it wasn't so bad. The most significant (added in v5) is proper async handler support.

Stable doesn’t mean “no room for growth.” It means, “you can count on it to work (for the features it supports) and keep working the way it does.” Absolutely the worst part of the JavaScript ecosystem is the churn.

But what churn? I started using Webpack, Express, TypeScript and React around 2013/2014. I still use the exact same stack. The only difference is that my config files are simpler now. React switched to functions/hooks but class components still work; all of my code from the beginning runs just fine and the professional projects I worked on continue to be developed.

I switched from classic .NET Framework because they deprecated WinForms and WPF was not usable and they churned the entire damn platform and replaced it with alpha-quality software. How many UI frameworks, and how much other churn happened in the past 11 years there? Way too much, everybody is so fed up that the past decade of my career consisted of rewriting desktop apps to this stack.

NPM makes it quite easy to publish anything and for others to start using it. Just don't, stick with the proven solutions. There's - adjusted for user base - the same or worse amount of churn on Pypi and Nuget. If you wouldn't choose a random library nobody uses in the C# land, don't do it in the Node land. At least the Node libs continue to grow, while the Nuget stuff continues to die.

perl 6 eat your heart out

Can you elaborate this comment? Haven't used Perl in the last 12 years, so I fit the persona of "living under a rock"

Perl 6 took like 15 years to be released, and was met with fairly lukewarm reception, sometimes very negative. It ended up being renamed because it was so different from Perl 5, so it’s now called Raku. It was a flop.

Got it! Thank you for the explanation

Read this line on Wiki: "In Perl 6, we decided it would be better to fix the language than fix the user - Larry wall"

Looks like a very good philosophical statement. Maybe there's a lesson here for other programming language

( The other Perl slogan: "Easy things should be easy and hard things should be possible" is also really good )

> It [Raku] was a flop.

From what I read, it's a living, breathing language with innovative features, core developers, regular releases and a healthy community of users. What more do you want?

so how does it compare to koa, fastify etc?

Give enough persistence, in ten years they could theoretically rewrite v5 in async rust.

Reply on news.ycombinator.com