Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

At the very least, a first class syntax shows a different commitment level. Building a syntax into ES2015 states a definite, intended, and considered effort to deal with modules as a key part of the language moving forward.

An async implementation of `require` would still be subject to most of the same debate and complications of the "Loader" (how are module names converted to URL paths; how are URL paths deduplicated from being downloaded more than once or ran more than once; ...). You can't assume "Node-like" semantics in the browser (where it's more often more costly to walk the remote file system) and even amongst AMD solutions you'll find variations in how options are configured and how the different loaders work.

TC39 getting the syntax into ES2015 was as much a signal to WHATWG to stop kicking the "Loader" debate can down the road and actually make decisions and get things standardized as anything else. It's easy to believe that without that commitment of dedicated syntax in the language that the browsers would be a lot less incentivized, we'd still be having the Loader debate in 10 years and we'd still have increasingly subtle differences in AMD loaders and CommonJS loaders, and that nice new "async implementation of require" would continue to just be one option among many, with twelve different libraries implementing it in slightly different ways.

Personally, I think the ES2015 import/export syntax is much more aesthetically pleasing than AMD, and nicer to work with than CommonJS, but I can appreciate that there are plenty of aesthetic opinions on the subject.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: