Mozilla Hacks

An Update on Web Components and Firefox

Avatar photo By Soledad Penadés

Posted on November 20, 2015 in

Web Components is an umbrella term for four technologies that aim to make UI development easier and more modular. It has been in development since about 2011: a very long time for Internet standards!

All the specifications have been changing constantly as more vendors have started implementing them, and also as developers have gained real world experience in using them.

Therefore, it’s only natural that we are all confused as to what is and what is not natively available in each browser.

To date, in Firefox:

  • Only <template> is natively available.
  • The first iteration of the new consensus-based Shadow DOM is expected to ship in the first half of 2016. You can read Anne’s and Wilson’s posts for more details.
  • There was an initial implementation of Custom Elements, based on prototypes, which is also the version Blink shipped, but Apple’s Ryosuke Niwa is fleshing out some experiments to come up with new approaches that use the ES6 class syntax instead. There won’t be active work on Custom Elements on Firefox until consensus is reached.
  • HTML Imports are not shipping, as we want to wait to see what developers do with ES6 modules. There was an early unfinished implementation which will be removed.

We are very aware that keeping track of these changes is time consuming for developers who want to make sure their web components code works in more than just one browser. We’re addressing this issue by creating the Web Components Status in Firefox page in MDN. It will hold up to date information on what is implemented in Firefox, and any caveats you might encounter, so you can refer to it whenever you want to check what is available or not.

With thanks to Wilson Page, Anne van Kesteren, Andrew Overholt and Jean-Yves Perrier for their insights on this topic!

About Soledad Penadés

Sole works at the Developer Tools team at Mozilla, helping people make amazing things on the Web, preferably real time. Find her on #devtools at irc.mozilla.org

More articles by Soledad Penadés…

7 comments

  1. phil

    “We want to wait to see what developers do with ES6 modules”

    You said the same thing one year ago (https://hacks.mozilla.org/2014/12/mozilla-and-web-components/ ).
    Now ES6 modules are here, so what are we still waiting for ?

    I don’t think you should “wait to see what developers do”.
    Developers will use what Fb, Google, Mozilla, etc… propose to them, they won’t invent their own framework & patterns just to make their own app, they’ll use those available to them.

    Facebook makes react, Google has polymer,… it’d be nice for Mozilla make their own (and this time not abandon it like brick) that would not only allow to make web sites, firefox OS app, etc… but would also prove that Mozila’s choices of web standards are coherent ( for eg here it would show that HTML Imports are not necessary and that we can have a cleaner solution with ES6 modules).
    But otherwise it’s kind of easy to say “we like that” or “we’re against it” without having any solid framework/proof-of-concept to prove your point.

    November 23rd, 2015 at 15:16

    1. Soledad Penadés

      To add some perspective, ES6 just become an standard in *June 2015* – that’s less than five months ago. Although there are many ES6 features implemented in browsers already, modules are not implemented yet, and developers can only use imports by “transpiling” their ES6 code to “normal JavaScript” using some tool such as Babel. But that means that you’re not testing out how the real imports would work, and therefore browser makers cannot make decisions based on what a polyfill does, because when the real implementation happens, it might behave differently to what the polyfill did due to platform limitations. This is *very dangerous*, specially if you’re loading *code*.

      Using polyfills is not “a solid framework” or “proof of concept”, but a “temporary solution based on the draft of a standard” that should help developers inform browser makers on what’s good or not for the web platform. It’s a draft. An exploration. Work in progress. Working together—developers and browsers!

      In parallel to this, the people working on Firefox OS have been exploring using web components without HTML imports, and pretty much all of the UI is now built using components. They have also raised interesting points that have been taken into account for changing parts of the spec, based on actual usage and real-life experience. You can have a look at them here: https://wiki.mozilla.org/Gaia/Shared/Components

      November 30th, 2015 at 02:00

  2. Uruguayan Salamander

    ES2015 modules and HTML imports serve very different purposes and work completely differently. Sure, you could import a .js file with the element’s shadow DOM HTML in a multiline string, but that’s clearly going against the grain. Surely its understood to use modules for code, and imports for HTML?
    In a similar vein, logic would be questioned if a browser vendor blockef shipping ES2015 modules, because the equally-functional alternative of bundling dependencies on the server exists

    November 25th, 2015 at 05:50

  3. gian

    For those who want to try web components today without the bloat of huge frameworks there is http://riotjs.com . In riot we are able to render and manage 100% web components in only with 18kb. Riot is really valid crossbrowser performant alternative to the current native web components feature. Check it out and give us your feedback on github

    November 26th, 2015 at 09:00

  4. Lunatic Lambda

    You really can’t blame people to chose to invent more and more frameworks and libraries to do what they want. To wait a thing become standard and implemented by major browsers for 4 years, or chose a framework can meet your customers’ need in 3 days, that’s never the question.

    November 29th, 2015 at 19:09

  5. Ivan Dejanovic

    Soledad Penadés thanks for the Gaia components. Link for remote repo and demo page are broken unfortunately.

    December 2nd, 2015 at 03:18

    1. Soledad Penadés

      Sorry, Ivan—turns out the components are being renamed from being prefixed gaia- to fxos- to make it clearer where do they come from.

      The demo page is now at http://fxos-components.github.io/gaia-components/ and the organisation is called fxos-components: https://github.com/fxos-components/

      The change just happened yesterday so it was a bit of unfortunate timing!

      December 2nd, 2015 at 06:37

Comments are closed for this article.