Thoughts on software and life.

Monday April 25

Boxely, Part 1 of 3

Today AOL released a beta of the next version of AIM. This is probably not a big deal to most, but it is a big deal to me, because this AIM has now been re-written from scratch using Boxely, a GUI toolkit that I designed and implemented during my final year at AOL.

Boxely is an XML and Javascript based system for building desktop GUI applications, in the same family as Mozilla's XUL and Microsoft's upcoming Avalon. Just as XUL makes it really simple for people to write browser extensions for Firefox, Boxely makes it easy to write extensions for AIM. I don't know if Skype should be worried yet, but it seems AOL is interested in making AIM an attractive platform for all kinds of communication.

Boxely began its life in late 2002 when I came to the sad conclusion that "Mozilla, The Platform" was not what I wanted it to be. At the time, my friend Marlon and I had been working furiously for months to develop "Dante", an idea we had for a new desktop application. Naturally, I elected to build the first version as a Mozilla application using XUL. While I had loved XUL during the years that I used it to build Netscape/Mozilla products, I grew frustrated with it as I built Dante from the ground up, for a number of reasons:

  • Mozilla made Dante feel bloated before I wrote a single line of code. It added around 15MB to the disk footprint, 20MB to the memory footprint, and made startup time unnecessarily slow.
  • The XUL data binding model was (and still is) based on a clumsy RDF-based model. It requires you to write a ton of really unpleasant code to do very simple things.
  • Mozilla uses COM (err, XPCOM) heavily. If you've ever worked with COM, you know how arduous it makes even the simplest of object oriented tasks.
  • The XUL language was (and still is) missing a bunch of capabilities that I felt were necessary. I'll talk about what specific features I wanted in part 3 of this series.
  • Finally, Marlon had some very slick graphic designs on the drawing board, and Mozilla's visual style system just couldn't accomplish them. Particularly, it lacked alpha blended windows (which it now has, though I don't know how well it actually works).
  • As a seasoned Mozilla developer, I certainly had the ability to improve XUL, but I decided, in the great tradition of Netscape, to start over from scratch. Even if I had been able to fix some of my complaints about XUL, Mozilla would still be large and "COMtaminated". More importantly, since Mozilla intends to keep its XUL implementation backwards-compatible with Mozilla 1.0, I'd be pretty limited in how far I could change things.

    So, I spent a few months building a new lightweight, stand-alone XUL, named for the "box" objects at its core. It started out very similar to XUL, but evolved to be different in a lot of ways. Once Boxely was mature enough, I used it to re-write Dante. The Mozilla-based Dante had been a 10MB download that took about 25MB of RAM on startup. The Boxely-based Dante was a 1MB download that took about 8MB of RAM on startup, and was faster, nicer looking, and easier to develop.

    Over two years later, "Mozilla, The Platform" has improved quite a bit. If they can get rid of RDF templates, make the layout model more versatile, support more graphical features, and finish XUL Runner, I'd call it a contender. I have heard Mozilla talk about making "The Platform" more of a priority for the post-Firefox 1.0 world, so I'll keep my fingers crossed. The open source world really does need a cross-platform answer to Microsoft's XAML. It's not clear if AOL intends to make Boxely either cross-platform or open source.

    So, what is Boxely, anyway, and what does it mean to you, the GUI developer? In my next post I will look at how Boxely has changed since I left AOL, and in the final post I will show how Boxely compares to XUL.

    Posting your comment. Please Wait...