At first glance, I’m disappointed by this. Perhaps my take will change as I spend more time with Web Components, but to me HTML imports was a really key feature. ES6 modules are great, but AFAIK they only package JS. Being able to package a web component (template, and all associated assets) and distribute it without further dependencies is not only appealing and convenient but a key factor in making web components as a whole successful.

I realize that reconciling ES6 modules and HTML imports is likely a necessary step, but I hope that Mozilla eventually reconsiders implementing HTML imports after some consideration and dialogue with the community and other vendors.

1. dima

   There is at least one polyfill for that, why would you need it to be shipped with the browser? Do you think it would be so much faster? I don’t think so.

   Also, the polymer project build a tool called “vulcanize”, and it glues all the html pieces together: that would avoid the extra network requests, which are actually the thing that you should avoid.

   December 15th, 2014 at 13:07
   1. laurentj

      a polyfill + an other polyfill + an another polyfill +… Web sites become bloatware because of lack of support of some technologies in some browser.

      It seems that some web developers (and browser developers) don’t tests their web site on mobile in the real life (e.g., with a bad connectivity most of time).

      December 15th, 2014 at 14:33

   2. Ivan

      There is jQuery, why would you need to put ‘native functions’ like querySelector on browsers?

      We could use IE6 + jQuery forever! Whoooooooa…

      jQuery > ALL

      /sarcasm…

      December 16th, 2014 at 04:21

   3. Erik isaksen

      As for vulcanize – my understanding is that once we are all on http2 concatenation will not be as necessary as it is now. In that vein, vulcanize is a temporary but needed fix for now. Maybe I’m missing something but that’s how I see it. Es6 modules have a much different purpose than imports because they only package JS by design. Portability is a very important feature for Web Components.

      December 17th, 2014 at 02:11

   4. Adam

      AFAIK polyfills cannot parallelize downloading of web components, unlike native HTML imports. That’s why they should be implemented natively.

      December 18th, 2014 at 15:44

2. Erik Isaksen

   I agree that HTML imports are very appealing. It serves a much different purpose than a JS module despite some similarities

   December 17th, 2014 at 02:06

Hi,

i’m extremely pleased to read that Mozilla is considering to move forward with Web Components.

I agree that HTML imports is not a strict requirement – it can be accomplished by various other techniques though it wouldn’t probably a that big thing to implement.

Native Shadow DOM would be really great to see in Mozilla – following Chrome’s example here would make an impact on the other vendors i hope. Progress on the related styling issues would be highly welcome.

Speaking of my own experience with standards bodies (esp. in W3C) i wish the dev team some boldness to also follow your own opinions even if not everything has been settled in the standard. I found it much more effective to draft and implement your own solutions and take them back to the working group as a working example. IMO such an approach often has more impact on the standardisation process than fighting the words.

Since Html Imports is a core part of web components, I think you should implement it. I do agree maybe holding off a little while until things are better understood, ie the relation of es6 module loader and html import interaction. The de-dup portion of html imports need some work as that has concerned me of having 10 copies of the same library bundle with each web component and because its from a different url, they don’t get de-duped.

So yeah we need to reconcile dependency management with a nice solution for both javascript and html. The Polymer project relies heavily on html imports and since it is a spec of web components it should be implemented, but that is not to say you can’t suggest changes to the spec.

Main point is once the spec is finalized you should honor it. It really sucks having to handle different code just because you browser makers can’t agree.

Please make it easier on us web dev and try to make each browser the same from a code perspective. Please no browser wars, of this is better and I am just not going to implement this feature, lets get on the same page. Yes its work for you guys but the impact is grand, you browser devs are few compared to the mass of web dev that have to develop with your platform!! So think of us please!!

Glad to see that mozilla’s finally shipping web components to firefox. But I still do NOT think the reasons to not ship HTML imports mentioned in this post could stand. Yeah many features have polyfills. But letting the developers using Polyfills should not the first-choice of a browser developer.

Although HTML Imports are not required to create components, es6 modules were never meant to do what imports do.

I think you will find that fragmenting the support of such a feature will only encourage the ‘Package Manger Wars’ to keep going where we have so many Hacky ways of polyfilling this at compile time.

Imports are key in that they provide an easy way to package your element and distribute it WITHOUT additional dependencies.

Es6 modules could do some of this but do we, as a community, really want libraries and frameworks to build their own wrappers around this? Es6 was made for JS – it should not be ‘shoe horned’ into injecting CSS and HTML

1. Anne van Kesteren

   Eventually we want something standardized. The reason we are not doing HTML Imports as is now, is because we think its design would be quite a bit different if it was informed by what will come out of JavaScript modules, service workers, and exposing parts of HTTP/2 to JavaScript.

   We would like design to work the other way around. We hand web developers the primitives, and they design various compelling libraries and frameworks on top of that. And then we can see about standardizing something a tad higher-level to improve performance and take away some of the burden of having to use libraries.

   December 17th, 2014 at 08:52
   1. Laurentj

      > and exposing parts of HTTP/2 to JavaScript.

      So you want to wait many years before to see if html import is ok or should be improved ? Because, seriously, HTTP/2 is great, but it will take years before the time when it will be supported by the majority of millions of web server. So majority of projects could not use libraries or features that rely on HTTP/2.

      > And then we can see about standardizing

      Ok, you want to see web developers experimenting these new primitives to validate them. But you don’t want to see developers experimenting HTML import (which is, form my point of view, a “primitive” feature). :-/

      Sorry, I don’t agree with you.

      I don’t like the way taken by web technologies : year after years, we loose declaratives programming in favor of imperative programming, whereas in some context, declarative is better than imperative. The web didn’t exist if Tim Barners-Lee invents a kind of JS instead of HTML. It is so easier to understand and write web pages with HTML/CSS rather than with an imperative language…

      December 18th, 2014 at 02:29
      1. BrianC

         > Ok, you want to see web developers experimenting these new primitives to validate them. But you don’t want to see developers experimenting HTML import

         Ah, but nowhere is this sentiment stated in the article. The line “lack of HTML Imports is not a problem as the functionality can easily be provided for with a polyfill if desired” clearly indicates that Mozilla does not discourage (pardon the double negative) others from trying out HTML imports. The whole declarative/imperative + Tim Berners Lee argument is unfortunately a strawman, as it applies little to the subject at hand. This post never advocates for an imperative, JS-based alternative to HTML imports, nor does it advocate es6 modules as an alternative (note that the es6 module syntax is declarative). Neither does the article state that Mozilla will wait “many years” to analyze the status of HTML imports. Indeed, all of the features introduced are within the timespan of next year, so it’s still quite possible that FireFox will have HTML imports if web standards bodies can find some way to reconcile es6 and custom elements with regards to module systems.

         On that note, here’s a question: How would es6 modules and HTML imports interact? Currently, there’s no clear-cut consensus on this issue, but it’s imperative that there is a mutual understanding between both if HTML5 is not to break horribly. As far as I know, HTML5 imports operate on a completely different mechanism from es6 modules, meaning that they can’t interact with the System module loader. At the very least, this poses a problem with regards to imports including modules. How do you handle that if the module loader can’t interop with HTML imports? Currently, no browser vendor has a definitive answer. Despite backing both Polymer (which, contrary to popular opinion, is NOT the reference implementation for web components) and es6 modules, Google doesn’t have any notable strategy for handling the dichotomy between JS modules and HTML imports either.

         …and now I’ve written a load of incoherent blather. While I’d agree that Mozilla and co should work towards offering new web primitives to developers for experimentation, the decision to hold off on HTML imports appears justified when one considers the implications said feature has for modules in the browser.

         December 18th, 2014 at 12:08

      2. Anne van Kesteren

         Perhaps if HTML Imports provided a truly declarative way to component authoring you had a point, but alas, they do not. Script is required either way.

         December 19th, 2014 at 02:27

   2. Adam

      “…its design would be quite a bit different if it was informed by what will come out of JavaScript modules, service workers, and exposing parts of HTTP/2 to JavaScript”

      Sorry, I don’t get this mumbo-jumbo. Could you describe the reasons in simple terms?

      December 18th, 2014 at 15:50
      1. Tyler

         If you want to *eventually* see something standardized and given as a solution then you need to change the language in your blog post, because right now it sounds like you’re saying that you’re talking the ball and going home, WRT HTML Imports.

         In the meantime, consider adding these features you’re uncertain about as -moz- prefixes so that the web community can decide how it should be done through practice.

         December 29th, 2014 at 08:33

What is the actual problem that is stopping Mozilla from enabling the standard? The quote in the article (“…our feedback into the standards process has not always resulted in the changes required…”) does not inform – can you help us understand the issue with the standard?

Can you be specific about the JavaScript modules that should be used instead of Web Imports (is this JavaScript code modules?), how they resolve the issues you have with the W3C standard, and when we can expect them to be implemented? Is this going through a standardization process? Any links?

Thanks.

@Brett Zamir – thanks for your comment – those docs have been updated by the MDN team. Best, Havi

Mozilla,

Don’t be jerks and not implement Html Imports, it is a major part of the Web Component standards, does it have possible problems, Yes, can there be confusion on how Es6 module loader and Html Imports work together, Yes.

So what, Html Imports is a critical part of web components, and having to polyfill just sucks!!!!!!!. Go with the standard and do it. Things always change and at a later date when we figure out how html imports and es6 could work better or if one could replace the other, then implement that.

DON’T BE THAT GUY/GIRL just because you are not getting your way, we all agree that there is room for improvement in Html Import standard,your points are valid, but you need to implement it anyway!!!!

By not doing it you are hamstringing the whole Web Components Standard in the first place, Don’t Be Jerks!!

1. Anne van Kesteren

   Just to be very clear, “Web Components” is not a standard yet and only Google is currently shipping an implementation of sorts (not quite matching the specifications even). Therefore giving input into the process of “Web Components” becoming a standard is very much appropriate. You don’t get many attempts to do something right on the web.

   January 5th, 2015 at 00:56
   1. dan

      I understand getting it right, but that is one of the main reasons that web standards have been so haphazard. We end up having our own idea of what is right, good, and perfect, and in the end we just do our own implementations, which is different for ie,safari,chrome,firefox, ect. I think it is one thing we need to change, lets shoot for perfection but go ahead and accept something much less, something good enough, but at least a standard across browsers. Sorry for the harsh words, but at least from my stand point, I was planning on Mozilla following Chrome on Web Components because 2 major browser makers, helps push the others to follow suit, now it’s easier for other makers to not implement Web Components. I guess I am just tired of the Browser Wars, you implement this, we implement that, no one meets in the middle, and web devs suffer and have to just deal with it hence the million different js,html, css libraries to fill the gap. This just remindeds me of why I used firefox in the first place way back when IE where the guys who never followed standards and Firefox stood up and said we will and looked an IE as the guys causing the problems.

      Any way I have always liked FF and use it all the time, I am an early adopter going back to the Netscape days, even though I am not using it right now.

      I do realize Web Components are still not a standard yet but it has lots of press as well as Es6 which is not a standard but it looks like most browsers will implement, but that is another problem, taking 5 years or more to make a standard, way to long. It’s tough to get everyone to agree, I get it. But it would be really nice if we can keep the web moving forward and agree on standards as well.

      Sorry for the rant!

      January 5th, 2015 at 07:09

Hi @Anne van Kesteren, would you be able to comment on this HTML Exports library I came across:

https://github.com/nevir/html-exports

On another page the Author states:

“ES6 module HTML import interop is a bit weird, yeah. But they’re conceptually very similar, and it doesn’t take much to make them to play nice together…”

Are you able to comment as to whether his assertions makes sense or not?

Secondly, when you say that:

“…its design would be quite a bit different if it was informed by what will come out of JavaScript modules, service workers, and exposing parts of HTTP/2 to JavaScript”

Can you provide a more concrete example of what you think that might actually look like, just as an example. Are you, for instance, talking about projects like jspm.io that allow multi-asset libraries to be developed using ES6 syntax, and which @Guy Bedford even demonstrates could be used to develop web components?

Editor’s note: Thanks everyone for your questions and thoughtful comments and responses. The conversation will continue on the public-webapps standards list (http://lists.w3.org/Archives/Public/public-webapps/). Comments are now closed on this post.