Now a correction:
On Tue, Nov 19, 2013 at 4:25 PM, John J Barton
<johnjbarton@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