Dear TC-39, can you please take another look at your module syntax
Dear TC-39,
You’ve been doing some fantastic work recently, all the new features slated for ES6 look amazing. Arrow functions and the functional parameters sugar do such a good job at making functions just that much more fun to use. Set, Map, WeakMap great and really going to help for data centric apps (like all the GeoSpatial stuff I do). Generators, well I’m already using them and they are fantastic. Promises are already in browsers, that’s so fast it’s unbelievable. All these great things you’ve done make this just so much harder. But the module syntax you folks are proposing for ES6, I think you should take a fresh look at it.
Most of the discussion we’ve had on the module system has been framed poorly, it has been people like me who it rubs the wrong way attacking it and people like you who spent a lot of time developing it defending it. But really we’re all on the same side, we want the best possible module system that we are able to actually get into browsers in a realistic time frame. More specifically a module system that does static analysis (finds the dependencies without running the code), so that we can avoid the significantly added layer of complexity that comes with dynamically loading modules.
I originally was going to write a while thing about the flaws in the system you guys are proposing, I even made this flow chart to show how complicated the export syntax is and a whole list of links to code that wouldn’t be writable in the new syntax. But then it occurred to me that it is hard to tell if you guys writing the spec really even think this syntax is any better then what is currently out there, because if you do your doing a very bad job of selling it to us in the node community. Static analysis of dependencies and imports with browserify or the CommonJS wrapper in require.js (define(function(require, exports, module){...});) show that in practice there is no need for restrictions on the location of imports to successfully find them in static analysis and people trying to conditionally load modules in a situation where they can’t isn’t a problem in the wild.
There are sources which describe ES6 modules as a compromise between CommonJS and AMD modules, but again that isn’t really the case any more as using the CommonJS wrapper has become more prevalent in AMD code to the point that most debates about CommonJS vs AMD have much more to do with tooling and deployment strategy. In many ways ES6 modules are redefining the one thing about modules that the AMD and CommonJS communities agree on, syntax.
Which brings us to the root issue, TC-39 hasn’t sold the node and AMD community on their new modules system. Coming from node and AMD systems this one is more complicated with significantly less functionality, specifically
- Lack of import statements (as opposed to declarations).
- Syntax that is still geared towards exporting a bag of values as opposed to a thing.
- Generally high level of complexity of import export syntax.
The people in the node community giving you grief about this syntax aren’t just bikeshedding but are people building production apps with a module system that they like and you haven’t convinced them that you have something better. And that’s just sad because the node community is your biggest fans. We love generators, we are using block scoping in the wild, and have some very strong feelings about Promises, much of which is positive.
TC-39 that’s what I’m asking you, take a hard look at your module syntax and ask yourself
- Are we taking advantage of the experience that the community has gained building production systems with CommonJS and AMD?
- Are we taking advantage of the examples offered by more modern build tools like browserify and require.js?
- Are there real and non-hypothetical advantages gained from restricting imports to declarations?
- Have we taken into account other features of ES6 like destructuring in designing these modules?
- If you weren’t involved in the spec writing process, would the export syntax make as much sense?
From an outside perspective it feels like TC-39 is suffering from Not Invented Here syndrome ,if committee members don’t think that this is the case then I think a lot of people would appreciate it if you guys tried to sell us on the advantages of this syntax as compared to current tools if members don’t feel that way I don’t think I’m the only one who would prefer modules done right in ES7 to settling in ES6.
Edit:
- Comments on reddit
- Also in case it’s not clear, I’m not advocating to just drop in node modules into the JavaScript spec, just it would be nice to have a similar level of features.