What does HackerNews think of import-maps?
How to control the behavior of JavaScript imports
Interesting!
https://github.com/WICG/import-maps https://deno.land/[email protected]/linking_to_external_code/im...
What's the point of implementing APIs like WebGPU and localstorage in a non-browser environment? I get WHATWG streams, esm, fetch and WebCrypro though.
the web as we used to do it didn't have packages. and today we want to be able to bring in some packages. even if we want a more old school jQuery or vanilla js experience, we still want some ability to bring in other code, helpers, libraries.
and as soon as we want to do more than hack together 100% fresh novel code, the big nasty world of bundlers &c jumps up at us. we can go the old school route, but we have to forgoe all modernity to do so, renouncing not just big framework, but every other tool & package available too. specs like import maps[1] would help so much to let us make modulehbased development possible & easy, but this straightforward enhancement keeps meeting imo oddly stiff resistance/unenthusiasm from standards developers/some browsers.
and alas the browser still, 5 years latter[2], does not support ecmascript modules[3] in a wide number of places (which themselves are decade old!). even if we do try to use modern javascript, vanilla js + esm, new school modules with old school unframework, we run aground again & have to resort to bundlers if we dare try doing things off the main thread.
i still agree with the core thesis. that it's us. that we are responsible for having introduced complexity & that a lot of it is unwarranted. i personally am hoping web components (really, just custom elements) can help us realign, simmer down some of the big framework mentality & return us towards a more apparent mode of development, a better state of grace. i feel fatigued not by how many frameworks there are, but by how few players there are trying to do better, trying to figure out good ways to do custom elements. thankfully there are some good works too. i am very excited to try github's new Catalyst[4], which is inspired by basecamp's Stimulus. there's an amazing mvc feel here that seems straightforward & sensible, makes it easy to look at the dom & grok how things happen.
[1] https://github.com/WICG/import-maps
[2] https://github.com/w3c/ServiceWorker/issues/831
[3] https://bugs.chromium.org/p/chromium/issues/detail?id=824647
It's an upcoming feature on the browser standards track gaining a lot of traction (deno already supports it), and offers users a standardized way to maintain the decoupling that you mentioned, and allows users to refer to dependencies in the familiar bare identifier style that they're used to from node (i.e. `import * as _ from 'lodash'` instead of `import * as _ from 'https://www.npmjs.com/package/lodash'`).
I imagine tooling will emerge to help users manage & generate the import map for a project and install dependencies locally similar to how npm & yarn help users manage package-lock.json/yarn.lock and node_modules.
v1 shipped with Chrome 53, Safari 10 and Firefox 63. (And there's a polyfill.)
It's not "soon", it's very much "been in production for a while".
A base class like LitElement https://lit-element.polymer-project.org is all you need to achieve a sort of "react-like" development style (components with unidirectional data flow) WITHOUT build tools() and WITHOUT dom diffing! :)
() if you want to use npm dependencies instead of just plain files with a bundled version of lit, you still need to rewrite import paths, until https://github.com/WICG/import-maps becomes a thing at least. I wrote a tiny dev server that does that: https://github.com/myfreeweb/es-module-devserver