Good news is never as interesting or as powerful as bad news. So while the majority of this document will be laying into XBL and its Mozilla implementation, I'd like to issue one caveat up front: XBL is, fundamentally, a Good Idea.
Unfortunately, its goodness is mostly in the idea itself, and little else. But it is a good idea to discretely and in an object-oriented fashion design more powerful widgets, composited out of the existing widgets and event system. It is a very powerful approach, which is why despite the righteous thrashing I'm about to deliver the technology, I still like it enough to extract the core idea and re-create it in a more usable form.
By "the XBL specification" I mean the XML files that make up the XBL specification, not the internal implementation.
I emphasize that because when examining the benefits of using XML there are two types of benefits that must be examined distinctly. First, there are the benefits of the XML syntax, and secondly, there are the benefits that accrue from standardizing on anything at all, not just XML.
XML does have some unique benefits:
- Cross-platform: Everybody can parse XML. Parsing XML is only the beginning, but it is a good beginning.
- Namespaces: XML provides a clean namespace mechanism, allowing the embedding of multiple distinct types of content in one document.
- Entities: A defined text-variable substitution system, though in my opinion the benefits of this are often oversold. It is often used for internationalization in Mozilla but a simple lookup scheme is inadequate to that task.
- Associated Technologies: Like XSL and of course DOM.
The question is, how much does XBL benefit from these technologies? And my answer is that in practice, very little.
XBL's benefits come not from standardization on XML, but on standarization period. By standardizing on XML, you get some degree of cross-platform compatibility and the other benefits of XML.... But you also inherit XML's flaws. And XML flaw number one, of course, is that it makes an absolutely crappy programming language to write in.
The problem with XML as a programming language is that syntax is a very important aspect of a programming language; there is only syntax, semantics, and library. By trying to jam a language into XML, you're choosing a meta-syntax not designed for programming languages, and you still have to create a syntax on top of it! There are some projects that use XML as a base language and allow you to edit any of several transformations of the base XML data; they have to provide the latter to have any hope because pure XML is unusable as a programming language. XUL made some of that error in the template language and see my rant for how well that turned out... it isn't all the XML choice but it plays a big role.
The problems with the implementation as it now exists in Mozilla (circa 1.7) strongly echo my complaints about XUL templates: Failures of all kinds are silent. Trying to do something clever will randomly segfault the browser, again with no explanation.
You can't apply any testing technologies like JSUnit because the XBL is too deeply embedded and critical parts are out of your control, such as the rendering order. (Really, I tried, I did, but without semaphores in JS it can't be done, even with document.loadBindingDocument. You can create the XBL nodes, but I had an XBL widget that would not render synchronously for reasons I never could figure out, and as a result it was unavailable for testing, no matter what I did, because having the XBL widget rendered is a pre-requisite for testing its methods; see below.)
If I found it so much easier to use JS and the DOM instead of XBL, then why not go all the way?
In fact, it isn't even hard to take an XBL object and convert it to JS + DOM, and writing a base JS class to make this easy doesn't take long (mostly a matter of managing the bindings which is a little tricky, but not too bad). It takes even less time if you just download mine.
Second, you lose entity support, but it isn't too hard to create a lookup table, and if you like, you can create a more sophisticated system like Perl's Locale::MakeText, so this too can also be a big win under some circumstances.
(As I write this, I am looking into supporting XML fragments via the parsers that IE and Mozilla expose, and yet, almost immediately as I converted my existing XBL widgets over I was using features that didn't translate and made my system clean; since I've turned my code into an open source project I may just wait for someone who cares to add that feature; as I don't care I'm not sure I could do it right.)
In conclusion, even as I don't like the XBL implementation in Mozilla one bit, I like the idea well enough to re-implement it. Certainly it is stronger than XUL templates, in my opinion.