Firefox OS Development: Web Components and Mozilla Brick

In this edition of “Firefox OS: The platform HTML5 deserves” (the previous six videos are published here), Mozilla’s Principal Evangelist Chris Heilmann (@codepo8) grilled Mozilla’s “Senior HTML5 Engineer Angle Bracket Coordinator” Matthew Claypotch (@potch) about the exciting new possibilities of Web Components for Web App developers and how Mozilla’s Brick library, a collection of custom elements to build applications with, can help with the transition. You can watch the interview on YouTube.

The Why of Web components

There is a problem with the Web as a platform for applications: HTML, the language that makes it easy to mark up documents and give them meaning doesn’t have enough elements to build applications. There are quite a few new elements in the HTML5 spec, but their support is sketchy across browsers and there are still a lot of widgets missing that other platforms like Flex or iOS give developers out-of-the-box. As a result, developers build their own “widgets” like menu bars, slider controls and calendars using non-semantic HTML (mostly DIV elements) and make them interactive using JavaScript and theme-able using CSS.

This is a great workaround but the issue is that we add on top of the functionality of browsers instead of extending the way they already function. In other words, a browser needs to display HTML and does a great job doing that at least 60 frames per second. We then add our own widget functionality on top of that and animate and change the display without notifying the browser. We constantly juggle the performance of the browser and our own code on top of it. This leads to laggy interfaces, battery drain and flickering.

To work around that problem a few companies and standards body members are working on the Web Components specification which allows developers to extend the browser’s understanding of markup with own elements. Instead of writing a slider control and make it work after the browser already displayed the document, you define a slider element and become part of the normal display flow. This means our widgets get more responsive, don’t work against the browser’s rendering flow and all in all perform better. Especially on low spec mobile devices this is a massive win. The whole thing already happens: if you for example add a video element to the document you see a video controller with a timed slider bar, a play button and volume controls. All of these are HTML, CSS and JavaScript and you can even see them in the debugging tools:

Anatomy of a video element

Firefox OS, being targeted at low end devices can benefit a lot from widgets that are part of the rendering flow, which is why Mozilla created Mozilla Brick, a collection of custom elements to build applications with. Earlier we introduced the concept using a library called XTags, which powers Brick. Using Brick, it is very simple to create for example a deck based application layout using the following markup:


  
    0I'm the first card!
  
  
    1
    
      These cards can contain any markup!
2

The resulting app consists of three decks that can be animated into another without having to do anything but call a deck.shuffleNext(); function.

Web Components are a huge topic right now and many libraries and frameworks appear each week. We hope that by using Brick we can enable developers to build very responsive apps for Firefox OS quickly and cleanly and leave the pain of making your app perform really well up to the OS.

About Chris Heilmann

Evangelist for HTML5 and open web. Let's fix this!

More articles by Chris Heilmann…


10 comments

  1. Ivan Dejanovic

    I just ran couple of demos from Bricks web site and they look very nice.

    What I noticed in the article that X-Tags are foundation for Brick, if I understood the article correctly. So I went to X-Tag site and saw the browsers that are supported. What caught my attention was IE9+ compatible.

    I tried Brick demos in IE8 the default browser on my company provided computer, the one I use for work, and found they don’t work.

    As a developer I have latest Firefox and Chrome installed on my work computer but all non developers in the company I work for, it is a large international US owned company, have only IE8. We had clients, international financial institutions, that had an explicit request that products we deliver to them must work in IE7.

    I am not sure what is the current market share of each IE version, but I now a lot of companies are slow to adopt new version. Is there any plan of making X-Tag and Brick work on IE8 and lower version? There are still users that at work at least have to work with browsers installed by the company and who can not change or upgrade them.

    Thanks for the great presentation and please keep working on Brick. It seems promising.

    September 27th, 2013 at 01:59

    1. Chris Heilmann

      Hello Ivan,

      currently there is no drive to make web component based solutions backwards compatible with older versions of Internet Explorer, mainly because the architecture of that browser was incompatible with the agreed standards the whole idea of web components is built on. I understand your frustration and the best way to work around is let the bricks fallback to a simpler interface. A deck for example could be a list with anchors to jump to.

      Support for older IE is a massive overhead in testing any new app and in most cases the effort is not justified looking at the amount of users. In your case there is a company policy reason not to upgrade, but the sad truth is that it is simply dangerous to run outdated software of any kind on computers connected to the web. Old Internet Explorer is not only a nuisance for web developers, it is a very interesting attack vector for crackers and malware distributors. Even Microsoft has given up on IE6 (http://www.ie6countdown.com/).

      September 27th, 2013 at 02:25

    2. Doug Reeder

      As Chris Heilman notes, supporting older browsers (mainly IE) is a huge sink of time for web dev (and one that is rarely called out in budgets).

      The usual way to support older browsers is to use a framework that smooths over the differences. If you want a component-style framework that supports IE8 and later, Dojo (http://dojotoolkit.org/) is a popular choice, while Enyo (http://enyojs.com/) is better if you want to support both mobile and desktop.

      If you need to support IE6 and 7, version 1.8 and previous of Dojo support it.

      September 27th, 2013 at 13:52

  2. pd

    Not having to turn on the display of psuedo element styles from a submenu, as is the case in Firebug, is an improvement. Responsive design tools are an improvement that Firebug does not yet have.

    For all those Firebug users out there, whom Mozilla appears to have shifted focus away from, please, for the love of the open web, look into this bug:

    https://bugzilla.mozilla.org/show_bug.cgi?id=815603

    as a matter of priority. After all, people have been using Firebug for years. Mozilla encourages people to support the open web and thus Firefox. Developers are the ones who ensure standards are followed, we’ve been punching away at keyboards and clicking Firebug tabs for years in an attempt to build your open web. We deserve a functional Firebug.

    September 27th, 2013 at 07:13

    1. pd

      Whoops, sorry re above, wrong tab, meant to post here: https://hacks.mozilla.org/2013/09/new-features-in-the-firefox-developer-tools-episode-26/

      September 27th, 2013 at 07:15

  3. nadrimajstor

    A noob question:
    How to get to those shadow DOM elements in FxOS (shown on upper picture/video tag element) ?

    September 28th, 2013 at 14:13

  4. Aras

    I am very excited about Brick and web components in general, I think they are making developing web app much easier and more fun.

    I am wondering if there is going to be a CDN for latest build of brick, or maybe it will be added to jsfiddle. While demo page is great way to show off what components are available, I think it would be even better if people could start interacting with the code right away.

    My other question is about the roadmap for Brick. How can I find out what components are on the road map, and what features and components are highly demanded by developers.

    Very happy to see this blog post, keep up the great work!

    September 28th, 2013 at 16:01

    1. Fred

      It might very well be added to JSFiddle. What a great idea. We’re good friends with the author and can ask him to consider it!

      October 1st, 2013 at 13:43

  5. niutech

    Is it possible to mix X-tags, Bricks and Polymer elements together in one app? Are they compatible? Can an X-tag rely on or contain a Polymer element?
    And why aren’t Offcial Firefox OS Building Blocks made of Web Components?

    September 29th, 2013 at 11:37

  6. DL

    While web components do provide tremendous advantages in terms of structure, it is somewhat unclear why web components are better in terms of performance. It is true that conventional widgets are implemented on top of the browser, but isn’t it also true of web components, since they are also defined using HTML/CSS/JavaScript?

    Conventional widgets probably take more time to initialize, but once a widget is created, it would work pretty much the same way as a web component: some JavaScript code manipulates DOM and the browser renders it. In other words, I don’t quite get what you mean by “animate and change the display without notifying the browser” or “work against the browser’s rendering flow”.

    October 2nd, 2013 at 04:41

Comments are closed for this article.