Stephen M. McKamey, 2006-11-11

JsonML - Building UI in Ajax

Over the last couple years, Ajax technologies have been the hottest topic. The primary gains we hear about Ajax are from its asynchronous communication. What we don't often hear about is the pain incurred in building a savvy UI around this communication mechanism.

There are essentially two out-of-the-box techniques for building UI programmatically in the browser. The first is to render the XHTML as one normally would on the server, push it down to the client and instantiate via the innerHTML property on the container DOM element. The second is to build the elements "by-hand" using the client DOM (Document Object Model) much as you would in a server-side control without a design surface. Neither of these options is ideal, and so a third option is proposed.

Good: XHTML via innerHTML

This option feels natural. We've been rendering HTML on the server and sending it down for over a decade. While this is supported on nearly every Ajax-savvy browser, it is technically non-standard. The primary issue with this option though is speed. Certain browsers in certain circumstances (especially appending data) take a serious performance hit when parsing the text passed to innerHTML. One advantage with this option is it can be stored as a string in the client so that the markup may be reused. Unfortunately it is hideous to look at with the double encoding of both XHTML and JavaScript. Finally, when adding the HTML, there is no way to filter or trigger any events during rendering for altering the output that was given. This means that what is sent needs to be the final output, or afterwards a script must search through the elements by id and tagName. When a client wants to update a portion of the page, the entire section must be sent down from the server. There isn't a nice way to "merge" a structure and its content.

Better: W3C Document Object Model

This is the "right way" to do it. It's standards-based, its fast, and we have complete control of the structure, so merging is possible. Unfortunately, it is a complete pain in the... Each element must be created, stored in a variable, each attribute must be set individually, and then it must be appended to its container element. Repeat for every element. While it is easy, it is tedious and quickly degrades to cut-n-paste errors because let's face it no one is typing this for every element. The repetition of all those DOM calls can add up quickly. The scripts can be quite bulky. And if the common methods and objects are stored in shorter temporary vars, the script can be difficult to read. Finally DOM calls can't be serialized and stored into script.

JavaScript Object Notation

A clever idea to come out of Ajax's communication problem is JSON (JavaScript Object Notation). JSON is a data-interchange format much like XML with a much smaller footprint. The other advantage of JSON besides size is that clever use of JavaScript eval() provides client-side decoding for virtually free. JSON encodes data in a structure which is the same syntax JavaScript uses for its literals.

Best: JSON Markup Language

Building upon this idea of compact structured data, here is a third representation of UI elments called "JsonML" (JSON Markup Language). The idea being that the UI is rendered into JsonML, sent across the wire and then a generic client script can deterministically build DOM elements from this structure. Look at the advantages:

  1. Standards compliant: JSON is 100% JavaScript, and the build script is 100% JavaScript and DOM.
  2. Faster: JsonML feels like DOM, because its made from DOM.
  3. Far less tedious than DOM.
  4. Lighter than DOM+JavaScript: A single build script is writen so all that is being transmitted/stored is JsonML which is far smaller than all the DOM calls.
  5. A JsonML structure is JSON and therefore may be embedded directly into JavaScript without additional encoding, which means repeat usage, easier to read and less bulky.
  6. Minimal effort needed to add events to the UI build script enabling merging other such processes.

As you can see we remove nearly all of the disadvantages of both approaches. With some careful designing of the syntax, the actual size of JsonML is nearly identical to the original XHTML, and in some circumstances smaller.

Next: Binding Behaviors to DOM Elements

For a detailed explaination of the syntax and an example build script, check out: http://jsonml.org