Re: [w3c/webcomponents] HTML Modules (#645)

Sure you can XHR a HTML document, but the point of this is to use the ES module dependency system instead of duplicating it with HTML import's own dependency system. Being able to `import` a Document has two benefits over fetch/XHR:

- it can have a shared dependency system with ES modules, which helps do things like deduplicate repeated dependencies
- it uses the same synchronous style as other imports, i.e. it's convenient that the script doesn't begin to execute until all imports have finished, which is nicer to work with than lots of promises (particularly if there is nothing to do until a subresource like a document or image has loaded).

> But what about performance (including loading performance)?

I was previously concerned about this, but it doesn't actually seem to be that big a problem, at least in our case. We recently switched over from native HTML imports to a polyfill based on XHR, and we could not measure any performance difference, and none of our users noticed anything different. I think this is because in our case we have ~300 imports which are generally all pretty small, so there's not much advantage to preload scanning. Also I suspect the network layer gets saturated pretty early on in loading and loading performance depends mainly on roundtrips (which is generally log(number of imports) assuming a reasonably balanced dependency tree).

Even if other cases show a significant performance difference, I think being able to move features in to a library is such a huge advantage that it would be better to do that and work out ways to fix any performance issues later on. This is exactly what the [extensible web manifesto](https://github.com/extensibleweb/manifesto) is about: build low-level capabilities, and then you don't have to spec or implement more advanced features on top of that, they can be left in a library. I'm sure there's plenty that can be done to optimise a library-based approach - for example if preload scanning is really important, surely there can be a special "fetch document with preload scanning enabled" mode added which the library can also make use of. It's even possible, looking further ahead, that someone could have a streams-based WebAssembly HTML parser and even do all of that preload scanning in the library.

Since libraries can iterate quickly, it's even possible they could be faster than a built-in. I'm not sure what HTML imports says about the order of sequencing loading stylesheets and script, but our polyfill assumes no scripts call getComputedStyle on startup and allows all style to load in parallel to script without waiting for them to finish. That's the kind of "cheating" optimisation you can experiment with, or enable as an option, in a library, since you can deviate from the strictness of the spec in the name of performance.

I'm convinced generic imports are a good idea anyway, so I think we should go ahead with that, and see how far we can get implementing HTML Modules on top of that. I'm willing to write the library that does it (we'll probably use it ourselves). It may be that we can actually make an optimal and production-grade HTML modules implementation on top of generic imports, in which case we saved a lot of spec and implementation work!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/645#issuecomment-315799339