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

For production-ready on present-day networks: SPDY push and HTTP/2 push get you there, but we lack a lot of tooling to make that easy. Getting there is pure engineering effort (we have the primitives we need, I think).

ES6 module <-> HTML import interop is a bit weird, yeah. But they're conceptually very similar, and it doesn't take much to make them to play nice together (working example that I'm hacking on right now, actually: https://github.com/nevir/html-exports).

Package managers are hard, and until npm cleans up their layers for use by client package managers, it's not a great place. But, again, I think we have all the primitives we need, just a lot of community engineering effort required.

Treating HTML as presentation layer: let's not hamstring HTML just because of current-gen frameworks/libraries! Plus, if you look at future frameworks, they're trending towards everything-is-ES6 (which means template strings, etc). Blah!

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