Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support outside of node #331

Open
bjohansebas opened this issue Jan 30, 2025 · 4 comments
Open

Support outside of node #331

bjohansebas opened this issue Jan 30, 2025 · 4 comments

Comments

@bjohansebas
Copy link
Member

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
Copy link
Member

blakeembrey commented Jan 30, 2025

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
Copy link
Member

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
Copy link
Contributor

ljharb commented Jan 30, 2025

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

@wesleytodd
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants