The idea of Spartan Ajax is very simple - do away with HTML!

Sounds crazy but it isn't. Recently we have been misled by the theory and practice of the "markup" language. It is all well and good when markup languages are being used to create layouts and I've nothing against SGML, XML or HTML when they are being used to mark up content for presentation or data for processing. The problems begin when markup languages make their way into programming environments.

Markup is declarative - it states how things are - but programming languages are (mostly) procedural and say how things should happen and the two don't mix well. When the web was new HTML was used for pure markup but as web pages changed from declarative to procedural we needed a way to work with HTML "objects" from code.

At first, and still far too often today, the scripting languages were scattered through the HTML as inline code, with the result that the whole thing was a mess and difficult to maintain. To solve this problem "code behind" was invented so that we could separate declarative markup from procedural code. The idea was that a web page that "did something" had HTML in one file that controlled what the page looked like and code in a file "behind" it to make it do something.

However code behind introduces another problem that is arguably worse than the one it solves. The separation of concerns brings with it a need to join the two naturally separate name spaces. In other words, how does the code know what the HTML objects are called and if necessary how does the HTML know what the code objects are called? And when you come to try and maintain it where is any given object defined - in the code or in the markup? It doesn't take long for the name problem to become as big a mess as mixed code and markup.

For some unknown reason the whole idea of using markup either mixed with inline code or with code behind caught on and made its way into mainstream languages. For example, we have XAML and the .NET languages and MXML and Actionscript in Flash to name but two examples. The whole approach is crazy but it is often justified with the claim that it allows a designer to work on the look and a programmer to work on the action. If you think about this for a moment you will realise that you don't need a markup language to make this possible and in fact designers never sees the markup language because they use a drag-and-drop app like Expression Blend or Flash CS4. Most designers don't care that their designs are coded in XAML or whatever, they just use the package provided and it generates the code. There really is no reason why Expression Blend or any Designer shouldn’t generate code in the same language used to create the code. Why invent two languages when one is more than enough?

Thinking about markup languages in a slightly different way provides some additional insight. You can consider XAML or MXML to be object instantiation and initialisation languages. It is after all what they do. You write a XAML or MXML tag and this is used to instantiate and initialise an object for the code to work with. For example, XAML is processed to create .NET objects which are then made available to C#. Why not generate C# and do the job all in the same language and "name space"? The only reason for inventing XAML is so that the guys at Microsoft only have to write a designer that outputs a single language, i.e XAML, rather than one for each of the .NET languages. There is no great advantage for the programmer or the designer in introducing yet another language!

Now let us take this a stage further. HTML can be viewed as an object instantiation language like XAML. Its entire role in life is to instantiate and initialise objects that are added to the DOM. Seen in this way it is clear that it too is just as dispensable. This is the central idea of Spartan Ajax - don't use HTML, just use a client side language, e.g. JavaScript, to do the entire job. No more HTML, no more code behind - just code in front. It’s a simple idea and easy to use.

All you have to do is write nothing but JavaScript that creates and works with DOM objects. You can easily take a completely object-oriented approach and build web applications that are extensible and easy to maintain. Many of the techniques needed for Spartan Ajax are standard in libraries such as JQuery or Dojo but these simply haven't taken the next and obvious step of getting rid of the HTML and writing nothing but script. Some well known web applications, such as Google earth, are already using JavaScript UI components and are examples of Spartan Ajax - but perhaps not as extreme as they could be.

What about UI design? If the UI is created by 100% JavaScript how can we hand this over to a designer? The solution is the same as it has always been - create a drag-and-drop designer that outputs JavaScript. The simplicity of one language and only one way of creating objects is too good to ignore.

The more you think about it the more it makes sense to forget the whole crazy idea of separating the object instantiation and initialisation out in a declarative language. To see how crazy it is just look at the way that procedural facilities are embedded within XAML, say, making it even more obvious that the separation is artificial. Forget markup languages for code, forget HTML, forget code behind and work with nothing but code in front.

Try out Spartan Ajax for real with JavaScript Pong, a modern implementation of a classic game or have a look at Building JavaScript controls to see how things could be done and at Getting started wth Bing Maps (Virtual Earth) to see how JavaScript controls have been used in a large system.

For more information on Spartan Ajax simply follow the links below and read the articles:

Nothing but JavaScript

Spawn of the Devil?

<ASIN:0596517742>

<ASIN:1590597273>

<ASIN:1933988355>