|Spartan Ajax - No more HTML!|
|Written by Mike James|
|Monday, 07 September 2009|
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!
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.
For more information on Spartan Ajax simply follow the links below and read the articles:
|Last Updated ( Friday, 14 May 2010 )|