I can't wait for ES module support in Firefox by default (so all major browsers are covered). It feels so good to be able to write code in "plain old JavaScript" again without the need for transpilers and build tools for small apps. I made this minecraft WebGL2 thing (<a href="https://mrspeaker.github.io/webgl2-voxels/" rel="nofollow">https://mrspeaker.github.io/webgl2-voxels/</a>) all in modules, and being able to just view-source without any shenanigans feels like the old days.<p>The only issue now is I want to share the code with a Node server... I really hope the new proposals will help bridge the require/import gap!
The problem I find with the current ES modules is a lot of statements like this<p>import {thing} from '../../../thing/in/dir.js'<p>and then if I move a file I have to change all of its imports to a different number of parent traversals. It would be really nice to be able to define a path that all imports would be relative from.<p>I think babel has something like this using @, but I don't use babel right now.
This has been the only thing keeping me using Babel for a couple of years now. Every other ES6 thing I really wanted is in vanilla JS. I'm pretty thrilled.
This is what we get when we encourage rather than actively discourage new innovative ways to explain things. There are so many academic fields that could reduce their learning curve if they only embraced this idea rather than close off any and all attempts to deviate from the path of established rhetoric (which could cause huge cascades of innovation throughout all industries, making many fields look a lot more similar in their pace of growth to the front end world).
FWIW, I was wanting to play with native modules locally using files loaded directly in browser instead of a local Node instance.<p>That's about impossible in Chrome (in my experience and as per SO answers) and trivially easy in Safari.<p>Develop menu / Disable Cross-Origin Restrictions<p>Not that spinning up node is really any slower when you take into account auto-reload capabilities.
It seems like the pendulum of "configuration vs. convention" has swung all the way back to the configuration side.<p>Before: add all the scripts you'll need to the HTML. Just don't run any scripts before the document loads.<p>Today: bundle in 6mb of dependencies to solve that "problem" so that we don't have to use window.onload.<p>I especially like the sibling commment about how this new development gets us closer to the good old days of being able to view source on our code. As though that was something that had happened to them, rather than a conscious decision to adopt worse tools.
These Mozilla posts are very well done! As per the article, I'm always excited to see the JS community converge towards decent standards. This has been a long time coming.