Tag Archives: firefox os

Extensible Web Summit Berlin 2014: my lightning talk on Web Components

I was invited to join and give a lightning talk at the Extensible Web Summit that was held in Berlin past week, as part of the whole JSFest.berlin series of events.

The structure of the event consisted in having a series of introductory lightning talks to “set the tone” and then the rest would be a sort of unconference where people would suggest topics to talk about and then we would build a timetable collaboratively.

My lightning talk

The topic for my talk was… Web Components. Which was quite interesting because I have been working/fighting with them and various implementations in various levels of completeness at the same time lately, so I definitely had some things to add!

I didn’t want people to get distracted by slides (including myself) so I didn’t have any. Exciting! Also challenging.

These are the notes I more or less followed for my minitalk:

When I speak to the average developer they often cannot see any reason to use Web Components

The question I’m asked 99% of the time is “why, when I can do the same with divs? with jQuery even? what is the point?”

And that’s probably because they are SO hard to understand

  • The specs–the four of them– are really confusing / dense. Four specs you need to understand to totally grasp how everything works together.
  • Explainer articles too often drink the Kool Aid, so readers are like: fine, this seems amazing, but what can it do for me and why should I use any of this in my projects?
  • Libraries/frameworks built on top of Web Components hide too much of their complexity by adding more complexity, further confusing matters (perhaps they are trying to do too many things at the same time?). Often, people cannot even distinguish between Polymer and Web Components: are they the same? which one does what? do I need Polymer? or only some parts?
  • Are we supposed to use Web Components for visual AND non visual components? Where do you draw the line? How can you explain to people that they let you write your own HTML elements, and next thing you do is use an invisible tag that has no visual output but performs some ~~~encapsulated magic~~~?

And if they are supposed to be a new encapsulation method, they don’t play nicely with established workflows–they are highly disruptive both for humans and computers:

  • It’s really hard to parse in our minds what the dependencies of a component (described in an HTML import) and all its dependencies (described in possibly multiple nested HTML imports) are. Taking over a component based project can easily get horrible.
  • HTML imports totally break existing CSS/JS compression/linting chains and workflows.
  • Yes, there is Vulcaniser, a tool from Polymer that amalgamates all the imports into a couple of files, but it still doesn’t feel quite there: we get an HTML and a CSS file that still need a polyfill to be loaded.
  • We need this polyfill for using HTML imports, and we will need it for a while, and it doesn’t work with file:/// urls because it makes a hidden XMLHttpRequest that no one expects. In contrast, we don’t need one for loading JS and CSS locally.
  • HTML Imports generate a need for tools that parse the imports and identify the dependencies and essentially… pretend to be a browser? Doesn’t this smell like duplication of efforts? And why two dependency loading systems? (ES6 require and HTML imports)

There’s also a problem with hiding too much complexity and encapsulating too much:

  • Users of “third party” Web Components might not be aware of the “hell” they are conjuring in the DOM when said components are “heavyweight” but also encapsulated, so it’s hard to figure out what is going on.
  • It might also make components hard to extend: you might have a widget that almost does all you need except for one thing, but it’s all encapsulated and ooh you can’t hook on any of the things it does so you have to rewrite it all.
  • Perhaps we need to discuss more about use cases and patterns for writing modular components and extending them.

It’s hard to make some things degrade nicely or even just make them work at all when the specs are not fully implemented in a platform–specially the CSS side of the spec

  • For example, the Shadow DOM selectors are not implemented in Firefox OS yet, so a component that uses Shadow DOM needs double styling selectors and some weird tricks to work in Gaia (Firefox OS’ UI layer) and platforms that do have support for Shadow DOM

And not directly related to Web Components, but in relation to spec work and disruptive browser support for new features:

  • Spec and browser people live in a different bubble where you can totally rewrite things from one day to the other. Throw everything away! Change the rules! No backwards compatibility? No problem!
  • But we need to be considerate with “normal” developers.
  • We need to understand that most of the people cannot afford to totally change their chain or workflows, or they just do not understand what we are getting at (reasons above)
  • Then if they try to understand, they go to mailing lists and they see those fights and all the politics and… they step back, or disappear for good. It’s just not a healthy environment. I am subscribed to several API lists and I only read them when I’m on a plane so I can’t go and immediately reply.
  • If the W3C, or any other standardisation organisation wants to attract “normal” developers to get more diverse inputs, they/we should start by being respectful to everyone. Don’t try to show everyone how superclever you are. Don’t be a jerk. Don’t scare people away, because then only the loud ones stay, and the quieter shy people, or people who have more urgent matters to attend (such as, you know, having a working business website even if it’s not using the latest and greatest API) will just leave.
  • So I want to remind everyone that we need to be considerate of each others’ problems and needs. We need to make an effort to speak other people’s language–and specially technical people need to do that. Confusing or opaque specs only lead to errors and misinterpretations.
  • We all want to make the web better, but we need to work on this together!


With thanks to all the people whose brain I’ve been picking lately on the subject of Web Components: Angelina, Wilson, Francisco, Les, Potch, Fred and Christian.

Audio for the masses

The video above is from LXJS – the Lisbon JavaScript conference, which happened more than a month ago. I gave this talk past week again at VanJS, so I decided it was time for that belated write up on this talk.

If you want to follow along, or play with the examples, the slides are online and you can also check out the code for the slides.

As I’ve given this talk several times I keep changing bits of the content each time depending on what the audience seems more interested in, plus I also sometimes improvise stuff which I don’t remember when writing the final write up, so if you were at any of the talks and see that something’s missing or different now you know why! I’ve also added a section at the end with frequent questions I’ve been asked, hope that’s useful for you too.

Continue reading

Invest in the future: build for the web!

I spoke at GOTO Amsterdam a few weeks ago. I was really thrilled to be back in the Netherlands after so many years! So thanks to Sergi Mansilla, who curated the HTML5 track, and the organisation in general for bringing me there!

The talk wasn’t recorded, but I made a screencast just in case you really want to listen to me. I am also posting the outline/notes I wrote, and they differ in places because I don’t read them during the talk (I don’t even have them handy) and I sometimes went a bit off topic, but that’s the beauty of improvisation!

Here are the slides, and the slides source code just in case you wanted it too.

On to the notes-expect some MASSIVE GIFs and amazingly clever photomanipulation! tee hee hee!
Continue reading

From the city of FOMOnto

I seriously intended to write three (three!) blog posts past week-end but I got dragged outside to experience the glorious British Spring in London, and its pubs and stuff, and I ended up not writing anything at all. But it was good because it was Easter and you’re supposed to have a break sometimes.

Then I had this very intense work week here in Toronto which was full of discussions, pair programming, presentations, hack hack hackety hack, more discussions, and even a double session of bad 80s/90s movies to top that. The Mozilla Toronto office is packed full with so many rad people that great conversations happen all the time, so I didn’t really have the time to write any of those three posts.

But I have some cool stuff to show/discuss, so there we go before I fly back to Europe:

First, just in case you’re interested – here are the slides of my presentation: our projects, in the future. Without any context you won’t actually get most of the points, but that’s to be expected. I want to get back to this in a blog post because it’s something that every open source project should be doing, so don’t worry if you don’t follow along.

My talk ended with me trying to plant two seeds in the minds of my team mates, the first one being that we should aim to be the open source developer we would like to see. So whenever you’re unsure of what to do, pretend you’re that ideal perfect developer and act as they would do. The second idea was an automatic “good open source citizen” ACID test, and hey, tofumatt and me hacked a prototype together. Here’s acidity, which you can also install with the node package maid with

npm install -g acidity

then cd to any of your projects and run acidity, and maybe you’ll get some cool emoji.

Also, not something that I took part in, but Potch came up with a nice hackxperiment which enables you to write CommonJS-style code in WebWorkers, with the notion of making it easier to move more business logic into Web Workers so that the main thread is snappy and responsive. He also happened to say “Shadow DOM” out aloud and BAM! Angelina Fabbro (from Inspector Web and the mystery of Shadow DOM fame) entered the room. Was this staged? We’ll never know.

Another ultraexciting thing that happened was that I finally had early access to the brand new App Manager in Firefox’s DevTools. With this version you can create new Firefox OS apps straight from its interface, edit them, open existing projects, deploy and debug them, etc. The UI is way (WAY) more streamlined now—you don’t need to switch back and forth to go from debugging to deploying, and you can simply use some natural shortcuts: CTRL+Save / CTRL+Reload. This makes developing privileged FxOS apps really webby and it feels GREAT. Here’s an early screenshot so you can drool:

App Manager v2

The way I got access to this version was by checking the code out of Paul Rouget‘s Firefox branch and compiling it. I’m told I was the first person that run this new AppManager apart from its own developers, so I suppose that means ACHIEVEMENT UNLOCKED. Paul warned me of some potential weirdnesses but I couldn’t reproduce them.

For those of you curious, compiling took about 30 minutes and 5 Gb of disk space, on a MacBook Pro. I’m told that subsequent compilations should be way faster but I haven’t got to that yet.

More cool things from this week: I will be mentoring a Google Summer of Code student this summer! The project is about Firefox OS games. Isn’t it exciting?!

I also got confirmation that I’ll be speaking at an awesome conference in June. I’ll be actually speaking at two awesome conferences in June but I still haven’t announced the first one as that’s one of the posts I wanted to write, with my own promo code and stuff.

We also had a mini meatspaces meatup with some great Torontonians, where it was decided in a sideway non-important comment in passing that Toronto should be renamed to City of FOMOnto. Note to non-insiders: FOMO = Fear Of Missing Out. Fun fact: I used to think that FOMO meant Fear Of Making Out for a long time.

Now if you excuse me I have to perform some ~~~magics~~~ and fit all my stuff back into the suitcase. Stay tuned!

Failproof AJAX requests in Firefox OS

Have correct values in the manifest

The app type has to be at least privileged. No, web (hosted) apps won’t work with different domains if CORS is not enabled there.

Add the systemXHR permission too, or your XMLHttpRequests to domains without CORS enabled will instafail.

Example of the syntax for these two things in the manifest:

  "type": "privileged",
  "permissions": {
    "systemXHR": {
      "description": "Allows loading remote content"

Add the “magic word” when creating XMLHttpRequest objects

The magic word being the mozSystem property:

request = new XMLHttpRequest({ mozSystem: true });

You should now be able to use the request in the usual way. Remember to add an error handler in case it fails!

We are using these superfailproof requests in our privileged app template to load definitions from MDN. Have a look!

For more info