Consider removing express from replacements

[mcollina]

Maintaining a framework is hard, and very often is the result of a lot of compromise.

Marking a framework like Express "to be replaced", while maintainers ships new releases, and millions of developers use it every day, is not good for the community, or for the trust you have been given.

It's not new tech, and keeping it up is hard. These kind of pages makes the lives of maintainers harder, cause burnout, and ultimately give a worse outcome to the community.

I always thought this initiative as a force of good in the ecosystem because it helps with replacing a lot of abandoned or superseded modules, but Express is not either of them.

---

Disclaimer: I worked hard together with others to resurrect express and make it viable again, keeping the whole community safe. I also authored Fastify, and I could have been pushing for a similar initiative a long time ago. I didn't do it, because I deeply think it's not good for the community.

[bjohansebas]

Hi! I don't have a neutral position on this because I'm part of the Express team, and we work very hard to keep Express secure, reliable, and moving in a positive direction.

From my perspective, it's honestly discouraging to see Express on that list, just as it is to see body-parser there. Express will continue to prioritize security and stability above all else. We intentionally choose stability over rushing changes, even when that means moving more slowly.

We're also a small group of unpaid volunteers maintaining a large part of the JavaScript ecosystem in our free time. Things like this inevitably add pressure. At the same time, we're investing a lot of effort into researching how to modernize Express without breaking existing applications, because preserving compatibility is one of the project's core values.

Labeling Express as something that should be replaced by "better alternatives" ends up hurting the reputation of a project that continues to serve a huge part of the ecosystem. Open source isn't a race between companies where everyone has to ship features as quickly as possible. Different projects optimize for different goals.

I think e18e does a lot of good work. For example, encouraging projects to replace small utility dependencies with native platform APIs where it makes sense is genuinely beneficial for the ecosystem and can improve security and maintainability. I fully support efforts like that.

Disclaimer: This comment reflects my personal opinion only. It does not represent the views of the Express team.

[styfle]

I worked hard together with others to resurrect express and make it viable again

Is it possible the recommendation was added prior to its resurrection?

It sounds like the label should be removed now that express is maintained.

[joaopedrodcf]

The issues is from 2 years ago #159 and the replacement was added 4 months ago #412

[43081j]

thanks for the discussion. this is a living data set we add to and remove from as time goes on - so much of this can be summarised as "we should remove express from the data set".

express is 2MB, CJS, and has a plethora of deep polyfill dependencies.

these are the reasons for the original proposal to add it to the data set.

there has been a slight miss on our side as a community - in that express has changed since the issue was first created and maintainer activity has seen a rise.

the points above, though, still stand today.

under normal circumstances, that would be enough justification to keep it in the data set. however, since express is a "framework", I can understand why it might make sense to remove it.

before we take any action, ill wait for some more opinions (in particular @e18e/core, but anyone really).

meanwhile, @bjohansebas do you know if there are issues we can follow or help with as a community for these:

• removing qs or moving it to an optional peerDependency (this removes the "deep polyfill dependencies" and ~700KB of express' install size)
• migrating to ESM only

[dreyfus92]

+1 to removing it 🫡

the technical points stand, but the framework distinction is the right lens. mr works best when the swap is mostly drop-in.

separate from removal, would love to see the qs / ESM work land 🤘🏻 happy to help from our side where we can.

[AlexanderKaran]

Before getting into the details, I want to say that I love Express. It was my introduction to Node, and I have many fond memories of it. I am also really excited to see progress happening again.

That said, I am a little nervous about the argument that “since Express is a framework, it makes sense to remove it.” Where does that end? I can see that sliding into, “X is a framework, so it is okay for Y to exist,” which feels at odds with our guiding principles.

I lean toward removing it, but I would feel more comfortable if we made further progress, especially around making qs an optional peerDependency. I do not think that everything should be included just because something is a framework; that feels like it moves us away from our guiding goals.

Happy to give time to help get it done as well.

[mcollina]

The key reason why frameworks are not easily replaceable is that because they are the key of an ecosystem. Replacing a framework is extremely hard: the missing ecosystem is the primary blocker.

As for express, none of the options proposed here are good replacements, as they lack the depth and maturity of that ecosystem. There are tens of thousands of modules that are compatible with express. (No, even Fastify does not have that same depth, as much as we tried).

Regarding the current problem, the whole https://github.com/jshttp org is full of modules to modernize. On a fun note, they shipped a new ESM version of cookie, which we adopted in Fastify... that broke our users in AWS Lambda, because they disable require(esm) there.

---

Would you like to schedule a call to discuss? I think there is a bit of nuance that maybe we are not passing through here.

[bjohansebas]

migrating to ESM only

We're gradually migrating to ESM, and you can already see that with packages like cookie and content-disposition. raw-body has also made that move. Express itself will follow once we officially start Express 6 development, since we'll already be requiring Node.js 22 because of those packages anyway. 🙂

We also don't have tracking issues or PRs for this. If I open an issue, it quickly attracts 30 AI-generated PRs, and we end up spending more time closing them than it would take to just open the real PR ourselves when we're ready—even after we've already said there's an existing plan for the work. That's just the reality of OSS these days.

So when the time comes, someone from the team will simply open the PR. It's unfortunate that open source has evolved this way, but for changes like these it's honestly better than spending our time triaging AI-generated PRs. Of course, contributions that aren't AI slop are more than welcome. 🙂

And if anyone wants to help out, we're on the OpenJS Slack.

removing qs or moving it to an optional peerDependency (this removes the "deep polyfill dependencies" and ~700KB of express' install size)

As for qs, yes, one of those options will happen. Personally, I'd prefer to remove it entirely, but that's just my opinion—we need to reach a consensus within the project. My goal would be to remove that built-in option and have users extend the query parser themselves, as Express has allowed since Express 4. If that doesn't gain consensus, then making it an optional peer dependency is probably the smartest approach for now.

Also, for body-parser, the plan is to introduce a generic parser, so we could simply remove the extended option for URL-encoded parsing there as well. That's still up for discussion, but it's something I can bring to the team. If that doesn't happen, then making qs an optional peer dependency is still a reasonable fallback, even though I don't think it makes much sense to keep it bundled.

I think I'm going to open a general discussion issue in our project discussions instead of continuing to split the conversation across individual repositories. The discussion has become too fragmented at this point, which is why I didn't send over all the existing issues and PRs, they're scattered across different repositories. I'll link the discussion later. 🙂

That said, I am a little nervous about the argument that “since Express is a framework, it makes sense to remove it.” Where does that end? I can see that sliding into, “X is a framework, so it is okay for Y to exist,” which feels at odds with our guiding principles.

I understand your point that frameworks shouldn't necessarily be treated differently just because they're frameworks. If you don't think that's the right direction, that's completely fair—it's your project and your goals, and we respect that.

From the Express side, though, we've been steadily improving the dependency tree, and at this point qs is really the last remaining piece. The other 30 dependencies are going to stay because each one is designed to be reusable across the ecosystem. As Matteo mentioned, cookie is used by Fastify, and the same is true for many of the others—they're general-purpose modules. That's why we don't take the same approach as Hono and aim for zero dependencies. 🙂

Also, seeing 30 dependencies isn't necessarily a bad thing. From a security perspective, it's actually an advantage: if a vulnerability is found, we only need to update a single dependency, and the entire ecosystem benefits from that fix without every framework having to implement and maintain its own copy.

Regarding the current problem, the whole https://github.com/jshttp org is full of modules to modernize. On a fun note, they shipped a new ESM version of cookie, which we adopted in Fastify... that broke our users in AWS Lambda, because they disable require(esm) there.

@mcollina, could you share the issue with us, maybe in Slack?

Also, jshttp and Express's philosophy are really focused on plain Node.js rather than other runtimes, which is why we're making these ESM-related changes. That said, it's still something we're interested in from the Express side, so we'd definitely like to know more about it. 🙂

[MaxwellCohen]

Under the current setup of e18e's module replacement model, Express should be removed because the module replacement appears binary (unreported or replace with a smaller/faster option). This model works great for simple libraries, but not frameworks. I do not know where the line between library and framework should be drawn.

As an application developer, I would love a resource to help me objectively pick high-performing dependencies (libraries and frameworks) for my application. When I look at reviewing a depency it falls on this scale:
0) Don't use this depency - ie it should just be inlined, or there is a major reason to not use it, like security.

1. Replace this depency with a modern solution - there is a drop-in replacement that you can use.
2. Consider replacing the depency - this dependency has a lighter solution that can be used instead, but requires some amount of work to replace.
3. You probably should not start a new project with this dependency, but it is not worth changing or too hard to change in an existing project.
4. The dependency is good - this dependency follows best practices but has not been examined for optimizations or has architecture limitations that prevent it from being the best in class.
5. "Best of best" - this dependency has been examined, optimized, and benchmarked to be top performing in its class.

e18e's current module replacements model is a great solution for level 0 and 1 dependencies, but it starts falling apart for levels 2-5.

Using this scale, depending on the project, Express can be anywhere between 1/2 (very simple projects) and 3 (very complex projects) today. It looks like the Express team is working on getting to 4 or 5. Based on Architecture limitations or backward compatibility needs, I do not know where Express can end up. If there is anything that I can do to help the e18e team, the Express team, or Other teams make the web faster and more modern, please let me know.

[bjohansebas]

Using this scale, depending on the project, Express can be anywhere between 1/2 (very simple projects) and 3 (very complex projects) today. It looks like the Express team is working on getting to 4 or 5. Based on Architecture limitations or backward compatibility needs, I do not know where Express can end up. If there is anything that I can do to help the e18e team, the Express team, or Other teams make the web faster and more modern, please let me know.

We're currently exploring a rewrite of the router to make it faster. I already have a poc, but there's still a lot of work to do. The plan is to break it down into smaller PRs, and I'm still discussing the approach with the team. We're taking it step by step.

We're also looking at how to support QUIC in the future, as well as a server fetch model similar to what Hono provides, since that's likely the direction Node.js will continue moving toward. So there's still a lot of work to do, both in Express itself and across the ecosystem.

On top of that, we're continuing to optimize our dependencies even further, just as we've already done with packages like cookie, content-disposition, and others. 🙂

[bjohansebas]

Here's the tracking issue for qs expressjs/discussions#511. There are probably more issues scattered around, but honestly there are just too many discussions about the same topic.

This issue is intended to be the central place for the broader discussion about removing opinions around parsers and letting users choose whichever parser they want.

[43081j]

that broke our users in AWS Lambda, because they disable require(esm) there.

sounds like a problem they need to solve. blunt but true i think. those consumers should enable require(esm) or pin to the older CJS version until they can.

Would you like to schedule a call to discuss? I think there is a bit of nuance that maybe we are not passing through here

its a fairly large community so this is difficult to do in a constructive way. but i'd be up for hopping on a call some time (as the person who is currently filling a "devrel"-like position in the community), and can try bring some folk along.

its worth assuming we do thoroughly understand this though and know where your point of view is. don't think it is lost on the community - many of us fully understand.

We also don't have tracking issues or PRs for this. If I open an issue, it quickly attracts 30 AI-generated PRs, and we end up spending more time closing them than it would take to just open the real PR ourselves when we're ready—even after we've already said there's an existing plan for the work. That's just the reality of OSS these days.

i will DM you about this. i fully understand but its important that the e18e core at least has this line of comms with you and the other express maintainers, to be able to correctly manage related issues/PRs. so even if not public - at the very least, we should be talking to each other to know what is upcoming i think.

From the Express side, though, we've been steadily improving the dependency tree, and at this point qs is really the last remaining piece.

this is my understanding too. in fact, the last major already did the work but by accident (or just unknowingly) left it as a dependency when it absolutely shouldn't have been. it literally is not used by default, hence not a dependency anymore. its the definition of an optional peer and only isn't marked as such by accident.

if we can only get through the red tape of changing a bit of JSON to what it was always meant to be - express is a lot simpler and a lot smaller. the body-parser stuff will follow, one step at a time.

tldr my opinion

we need to decide based on the general consensus in this discussion - but my opinion is we should:

1. remove express from the data set (under the assumption it will eventually drop qs)
2. help the express team (as a community) drop qs amongst other things
3. tighten the loop between the core team + the express team

on the last point, the core team are the ones understanding the various discussions to make a decision on what action to take. its important those people are "in the loop", especially if much of your roadmap is invisible (as you said, much of it isn't tracked on purpose to avoid AI chaos). so we really should bring openjsf + e18e closer in general i think, at least for understanding roadmap.

[bjohansebas]

on the last point, the core team are the ones understanding the various discussions to make a decision on what action to take. its important those people are "in the loop", especially if much of your roadmap is invisible (as you said, much of it isn't tracked on purpose to avoid AI chaos). so we really should bring openjsf + e18e closer in general i think, at least for understanding roadmap.

Sorry if I gave the impression that we're working on things privately. Some things are, of course, for security reasons, like security reports, but that's about it.

The problem is that something as simple as opening an issue to track an ESM migration immediately attracts PRs that we don't want yet, regardless of what we write in the issue. That said, maybe we could have a tracking discussion in the Discussions repo instead, since at least that won't attract dozens of PRs.

Most of our work is public and spread across different places: the OpenJS Slack (#express), discussions in the various repositories, and for larger changes that affect the broader ecosystem rather than just Express, in the Express Discussions repository, for example, the effort to stop depending on debug 🙂 expressjs/discussions#509 (not replace it, because that's probably not going to happen, but simply stop depending on it directly).

Once we have a clearer roadmap for Express 6, after consolidating all those PRs and issues, I'll be happy to share it with everyone, whether on Discord or here—whatever works best. It's just still a work in progress.

We also have public meetings that anyone is welcome to join if they have the time. That's where we usually get feedback from the team and discuss upcoming changes.

If there's something you'd like to discuss constructively, just let us know in the OpenJS Slack channel I mentioned. A heads-up is appreciated, since we often have meetings dedicated to specific topics, and it helps us plan the agenda so nobody's time is wasted. 🙂