Hacker News Reader

The web is a very wide world out there, and companies and people have a wide diversity of architectures and methods for frontend apps that benefit from import maps.

Consider:

- Many people want to skip bundling altogether for as long as is possible. It's really nice to have a build-free (or almost build-free) app, especially when you're starting a greenfield or personal project. Why get mired down in researching the latest third-party build tools before writing code?

- Third-party dependencies can be vendored (included in your own deployed assets on a domain you own). This ought to be everyone's default - CDNs shouldn't be used in production for new projects anyway. If you're loading from your own domain, hashing the asset isn't necessary.

- Sometimes you may have dependencies you wrote yourself that you'd like to load with an import map.

- Some architectures call for both a build/bundle step and an import map. Consider a micro-frontend architecture -- this allows many decoupled teams to work on different parts of an app that are composed together at runtime. Each MFE is built/bundled prior to deployment, but an import map helps the browser load each one when it is needed. See https://single-spa.js.org/docs/recommended-setup/

> I already had a tool that could do that, and it worked in every browser and didn't ignore the the security advancements we made 10 years ago.

But that tool (WebPack or RequireJS, right?) had to shim a lot of non-native features into the browser runtime, and at build time it was slow and very complex since there were so many module types that needed to be supported. Modern tooling has much less build-time complexity, requires little or no runtime module library, and is more performant since it's often written in Rust. (See Vite, esbuild, etc.)

Browser features that allow simplifying and/or eliminating third-party tools are always a net win, IMO.

> ... and is more performant, since it's often written in Rust. (See Vite, esbuild, etc.)

Minor nitpick, but Esbuild is written in Go, not Rust. Vite also uses Esbuild behind the scenes.

If I'm not mistaken, SWC is the one built in Rust.

    Many people want to skip bundling altogether for as long as is possible. It's really nice to have a build-free (or almost build-free) app, especially when you're starting a greenfield or personal project. Why get mired down in researching the latest third-party build tools before writing code?

But ESM doesn't actually give you this, this is precisely the point I'm making. ESM doesn't become ergonomic without the use of some sort of tooling. Perhaps you have your setup that just spins something up and auto-compiles an import maps or something. Great! But that's not at all the promised dream of finally escaping tooling. It's the same thing we had before, just outputting different stuff. Different stuff that happens to be worse in a lot of ways.

Import maps are a perfect representation of this. It's essentially asking you to hand-write a manifest file just to be able to type "import 'lodash'". This is not an improvement or simplification to the web ecosystem. In my experience, the people who are actually using any of this stuff, are doing so through some build pipeline. And again, this is unfortunate since no one should be shipping this to production since it is both slower and less secure.

Handwriting an importmap is no worse than handwriting a stack of `<script src="https://some.cdn.somewhere.example.com/jquery"></script>` global imports, but has the advantage that importmaps are lazy (aren't used until import time) and don't pollute the global namespace.

Just like the bad old jQuery days maybe you'll see a proliferation of importmap CDN lines to just copy/paste manually in READMEs, no need for further tooling than your OS clipboard.

Some CDNs are even building themselves to be easy to handwrite into importmaps (https://esm.sh/ for one example mentioned in other threads around here).

It gets complicated again if you don't want to rely on CDNs and prefer to have local copies, but that's always been the package management game in a nutshell (and before there was npm there was the much simpler bower and there are already tools trying to be ESM "bower").

(ETA: You can even avoid some handwriting by sharing importmaps, such as something like `<script type="importmap" src="https://your.fave.cdn.example.org/shared-react-importmap.jso...`)

You really don't have to worry about these things until your module graph is > 100 modules. You are falling into "all or nothing" thinking here, because you need tools in some use-cases doesn't mean that a feature is worthless. Not needing tools for small projects and then needing them for large projects is pretty good tradeoff.

I'm not sure what you mean by all or nothing thinking here. The problem with imports is precisely that it is incredibly cumbersome to use without a bunch of additional "add-ons". You can't just "use a little bit of it." Want to do the supremely simple task of importing a JSON file? Better make sure your browser supports import assertions (assuming one even knows these exist). Want to not have to import a long incomprehensible URL? Better write a manifest file called an import map that only recently got full browser support. You can't even trivially add a script tag with an ESM module because it won't work from a file:// domain, you have to start up a simple server for your simple.html file. So I have no idea where this notion of not needing tools comes from. I think what people actually mean is "my tools support ESM out of the box". It is not trivial to get a nice experience with zero tooling. Again, you at minimum need to run a server (and I believe you have to fiddle with the MIME types for python's one line simple server too, although perhaps that has now been rectified). The simplest projects require strictly more tools to use this thing. And on the opposite end of the scale, it appears that you agree that of course you will use tooling. Only hopefully those tools aren't generating imports but just bundling because if not they are creating slower and less secure resources.

ESM imports have fallen into the C++ trap: every year the determination is made that "if we just add these 5 extra features (both to the the ECMAScript spec and W3C spec), then they'll finally be great out of the box!" This is how we ended up with import.meta and dynamic import and import maps and import assertions and preloadmodule link tags, which are all still less flexible than require/bundler, and somehow still don't have any answer whatsoever to integrity checksums that originally shipped in 2015. It's absurd.

To be clear, I am not saying there shouldn't have been "an" import spec. I am saying this one is tragically flawed and remains realistically a bad option (unless you are using a compiler that is just going to turn it into roughly the same minified mumbo jumbo it was turning your requires into before). This is fairly well accepted at TC39. The spec was rushed. Nothing would be allowed to ship with that level of consideration anymore. Usually someone at this point asks "well what would you have done?!". I would have punted on import until after async/await. Many of the most fundamental issues in imports come from having to have conceived them in a pre-async/await world. They are essentially a "top-level-await-ish" statement, in a world with async/await. However, had async/await and top-level-await shipped first, and then import was introduced, you could have started with the expression form of import (await import()), which would not have required any new syntax (you could just use destructuring, the same way you do now), and not required a "exercise left to the host environment" hand-waivy async-link resolution system, but instead used the actual existing semantic of the language. We ended up having to do it anyways with dynamic import. It is so weird that `x as y` becomes `{ x: y }` and `x` becomes `{ default: x }` merely by moving the entrypoint around in the file. It would also be a lot more transparent to the user: by typing `const x = await import("blah")`, you aren't (erroneously) lead to believe that this is a synchronous action when it isn't. It's also way easier to add additional features to a function (such as integrity hashes or assertions or whatever), vs. in a statement where it requires a parser level change, and for no real benefit other than causing people to have to learn a bunch of weird new syntax that increasingly feels out of place.

> You can't even trivially add a script tag with an ESM module because it won't work from a file:// domain, you have to start up a simple server for your simple.html file.

This isn't an ESM problem. Last I checked this is still a per-browser security decision that applies to all JS, not just ESM, because browsers fear they can't trust malware or adware not to spread if file: were too open. (Thanks to such things in the IE days existing.) Too many developers are in Chrome 24/7 and forget that Firefox still exists and has good development tools and that Firefox allows file:// origin for scripts still in 2023 (with some caveats, but fewer than "doesn't run at all" as has been the Chromium default for a long time).

Also, I recall there are command line flags in Chrome to allow it if you really do want to use Chrome for development and can't just spin up a simple server on localhost.

It is an ESM problem, since it works just fine with non-ESM script tags. ESM isn't some theoretical thing, it's the reality of how it works, in particular when we are specifically discussing the practical reality of using it. And the fact is that it absolutely is more cumbersome than the old technologies (and more cumbersome than alternative approaches that could have been taken). The fact that we're now talking about launching Chrome with special command line flags demonstrates this. I mean, the rest of my comment that delves into all the other problems proves it even more, but the fact that it fails the bare minimum requirement of just loading when you drag and drop a file into the browser is fairly bad.

> It is an ESM problem, since it works just fine with non-ESM script tags.

This is not my experience. I've had many cases where Chrome security blocked non-ESM script tags to file: URLs (that Firefox was much more fine with).

The security mechanisms in the browser have gotten extremely sensitive (and rather baroque) and blocking file: by default is a part of that. This isn't an ESM-specific thing in any way, this is an overall browser security thing. It is a response to the arms race of malware.

People that have been writing/developing apps and scripts designed for local use (such as Twine) have been complaining about Chrome security defaults for years now for non-ESM development. "Drag-and-drop" of Twine games is generally only reliable on Firefox. There are so many obscure Chrome security issues that can break such games. This is not a new complaint for ESM.

(I didn't break down the "problems" with the rest of your comment because it was a bit of a rant and a lot of it felt to me more like opinions and bike shedding rather than "problems". I didn't think I can convince you that ESMs are good and wasn't going to try. I can point out the facts that script loading from local files is a Chrome [and IE] problem more than an ESM problem, because the facts back that up.)

If you expect to be able to develop with the file protocol you're going to be disappointed. Essentially all modern features don't work with it; not just ESM. You can't use Service Workers with the file protocol either.

> I'm not sure what you mean by all or nothing thinking here.

I mean this:

> Want to do the supremely simple task of importing a JSON file?

Surely you realize that "importing JSON" is not something every project or page needs. By "all or nothing thinking" I mean the idea, which you expand in this response, that unless it supports everything it's not worth ever using. But that's a false dichotomy. A lot of projects are simple. A lot don't need all of these advanced bundler features. Those projects can (and do) use bare ESM in the browser. And that's ok.

To answer your question more directly, the reason they do it this way is because bundling dozens of features into a spec and then releasing them all at once has never worked in the history of web standards. For better or worse, doing one small thing at a time is what works.

As someone on TC39, I can tell you that’s not why this was done this way. It’s an accident if history, and recognized as a rushed spec. The async/await first then import expression path I described would actually follow the “don’t ship one huge thing” (that then takes 5 years to implement) advice that you are suggesting.

tbf there's been a working import map polyfill for a long time now

There are obvious benefits to having the granularity of loading and caching script files match the granularity of how those files are used on different pages or updated at different times.

Bundling everything is fine for most apps, but sometimes you have a need for code splitting, or sharing libraries between scripts from different origins, or some mix of preloading and dynamic loading. So it is nice to have a standard for these things.

Here here. Today, bundlers may get you to first page load faster. But if a user comes back and you've shipped two small fixes, all those extra wins you get from compressing a bunch files at once fly out the window & you're deep in the red. If you have users that return to your site, and your site is actively developed, bundling is probably a bad tradeoff.

We see similar fixedness in the field all over the place: people freaking love small Docker image sizes & will spend forever making it smaller. But my gosh the number of engineers I've seen fixate on total download size for an image, & ignore everything else, is vast. Same story, but server side: my interest is in the download size for what v1.0.1 of the Docker container looks like once we already have v1.0.0 already shipped. Once we start to consider what the ongoing experience is, rather than just the first time easy-to-judge metric, the pictures all look very different.

Then there's the other thing. The performance reasons for bundling are being eaten away. Preload & Early Hints are both here today & both offer really good tools to greatly streamline asset loading & claw back a lot of turf, and work hand-in-glove with import-maps. The remaining thing everyone points out is that a large bundle compresses better (but again at the cost of making incremental updates bad). The spec is in progress, but compression-dictionary-transport could potentially obliterate that advantage, either make it a non-factor, or perhaps even a disadvantage for large bundles (as one could use a set of dictionaries & go discover which of your handful of dictionaries best compress any given piece of code). These dictionaries would again be a first-load hit not different from a bundle's hit, but could then be used again and again by users, to great effect again for incremental changes. https://github.com/WICG/compression-dictionary-transport

Bundles are such an ugly stain on the web, such an awful hack that betrays the web's better resourceful nature. Thankfully we're finally making real strides against this opaque awful blob we've foisted upon this world, our users, and ourselves. And we can start to undo not just the ugliness, but the terrible performance pains we've created by bundling so much togther.

If you use code splitting (and you really, really should), bundlers can yield strong incrementality.

This has repeatedly my been demonstrated to be false in real world tests. One bundled file performs way better, especially when you take tree shaking, minimization (which has performance implications even after load in terms of memory usage), and compression into account. A small change in one part of the code can result in lots of other code being removed from a library you use. Code splitting usually does a better job of achieving the (suspect) goal of making these incremental changes more performant since the chunks are chosen in order to optimize this vs files which are “chunked” along human organizational lines, which do not necessarily correlate highly with diffs.

If browsers hadn’t removed the shared cache for script resources, there might be an argument here. But they did, putting each domain its own cache to avoid fingerprinting, so even that goes out the window.

On the one hand people worry about the massive node_modules folder in the cases where it doesn't matter (when it's just files on disk in a local node app), and on the other hand, we create things like import maps that will literally take this dependency graph and translate it one-to-one to a higher latency HTTP version, where it absolutely will be a problem.