Now a correction: On Tue, Nov 19, 2013 at 4:25 PM, John J Barton <johnjbar...@johnjbarton.com>wrote:
> Last is an asynchronous "declarative" model (quote because such solutions > are not declarative). > Broadly I am advocating using ES6 modules with HTML imports. The particular example I made up earlier was patterned after ES6 asynchronous loading, here I repeat it: <script> System.component("import.php", function(component) { var content = component.content document.getElementById('import-container').appendChild(content.cloneNode( true)); }); </script> How does this differ from Dimitri's <link rel="import" async href="/imports/heart.html"> Well not as much as I claimed before. Both cases are parsed synchronously and cause subsequent loading. Both can trigger module loading recursively, my made up version by wiring ES6 module loading to allow inputs to be HTML Imports and Dimitri's version through subimports. The primary difference in this "starting the load" operation is the callback. In my made up version the callback would follow the System.load() pattern from ES6. In Dimtrii's version you have to have a separate <script> tag with an event handler and an event triggered by the import. If the application needs no callback, these two forms are draw on all counts. So the crux of a ES6-compatible solution is a JS loader supporting component loading. If the JS in an HTML import does not import any JS modules, then asynchronous module loading works, we just don't get JS modularity. So I'm back to "these don't compete". I think integrating ES6 modules with HTML Imports can be on ES6. The ES6 solution would be better for the reasons I outlined previously but everything is better in the future. jjb