We currently handle node.js and Go applications differently: Go applications are compiled to JS along with a small, inline syscall shim that knows how to talk over the Worker's MessagePort. For node, we have a browser-node binary, that then loads and interprets javascript files. This works well for a demo, but is sub-par for non-toy applications that require() things outside of the stdlib.
There are 2 ways we could go with this that aren't mutually exclusive:
use parts of Browserify (or one of the alternatives like webpack or rollup.js) in browser-node. When node ls.js gets executed, we read the ls.js file, parse it, find all the require statements, and transitively pull into the node process all depenencies before executing the script. We need to do this before we begin execution, because require() has blocking semantics.
implement and document a Browserify invocation that replaces a bunch of the Browserify standard library imports with our own that talk over system calls. Then we can directly execute these 'binaries'.
The second one is probably better for all use cases except demos, where people might modify and re-execute node scripts.
We currently handle node.js and Go applications differently: Go applications are compiled to JS along with a small, inline syscall shim that knows how to talk over the Worker's MessagePort. For node, we have a
browser-nodebinary, that then loads and interprets javascript files. This works well for a demo, but is sub-par for non-toy applications that require() things outside of the stdlib.There are 2 ways we could go with this that aren't mutually exclusive:
browser-node. Whennode ls.jsgets executed, we read thels.jsfile, parse it, find all the require statements, and transitively pull into the node process all depenencies before executing the script. We need to do this before we begin execution, because require() has blocking semantics.The second one is probably better for all use cases except demos, where people might modify and re-execute node scripts.