-
Notifications
You must be signed in to change notification settings - Fork 17
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
Comments
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. 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. |
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 |
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. |
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.
The text was updated successfully, but these errors were encountered: