Update, Juni 27: It seems that some of the weird comments here originated from a misunderstanding. This article isn’t about the web — HTML is the language of the web, no doubts. The Developer Day was about building applications, the ones you download — like Firefox, Songbird or Joost.
Mozilla Developer Day in Paris was great. I still cannot believe that I sat at the same table with Daniel Glazman and Benjamin Smedberg (but in our modern times there is proof). There were lots of people I always wanted to meet in person and many interesting talks. The Joost guys delivered a very impressive demo. But the best of it were the discussion sessions. 70 XUL developers in one room — this doesn’t happen too often.
I want to write about one particular discussion session because I think that it might be interesting to people who weren’t there. It was titled “XUL dark matter” but that’s not really what we talked about. Instead, Benjamin Smedberg confronted us with a very provocative question: why do we use XUL and what would it take to get us switch to HTML?
Are you puzzled? I think many people were. Was that a serious question? The advantages of XUL are too obvious: the box model, powerful localization mechanism and user interface widgets with native look-and-feel. But it isn’t that simple. The box model can be used from HTML as well, just take a look at Mozilla’s CSS extensions (e.g.
display: -moz-box and
-moz-flex: 1). The same DTDs can be used to localize XHTML just like XUL, and soon peterv will hopefully open us the whole new world of remote DTDs. Even supporting the same mechanism in regular HTML is not unthinkable, the standard allows it (I suspect however that there will be technical issues due to traditional abuse of doctypes in HTML). Finally, there is hope that some XUL widgets can be standardized for HTML (some as part of HTML5, some for later versions of HTML — it is a long-term effort). So the question is, why do we still need XUL?
As it turns out: it isn’t about the features. Ben Bucksch was the first to recover from the shock and to note the cultural aspects. XUL developers would prefer their “own” language simply so they don’t get mixed up with the FrontPage crowd. Currently there are entire worlds between a XUL developer and an HTML “developer”, and this separation is there to stay. I continued with a similar thought: the beauty of XUL is all the things that it cannot do. It cannot do table-based layouts or relative positioning (everybody who ever “inherited” a web application will probably appreciate this a lot). It doesn’t do all the numerous quirks to be compatible with all browsers including Mosaic 1.0. It doesn’t even have a quirks mode! It is a simple and straightforward language built for one and only one reason: to enable efficient development of user interfaces. It is meant for one and only one platform: Gecko. And for one and only one version of it: whatever the current version is at the moment. Yes, it is not backwards compatible, and we sometimes have to suffer because of it. But at least bugs are fixed instead of being preserved for all eternity.
HTML isn’t going away, but I hope Mozilla Corporation will recognize that XUL isn’t going away either. Of course, having to maintain similar yet not identical widgets for both XUL and HTML requires more resources. But giving up on XUL is not the solution. Adjusting XUL wherever necessary to allow code reuse between XUL and HTML seems more realistic to me. For example, <datepicker> in XUL could be changed to behave like <input type="datetime"> in HTML5. This is still a painful process especially because the changes cannot be done all at once but it should be doable.
All in all the developer day was far too short. There was too much to see and discuss for one day, which is why the demo session for example took three hours instead of the expected one hour. AllPeers promised us another developer day in Prague in September and I want to go even if TomTom decides not to sponsor the trip. Hope to see more of you there!