For nine months in 2004, I was heavily involved in Mozilla-specific development. There's hardly a technology in Mozilla I hadn't tried to use, except writing my own XPCOM component. This is a report on the overwhelming and consistent failure of Mozilla to deliver on its promises.
It started with the XUL Templates rant, which is still the strongest condemnation of the sub-essays that comprise this collection. However, it grew as every Mozilla tech I tried to use, without fail, followed the following pattern:
- See tech, sounds cool.
- Copy sample code, hey, it works!
- Try to modify sample code. Oops, it broke. Oops, there's almost no way to figure out what broke. Push past this and eventually get the tech to do something useful.
- Try to make the tech do something not just useful, but really useful. Watch as Mozilla seg faults. Figure out how to work around the seg faults after several days.
- Discover the really useful thing I want to do really isn't possible, convert back to standards-compliant HTML and Javascript.
Why?
Why does Mozilla fare so poorly if you actually try to use it in an advanced manner? I don't think that it is incompetance or a conspiracy; the most plausible and simplest explanation is that it is simply an effect of how the code is used.
Software systems, and the programs and code that make them up, that are still evolving act like the muscles in your body. Constantly used muscles become stronger; constantly used aspects of the code are maintained better and become more capable and better optimized. Unused muscles atrophy; unused code and capabilities either never really gets well implemented, or gradually decays over time unless someone makes an effort to use them. (From this point of view, "unit testing" is an "exercise regimen" that you always run your code through to make sure it hasn't suffered an injury.)
While Mozilla uses XUL, RDF, XBL, XPCOM, every time you start the program up, it only uses a subset of the capabilities of the technologies. XUL templates seem to only get used for internal RDF sources, and mostly with the tree element, and some of the otherwise mind-boggling limitations of XUL templates make sense no other way. XBL is used primarily to implement the browser interface, and while that is a serious usage that does exercise many aspects of the XBL technology, browser interface is rather simple compared to what I was trying to do with XBL, dynamically pulling in data in multiple parts and creating XBL elements that do a lot of work before even being displayed.
Those who would reply that XUL & XBL etc. are working for them are simply using the "correct subset"; the flaws are so fundamental and pervasive they can't possibly be my imagination. You, too, will hit them if you try to get too advanced or useful.
The other natural counter is to point out that other projects have been built on top of Mozilla. My reply is to observe that in theory, if you're willing to hack on Mozilla's source code, anything is possible. In fact, all such projects I know are huge by normal open source, or indeed commercial, standards; at least one of the ones that leaps to mind (nvu) is basically a full fork of Mozilla. That does nothing for the rest of us... nor does it show that such projects are doing things correctly! One of the problems of having excessive resources is that you can sometimes bull your way through a problem best avoided. I'm sure with time, effort, and the hiring of or becoming a Mozilla C++-level guru or three, I could have done everything that I wanted to do in Mozilla. However, given the constructive demonstration of a superior path that worked in much, much less time (both calander and person-hours), why would I want to do that? I'm not saying the way I constructed XBLinJS is the only way, I'm saying it's the best way, both in the short and the long term.
