4 ms·

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 m

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/ 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.

guilherme-puida 3y ago
> ... 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.
tolmasky 3y ago
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...`)

guilherme-puida 3y ago

> ... 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.

tolmasky 3y ago

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...`)