5 ms·
The work done by Guy Bedford and others in building SystemJS [1] is great. SystemJS is a practical implementation of the whatwg loader specification proposal [
by robertkrahn01 9y ago
The work done by Guy Bedford and others in building SystemJS [1] is great. SystemJS is a practical implementation of the whatwg loader specification proposal [2]. Using SystemJS you can use es modules in node.js and the browser right now. On nodejs it provides an escape hatch via System._nodeRequire to fallback to node.js' require from within an es module if you really have to.
The one thing that I really miss is that most (all?) JS module implementations really seem to be focused on static compile workflows. Sure, for deployments you want that, for development JS as a very dynamic language would offer much better support for live programming systems if the module systems would play along nicely. One reason why I personally was excited to see that the loader proposal initially considered custom locate/fetch/define behavior added via hooks but more recent discussions about bringing it forward seem to dismiss that. I think for great tooling a module system that supports both deployment as well as development needs is necessary and would really add to the JS ecosystem.
[1] https://github.com/systemjs/systemjs https://github.com/systemjs/systemjs
[2] https://github.com/whatwg/loader https://github.com/whatwg/loader
- spankalee 9y agoCareful, that loader spec is dead. Unless something drastic changes, don't expect any of those hooks.
- _pmf_ 9y ago> The one thing that I really miss is that most (all?) JS module implementations really seem to be focused on static compile workflows. That's what baffles me coming from Java and C#; I can have dynamically loaded modules with strongly typed interfaces in these ecosystems, but not in any JS module system.
- bfred_it 9y agorequire() is dynamic and import() will be too. What are you talking about? JavaScript is not a typed language (yet?) so it's like expecting pigs to fly.