The dream is this:
This puts us back into a 2012-era development cycle, when making a new website was as simple as opening up your favorite text editor (it didn’t have to be VS Code at the time!), writing some code, and refreshing your browser.
It also makes our code simpler: No more module loaders! No more dealing with a package manager! No more needing to read the complex documentation of a bundler! Just write JS code and you’re done.
The main problem is that libraries aren’t there yet.
Most libraries are distributed on NPM now, but they don’t all export an ES Module interface. A good number of them, even if meant only for the browser, still use CommonJS or CJS (i.e. “require” and “module.exports”).
Once the majority of front-end-centric libraries use ES Module syntax, we’ll be significantly closer to this dream. Some major ones, like React, are moving very slowly.
The second problem is that tooling is still necessary to some degree.
For one thing, there’s still a need for dependency management. Even if
we were to just download production-ready .js files for our favorite
third-party library like we used to in 2012 (instead of using
install react), we would still need to install the third party
dependencies that they depend on. Otherwise, if they bundle it into
their own .js file, we’ll have multiple copies of e.g. the “pad-left”
library, stored within each library that uses it. That’s inefficient.
There will also still be a need for serving files locally. Browsers
don’t support ES Modules using the file:// protocol, so at least
python -m SimpleHTTPServer will be necessary. But given that a lot
routing, a smarter server is
So the future of ES Modules still requires at least a local dev server, and probably a package manager – either NPM with sugar on top, or maybe something new – that’s probably still going to need something like package.json to store a “dependencies” list.
Recently I stumbled on Pika, which is an umbrella project that aims to solve the library problem using tooling. The author makes a very compelling argument for “a future without webpack”, which brought all this to my attention.
The Pika/CDN solution is interesting, although I’m still not quite
sure how it differs from unpkg.com’s
?module query-string solution.
It has a couple issues that need to be solved before I’d be comfortable replacing create-react-app with this in my client project: the first is to make it work with CommonJS dependencies, and the second is to automatically find dependencies.
We’ve discovered much easier ways to write websites since then, and those ways come at a cost of complexity that make me nervous to throw the baby out with the bathwater.
That said, there are some great libraries that make it possible to write web-apps without transpilers. If you’re okay with abandoning TypeScript (I’m on the fence about it), then you can probably replace JSX with HTM. And if you can afford to ditch IE11, you can probably get rid of Babel altogether.
My name is Steven Degutis. I'm a Catholic and a father and husband, and to support my family I write software.
This site exists so that I can post questions and thoughts, which can then be posted to sites like Hacker News and certain subreddits for further discussion. My hope is to further our trade by by promiting discussion and creative collaboration.