4 ms·

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'r

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.

WorldMaker 3y ago
Handwriting an importmap is no worse than handwriting a stack of `<script src="https://some.cdn.somewhere.example.com/jquery"></script> 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/ 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.json"></script> https://your.fave.cdn.example.org/shared-react-importmap.jso...`)

WorldMaker 3y ago

Handwriting an importmap is no worse than handwriting a stack of `<script src="https://some.cdn.somewhere.example.com/jquery"></script> 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/ 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.json"></script> https://your.fave.cdn.example.org/shared-react-importmap.jso...`)