(Slightly More) Substantiative Critique of HTML Imports

gistfile1.md

This is a mix of perceptions and feelings- correct them as necessary. I don't work on the spec nor the implementation of the standard- I speak as a potential user of the functionality. I assert I am still permitted an opinion.

• How to I make HTML Imports production-ready on present-day networks without vulcanize? HTML Imports produces many, many requests.
• How do I reconcile ES6 modules with HTML Imports?
• Will package managers learn to support HTML Import bundles?
• Many, many modern frameworks treat HTML markup as presentation layer, not data/application layer.

This is what I can think of off the top of my head.

@nevir as for SPDY + HTTP/2, for the average developer- is that a more pleasant experience than just concatenating the resources? I understand it's the future, but doesn't feel ready right for today (meaning the next 12-18mo) for most.

SPDY + HTTP/2 is today for most of the market. Your server (can) support it and clients already do: http://caniuse.com/#feat=spdy

ES6 has largely punted on defining the interactions between the network layer and the loader; this is natural: it allows a loader to be implemented differently for different runtime environments and, e.g., do transpilation. The level of resource request interception is slightly lower-level than with HTML Imports, but HTML Imports + Service Workers are equivalent (or more powerful).

Lastly, Vulcanize is just as much a requirement for modern webdev with imports as minification build steps were in a previous era. It's reasonable to talk about not wanting build steps AT ALL, but arguing about which style of (mostly orthogonal) tooling is OK and which isn't doesn't feel like anything but an argument from momentum.