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 (https://mrspeaker.github.io/webgl2-voxels/) all in modules, and being able to just view-source without any shenanigans feels like the old days.
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!
It's great for small apps, demos, and development!
But for deploying it'll probably continue to be a good idea to have build step. If you need to support a wider range of browser, you'll want a transpilation step. Minifying can drastically reduce the payload size. If you want tree shaking, that requires a build tool. Even with HTTP 2.0 and being able to push stuff down to the client you'll need to crawl the dependency graph and generate some kind of manifest for the server to know what to send. You can do those things on the fly, but that's just turning it into an implicit build step.
Depending on how frequently things are changing, there's also the matter of simultaneous versions of the app running at same time. If you're loading modules asynchronously, a user with Version A of the app could end up importing something meant for Version B. Users sometimes go for weeks or longer without refreshing a tab. Tools like Webpack make it easy to have all your module references updated and named correctly to avoid this kind of clash.
These aren't problems that all apps need to handle. In fact, it's great if you can get away without any of it! But those kinds of use-cases are what tools such as Webpack help to solve.
For a development environment this is great. However if there's any takeaway from this post, it is the reminder that all of the resolve, parse, eval, execute, graph traversal, and linking has to be done at runtime, so if you are okay with your app taking 1000x longer to load then if you bundle it, then I guess that's a personal preference.
However, we will continue to endorse for the sake of web performance that you bundle your code, and not use modules natively :-)
The problem I find with the current ES modules is a lot of statements like this
import {thing} from '../../../thing/in/dir.js'
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.
I think babel has something like this using @, but I don't use babel right now.
Ember has a convention to resolve files in its 'app' directory from your project name, and it makes renaming files a lot easier: `import { thing } from 'my-project/thing/in/dir.js'`
I wrote a very small resolve hook for node that does this. It makes the directory of the initial module / for all imports. Node has made resolver hooks like that dead simple.
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).
It seems like the pendulum of "configuration vs. convention" has swung all the way back to the configuration side.
Before: add all the scripts you'll need to the HTML. Just don't run any scripts before the document loads.
Today: bundle in 6mb of dependencies to solve that "problem" so that we don't have to use window.onload.
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.
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!