The Future of JavaScript
I really dislike what they're doing with modules because it's such a step back from the commonjs-inspired require() that node uses. In node, require() just returns a value. That value is usually an object but often it's just a function. Why should a module that encapsulates exactly one function return anything else but that one function?<p>In ES.next, you've got to use pythonesque `import y from Bar` statements which introduce a frustrating correspondence between the lexicals of your own program and the export names of the module you're trying to use which is really terrible if you're using as many modules as I typically do. I presume ES.next will invent even more specific syntax for some sort of `as` like keyword to side-step this but it seems so unnecessary when javascript already has a module system that is so very good as is exploding in popularity and use (>7000 modules now on <a href="http://search.npmjs.org/" rel="nofollow">http://search.npmjs.org/</a>).<p>I understand what they're trying to do with static analysis too but you can already pretty much do that and I've done it. It's not hard at all, just ignore require() statements that don't contain strings when you walk the AST, like this: <a href="https://github.com/substack/node-detective" rel="nofollow">https://github.com/substack/node-detective</a><p>Inventing more syntax instead of just adopting a far better module system that has seen actual use in practical situations is such a shame and ES.next is rife with this kind of prescriptivism. It irritates me to no end and I sometimes want ES.next to die a quiet death in obscurity because of it.<p><a href="http://wiki.ecmascript.org/doku.php?id=harmony:modules" rel="nofollow">http://wiki.ecmascript.org/doku.php?id=harmony:modules</a>