HTML Import Deprecation?

[rogerkaplan]

What is the Onsen team planning to do about the deprecation of HTML Import?
It seems that the industry has “voted” for ES6 modules instead. HTML Import was never implemented natively except by Chrome, and Chrome has now removed it as of Chrome 73.
HTML Import appears to be a key enabling technology for Onsen. The polyfill still works (for now) but depends on XMLHttpRequest then special handling of scripts, css, and html. This doesn’t seem to be a viable long-term solution, and is certainly not performant the way that native HTML Import promised to be!

[emccorson]

There is an ES modules version of Onsen UI as well as the regular version. I’m not sure I understand how HTML import is a key enabling technology for Onsen - can you explain it please?

[rogerkaplan]

I’m somewhat new to this, so I’m going to explain it from my current mental model. Please point out if I’m wrong.

From what I can see, the HTML Template is the main component boundary in Onsen. Navigator actions use the template construct to navigate pages, and composite structures such as the tabbar and splitter depend on templates to bundle the things they’re compositing.

The templates are referred to by NAME.html, where NAME.html is either the id of a <template> in the existing document, or a file with the same name in (I think) the same directory as the host file.

The HTMLTemplate spec, which allows deferral of parsing the source HTML and scripts until the template is loaded, seems to now be broadly supported across key browsers since at least 2015, and specifically in iOS Safari and Chrome/Chromium on Android. This part works great.

Previous to last year-ish, it appears that custom elements, templates and html import functions were bundled together as the core technologies enabling “Web Components”, but Chrome was the only browser which actually implemented all of them. And Chrome gave up and ended support for HTML Import in March. I also read somewhere that the HTML Import functionality is being superseded by ES6 module imports. I’m still trying to figure out how this substitutes for HTML Import, which appears to be much simpler. With modules, it seems that the browser determines a module dependency graph based on satisfying import requests with export declarations, just like traditional linkers. This seems to be different than loading an arbitrary html source file, optionally and on demand.

I tried tracing the Onsen code to figure out the mechanism it uses to retrieve the template when it’s in its own file. I got a bit lost but it seems to be using a polyfill not a browser-native technique. Although this may work for now, I find it dicey and subject to breaking in the future.

So far I have ignored this problem and used a single source file. As my pilot has grown (successfully, btw, thanks Onsen!) I’m at over 1k lines of source, which is not really sustainable.

In addition I’m concerned about the latency implications of having the “app” wait for more html/js to load when navigating, especially since each template file is relatively small. I’m currently debating putting each template into its own file, but preprocessing and generating a single html file for download to the browser in one shot.

Any insight would be appreciated!!

EDIT: After jumping back into this, I ran some experiments and confirmed that in the internal.js file, an external template is loaded by requesting the raw data using XmlHttpRequest, creating a template tag, appending the raw html, using document.importNode() to add it to the DOM, then searching the document for all scripts, extracting their text, creating new script nodes, appending the text, then replacing the original script node (which I assume is what is necessary to run the script).

Again, this process seems dicey to me…?