Open Bug 1688879 (importmaps) Opened 3 months ago Updated 8 days ago

Implement Import Maps

Categories

(Core :: JavaScript Engine, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: ystartsev, Unassigned)

References

()

Details

(Keywords: dev-doc-needed)

Chrome is shipping in 89.

This is probably the most anticipated feature in JavaScript history. It will, finally, after 25 years, enable the bundler-free web development. Please prioritize it, thank you!

Any updates? Available in Chrome already. The last step to the native code re-use in the browser. Only took 25 years.

Import maps isn't standard yet, and looking at the repo they still have a few kinks to work out. For broader reference, WICG doesn't standardize HTML -- it incubates interesting proposals, which can then be merged into the HTML spec. That hasn't happened for import maps, and this feature is not yet standard. Chrome tends to ship proposals eagerly, to get early feedback. This is a great for people to experiment with it.

Since you mention bundler free web development: One of the proposed use cases is import maps + http push, and I know many people are excited about this. dhh spoke about this technique on twitter, and it brought a lot of attention to this bug. This technique will likely not be viable in the long run, as Chrome is dropping support for http push and they do not plan to support push from HTTP/3. You can refer here for more details: https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/0o4J1GEjAgAJ Something else, potentially equivalent, may take it's place, but it is hard to know right now. Import maps is independently useful. If you were excited about this -- then this solution may still take a bit of time as alternatives are explored.

Bundle "free" development is currently under active discussion. There is contention about whether or not bundling should be integrated into the browser, as the network requests may be too costly to ever move away from bundlers. There is disagreement on this point, and research is ongoing. IETF and WICG are looking into this, and presentations have been made to TC39 as well. Alternatives have also been discussed. You can take a look at the following repositories for more info:

https://github.com/WICG/webpackage
https://github.com/WICG/resource-bundles
https://github.com/littledan/proposal-module-fragments

From our side: at present, there isn't bandwidth to eagerly implement this proposal at the cost of other high priority work. Coupled with the experimental status, the shifting space of complex multi-resource applications, and the implementation complexity which may interfere with ongoing work, it doesn't make sense to implement immediately. It is on our radar however, and we will certainly get to it when we can. I am doing a pretty large push on modules this year, and it will likely be within the scope of that work. I have a few higher priority issues to get to first.

OK, phew, the last thing. I am not sure what you mean about "native code reuse". Perhaps you mean portability between server and frontend code?

In which case -- yes, import-maps would introduce native support for portability of code from node to the browser. This problem has existed since the introduction of nodejs and commonjs in 2009 and the unique approach to module specifiers. The module system didn't exist at the time and there was a lot to figure out. What works on node doesn't work on the web, as the web is a more constrained environment. Node introduced a more "user friendly" specifier, as they don't have the security requirement that the web has for non-spoofable resources. There is a good reason why we use URLs on the web, while node decided to do something else. Import maps, from a user perspecitve, would make things more ergonomic and make the portability between these two types of js hosts much better. I wouldn't say that this is as old as JavaScript itself, as the problem import maps is solving is complex, and arose out of relatively recent technologies. It is an interesting problem but a relatively recent one compared to the age of the language.

Thank you for the detailed comment! Glad to hear import maps are on radar. I believe they a way forward, and AFAIK there's no other compelling solutions for code reuse. Hope you can take look on them during your push on modules.

To my shame, I don't know what is "http push" so can't comment anything on that.

Under "native code re-use" I just mean a module system that supports/is integrated with packages repository. It great to have native modules in the language, finally, but wait, you still can't use all the code published in the repositories (w/o running special bundler web-server). Feels like language designers/implementors live in their own universe and every-day web engineers - in separate one. Why native ESM modules did not account for the de-facto standard of JavaScript package, created by npm (node_modules, bare package identifiers)? Because language designers plan to introduce their own format? In the same way - why Node.js guys back in the days, created synchronous modules spec, knowing it will never be accepted in browsers? This all is just madness, lack of communication and loving kindness to fellow developers. We can do better I believe.

You need to log in before you can comment on or make changes to this bug.