I've been putting off a response on this, but I have some things to add...
The topic on this thread was originally HTML Imports - it seems like some
of the concerns expressed extend beyond imports and are a little wider
ranging. I am cross posting this comment to public-nextweb@w3.org as I
think it is related.
I share the concern about letting out an API too early, but I think my
concerns are different. In the past we worked (meaning browsers, devs,
stds groups) in a model in which things were released into the wild -
prefixed or not - without a very wide feedback loop. At that point, the
practical realities leave not many good options for course correction or
even for small, but significant tweaks. I think a lot is happening to
change that model and, as we can see in the case of everything with Web
Components (esp imports and selectors perhaps) the wider we throw the net
the more feedback we get from real people trying to accomplish real things
with real concerns - not just theory. Some of this experimentation is
happening in the native space, but it is behind a flag, so we are shielded
from the problems above - no public Web site is relying on those things.
And some of that is happening in the prollyfill space - Github FTW - in
projects like x-tags and polymer. When we really look down through things
it does feel like it starts to become clear where the pain points are and
where things start to feel more stable. With this approach, we don't need
to "rush" standardization in the large scale - if we can reasonably do it
without that and there seems to be wide questioning - let's hold off a bit.
HTML Imports, for example, are generating an *awful* lot of discussion - it
feels like they aren't cooked to me. But virtually every discussion
involves elements we know we'd need to experiment in that space - modules
would allow one kind of experimentation, promises seem necessary for other
kinds, and so on. There is a danger of undercooking, yes - but there is
also a danger in overcooking in the standards space alone that I think is
less evident: No matter how good or bad something is technically, it needs
uptake to succeed. If you think that ES6 modules have absolutely nothing
to do with this, for example, but through experimentation in the community
that sort of approach turns out to be a winner - it is much more valuable
than theoretical debate. Debate is really good - but the advantage I think
we need to help exploit is that folks like Steve Souders or James Burke and
W3C TAG can debate and make their cases with working code without pulling
the proverbial trigger if we prioritize the right things and tools to make
it possible. And no ones code needs to break in the meantime - the
JS-based approach you use today will work just as well tomorrow - better
actually because the perf curve of the browser and speed of machines they
run on is always up.
I don't think that "perfect" imports is necessarily the lynch-pin to value
in Web Components - it needn't block other progress to slow down the
standard on this one. Other things like document.register already feel a
lot more stable. Finding a way to evolve the Web is tricky, but I think
doable and the Web would be a lot better for it if we can get it right.