Boxely, pt 2

Updated: Corey, who actually works on Boxely at AOL, had a few thoughts about my Boxely ramblings. He speaks from a point of some authority, being one of the people who turned it from science project into core application infrastructure. Not that I agree with all his points (in particular, I think CSS is junk - but I said that already :)), but its worth a read, filling in a number of gaps in my discussion below.

Boxely is the UI toolkit that serves as one of the pillars of the OCP.

The basic execution model is a markup-based/script-behind one - very similar to XAML or MXML. When I say "script behind", I mean that the code is not inline as it usually is with HTML - its in a separate "code" file. The underlying protocol/data model utilizes a discovery/reflection/dynamic binding model provided by the EE (Execution Environment of the OCP), which I'll discuss in some more depth at a future date.

In this post, I wanted to discuss the UI model we use, briefly, and then discuss some of the benefits and drawbacks. Understand, by way of context, there were two goals for Boxely: (1) Make it faster for AOL and partners to iteratively build, maintain, and integrate features with AOL desktop applications, and (2) Enable richer, more modern, user interface experiences.

I'm not going to delve too deeply into Boxely samples or markup - this isn't going to be a how-to-use Boxely primer. At some point (soon-ish), I hope to just make the Boxely documentation and samples available online.

Unsurprisingly (given its name), everything in Boxely is based on the idea of a "box" - more or less the very same w3c box element that formalized and codified the grammars of HTML/XHTML layout elements for browsers. And it follows directly that Boxely's layout model is primarily a flex/flow model, much like HTML/XUL/XAML/MXML, etc.

It was an intentional design goal to try and keep the Boxely language as syntactically and grammatically consistent with w3c standards as much as we could, except where(a) standards were non-existent and/or underspecified (extensions), or (b) where strictly adhering to the model caused unnecessary complexity in the authoring process (revisions).

We tried to keep most things, early on, in the "a" category, leveraging CSS, namespaces, etc., where appropriate, with only a few things in the "b" category. Obviously, we extended the range of the addressable element space to include desktop concepts like windows, taskbar entries, icons, etc. We addded a "nine-grid" image brush style to make stretchable UI bits easier, and it is possible, in Boxely, to explicity change the z-order and/or the flow-order of a box independent of its location in the DOM.

Now, if you're not too familiar with (at least) HTML - and by that I mean you haven't built anything at any scale - you're probably going to be a little lost on the values driving some of our design choices.

In any case, the primary nuanced evolution in the second/third generation of mark-up languages beyond HTML is of self construction. There are a few very basic box types (fill, text, image, etc.) that can be combined and nested (i.e. boxes within boxes) with some basic layouts and behaviours to make all kinds of applications and content - this is one of the basic principles of HTML to begin with. Where Boxely (et al.) go further is that they then allow you to formally construct new markup elements out of some attributable collection of markup elements - essentially markup "functions" - that you can then reuse as first class markup tags within your UI source files.

And, of course, these can be nested - you can combine these gadgets, as we call them in Boxely, to make even more complicated gadgets. It is a pain to do that well (quality, speed, flexbility, and maintainability) in something like HTML.

Initially, we had this idea that the "class library" gadgets in Boxely (the ones we provided for all common UI elements) would have their own internal spacing rules to make layour easier. So, for example, a button gadget (that you might have constructed out of a text box inside a fill box - with a rounded corner, naturally) might have a padding of 3 pixels on either side. That way, it is always consistently spaced from other elements and gadgets you place around it.

Seems like the right way to go, but this was a surprisingly wrong-headed idea.

It turns out that in real word applications, the spacing between elements is more likely a function of the container than the element. And so, we added "hspace" and "vspace" parameters to our layout that you can specify on the container box that specifies how far apart its children are.

Most of the details of the differences aren't that critical for my point, and I hilited that one only to say this: there's a gap between the requirements of commercial applications (especially on the desktop) and content (in the technology sense) and most of our choices were about closing gaps between theory and execution. Basically, we weighed creating an "exception" against "does it make performance or authoring creation/maintenance significantly easier?"

So, some things I like about Boxely:
- Syntactic and grammatic familiarity of markup and script (XUL-ish and Javascript, respectively). We've brought up a number of teams very quickly, both internally and externally.
- Performance: its smaller, faster, and more flexible than Flash/MXL or XAML.
- Differentiation: we're able to create uniquely AOL applications. More on the good v. bad of that in the future - but I'll state that for our (AOL) purposes it's a big plus.
- Separable, layered development: That self construction I was talking about makes it MUCH easier for our applicaitons teams, designers, and product people to spend time worrying about the right set of problems. Now, they don't always LIKE that we can seggregate our development this way, but that's a different issue...

Some things I don't:
- Performance: a box is 144 bytes (it was a LOT bigger when we first started - so its improving), and we make a lot of boxes; and though Boxely is faster than the comparables, its still quite a bit slower than straight Win32 applications.
- Javascript: Some major dichotomies here - its a powerful but extraordinarily goofy language that everyone only thinks they understand. I'll delve into this in some depth in the future, but suffice it to say that its ease of use (but lack of GOOD scalability) is exactly the problem. Too much of our applications are built in script because it was easy (not too be confused with right) to do so. The nice thing about the OCP (the EE really) is that it lets us easily choose how we implement services and applications (its basically language agnostic) - but too much ended up in script. Some of this is not Javascript's fault per se - its just that the tradespace of scripting languages is quite different from that of compiled code, and not always readily understood - an opacity problem. As I said, more on this soon - its too big to tackle here.
- Layout: Flow and flex I like for some special cases, but they're really not a great fit, in my view, for most real world applications. I think this lately pervasive thinking is directly a "If you only have a hammer, everything's a nail" outgrowth from HTML's impact on the world of front-end application development.
- CSS: I think its pure crap. In my view, its an ivory tower computer science solution for style specification that's been inflicted on the world in the name of "standardization". Its complicated, NOT very powerful (why can't I address attributes?), and forces awful implementation tradeoffs.

Most of the minuses I don't think are fatal in anyway, over time (because we make them better or because they become less significant), but they did provide a newly discovered set of challenges in getting our first generation of applications shipped.

OK, next I'll dive into scripting and languages more directly, probably expanding this discussion into a look at the EE itself.