Support outside of node

[bjohansebas]

With this, I formally introduce the idea of providing direct support for other javascript runtimes for several of our packages, such as Express and its middlewares. This was brought up in today's meeting for JSHTTP packages, but I think it could also be beneficial for higher-level packages.

[blakeembrey]

I think it'd be beneficial to separate this into two issues: Express and downstream vs upstream packages that happen to live under the organization. It may be bias, but it's easier for me to see how the upstream packages are useful outside of node (e.g. path-to-regexp is just path routing, it gets used in Next.js - so some edge support - and browsers).

It's harder for me to understand the use-case of downstream packages being used outside of node if Express is explicitly a node project. Let me know if I'm missing something, but if that's the case it's more a discussion of making Express support non-node environments, which is a huge can of worms.

[blakeembrey]

I do also want to clarify that the discussion in the TC meeting was specifically about decoupling from node HTTP, but not specifically about supporting non-node environments. They're related, but not the same. E.g. I can build new node.js frameworks from packages that aren't coupled to the node internals, such as path-to-regexp being used for routing in Next.js, which gives them flexibility to build new interfaces that aren't the traditional req and res even though it's still a node.js package.

[ljharb]

Why? Because it's trendy, or is there actual data showing that there's a need for it?

[wesleytodd]

Why? Because it's trendy, or is there actual data showing that there's a need for it?

Browsers is the most pressing "need" I think. That said, I can also see good arguments for CF workers (which would require some new web platform apis or compat layers) and with that might also come some base level support for other runtimes which are currently not supported.

I am not saying I think the work is worth it (yet), and I personally believe this should all be landing in node before we move much on this, but I think there is more than just being trendy involved.

[jonchurch]

What does support mean?

In this discussion, "support" can mean different things. It's important to define where we stand on this spectrum:

• Basic compatibility (it works but isn’t actively maintained).
• Accepting PRs (community contributions welcome but no semver guarantees).
• First-class support (actively testing and maintaining across runtimes, runtime specific bugs are considered blockers).
• Runtime-agnostic Express (major refactoring to remove Node.js dependencies).

I think each package can make this decision for itself based on maintenance load, community desire, and feasibility.

What runtimes are out there?

The top non node runtimes some of our packages could show up in are:

• Deno
• Bun
• Edge runtimes (Cloudflare Workers, Vercel Edge Functions)
• Browsers (and service workers)

Im not well informed on this issue specifically, but I think usually the biggest blocker is relying on node http builtins whose availability differs across runtimes. Thinking about those differences is why WinterTC exists, and why the above runtimes participate there.

WinterTC aims to standardize APIs across these runtimes, making it easier for frameworks like Express to work without explicit adaptation.

Tying it all together

Like @blakeembrey points out, our convos hav centered around coupling to Node http builtins. That is the biggest blocker for wider runtime support.

Rather than debating explicit support for each runtime, we should instead ask "Would reducing Express’s reliance on Node-specific internals provide meaningful benefits?"

Im not motivated to increase our support matrix officially. I am motivated to evaluate options for decoupling from node http internals. That's a "move the ecoysystem and Node forward" direction for me personally, and if we get the side benefit of opening up compatibility with more runtimes then great.

We've had this conversation before

History repeats itself, see expressjs/express#2539 for the discussion around officially supporting io.js

The concern then, as now, was maintenance burden. Official io.js support did land eventually, and it was officially supported far longer than the 8 months that io.js existed.

If something like WinterTC had existed to ensure API compatibility between Node.js and io.js, Express might not have needed to make an explicit support decision at all, because API compatibility would have been a shared responsibility across runtimes.

[ljharb]

(fwiw io.js never stopped existing, it retroactively became node v1, v2, and v3 :-p)

[UlisesGascon]

For me the most important thing is the need to maintain a CI that can represent exactly what we are supporting, specially if we decide to support these alternatives over the years (and not just now or in the next year), so far we are one of the most stable libraries and we keep maintaining compatibility with ultra legacy versions like Node@0.8 in many packages (as an example). Our users love this stability and IMO is one of the key features that we provide.

The alternatives that we support must be compatible to with our LTS and major release schema, so far seems like in many of these alternatives are doing a proactive effort to support us anyway:

• https://docs.deno.com/examples/express_tutorial/
• https://bun.sh/guides/ecosystem/express

IMO seems like "provide official support to non-node environments" is a lot of effort for us (now) and we have other clear priorities for 2025: https://expressjs.com/2025/01/09/rewind-2024-triumphs-and-2025-vision.html.

That said, I am +1 to make the life easier for others to support us (upstream and downstream), so taking smart decisions like decoupling from Node specific might be the way to go.