Mozilla Development

I may not technically have "a job", but if you saw me at home, you'd never realize I wasn't just working from home. I've been working with some former co-workers on a project that will hopefully become my next job.

For this project I've been developing in Mozilla. No, not "developing web applications", doing development in XUL, XBL, RDF, and a lot of other fun Mozilla-specific technologies.

Mozilla has a lot of astounding capabilities, as you can see in the book Creating Applications with Mozilla. Mozilla's "XUL" language can be thought of as an extension onto the HTML form elements, including things like menu elements or better layouts. CSS is used in conjunctions with this extension, and XBL allows you to package up various things you can create with the form elements and Javascript into a coherent single unit.

For instance, I have created a "monetary amount" entry field, which looks like a text field, but restricts the user so they can only enter a monetary amount. Only numbers and a handful of symbols are allowed, like "period" and "negative". For extra bonus points, I threw in the ability to do simple math inside of the widget. Widgets can inherit capabilities from other widgets, so, for instance, I've placed the functionality that pressing ESC in a widget resets it to the original value in a virtual "root widget", and all widgets in the system will inherit this functionality automatically.

It's extremely powerful; in fact, what you think of as "Mozilla" (or Firefox or Thunderbird or whatever) is actually just a "web page" built in XUL + XBL + CSS + RDF, with Javascript and compiled C++ code manipulating it. If it's powerful enough to implement a web browser in, it's powerful enough to do a lot of other things too, more so then straight HTML, and that's a good thing. Because of the number of ways the concerns are seperated, with XUL handing layout, XBL handing logic (with Javascript), CSS handling appearence, and RDF handling getting data into the system, it is a remarkably flexible system that very natually fits the "seperation of concerns" type of thinking that good developers learn to use.

That's the good part.

The bad news is that Mozilla has one of the worst cases of what I'm going to call "tightrope development" I've ever seen. Imagine you're 100 feet in the air, and you're trying to traverse a network of tightropes... in the dark. Fortunately, you have "infinite lives" in the video game sense, but still, figuring out how to get from here to there requires altogether too much trial and error.

For you see, Mozilla being open source and well-supported, it has very strong tightropes. It's been a long time since I've seen Mozilla crash. But the Mozilla app writers know the system inside out, so of course they know how to navigate the network. As soon as you step outside of the ropes that the Mozilla developers traverse, though, you inevitably get one of these results:

  1. A cryptic component error 0x8000[something] that makes no sense whatsoever, displayed on the Javascript console. (You do know what that is, right?)
  2. Silent failure; nothing crashes but nothing works, with no indication why.
  3. A hung Mozilla.
  4. A spontaenously crashed Mozilla.

Note the complete absence of things like "an informative error message" or "helpful diagnostics". Developing with Mozilla is unfortunately exactly like groping around in the dark; if you don't do it exactly as the Mozilla developers intended, if indeed they ever foresaw anyone doing what you are doing, you can expect to spend three or four hours trying to figure out how to spell your request such that Mozilla understands it correctly, without any useful help from Mozilla.

Now, almost every technology has that problem. There's a learning curve to grok how it works, and before you do you have a hard time using it. Generally, though, you get things like error messages that give you some sort of clue what you are doing wrong, hence the emphasis in the previous paragraph.

And it's not as if Mozilla isn't asking you to master at least four distinct technologies at once, meaning it's anyone's guess as to whether the problem lies in the CSS, XBL, RDF, or XUL if you're not an expert yet.

Mozilla developers: If you're wondering why people still aren't developing with Mozilla and insist on using things like GTK even when you (correctly) know Mozilla would be better, I'd say this is a major contribution to that. Unless you're a highly skilled and experienced developer who is also motivated to get it right somehow, you're going to try Mozilla. You're going to type in a sample application, and be wowed at how cool Mozilla works. Then you're going to try a small modification to the application to get it slightly closer to what you want. And then, you're going to give up on Mozilla when this slight modification causes the application to at best silently fail, or even crashes Mozilla, with no error messages. I know, because I only powered through this failure case this year because I'm motivated, and it was only marginally better then when I tried it around the 1.0 era of Mozilla, when I was defeated exactly this way.

Now, I'll grant you I'm using Mozilla 1.7b, and not a "debug build" and maybe there's more information in those. But I need to develop on the same version I'm going to deploy on, I need more information in this build that I can turn on. (And it sure seems to me that I've turned on that debug information, now that I've got a Debug and QA menu in the browser, though I could be wrong.) But this is more of a CYA paragraph, because if I'm "supposed" to be using a debug version, I am yet to find the place where I as a developer am informed of that.