ES modules: A cartoon deep-dive

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 :-)