18th of February 2005 the world completely changed in regards to how we percieve both applications and the web, that was the date when Jesse James Garrett wrote his famous essay
Ajax: A New Approack to Web Applications. By writing that essay and giving Ajax its name Jesse James spiked what was to become later one of the largest and most significant revolutions in IT and System Development History. For 30 years we have been locked down in proprietary APIs owned by a single vendor, and this time locking someone "in" is virtually impossible due to the heavy emphasize on Open Standards and Open Web technology. Fact is I would vote the 18th of February 2005 as the "constitution date" for developers if I was asked. This was the date the beginning of freedom started for us and we could shake off the lock-in technologies, EEE and non-openness from 30 years of development in an API owned by "Huge Corporation Inc".
Image of Jesse James, the biggest cowboy in the "Wild Wild West"... ;)This post was spiked by a slider by
John Resig at
Ajaxian. Now I have enormous respect for John and the work he has done on
jQuery, though the first slide in the presentation at Ajaxian shows he has got it all wrong in regards to understanding
Managed Ajax which I will use as the term to refer to "no-JavaScript" Ajax Frameworks from now on.
Managed Ajax defined
Managed Ajax is a way to create Ajax Applications without having to write JavaScript at all. When everything hits the browser everything is JavaScript, HTML and CSS, but instead of writing JavaScript directly you write in *another* programming language code towards an API which in turn will "transform" into JavaScript somehow when being rendered back into the browser. Think of it like Java/Ruby/C# versus Assembly, C and C++. In Assembly, C and C++ you need to take care of your own memory and you need to do a lot of low fiddling, while in Java, Ruby and C# you get a garbage collector which takes care of the heap for you and you don't have to fiddle with the "small bytes". This concept makes Java, Ruby and C# "Managed Programming Languages".
Everybody knows that there are disadvantages to using Managed Programming languages compared to "low level" programming languages, most of them though comes from speed issues. Still most of us agree on that for many problems the benefits of using a Managed Programming Language far outweighs the disadvantages.
Managed Ajax is like that, there are several disadvantages in using it. Though for many problems the benefits far outweighs the disadvantages.
[Dis/]Advantages in Managed Ajax Frameworks
This all depends upon which Managed Ajax Framework you are using, there exists many Managed Ajax frameworks out there. I'll try to compile a far from complete list with some of the big players.
- GWT, "compiles" Java Bytecode to JavaScript
- Ext GWT, builds on top of GWT as far as I know
- Anthem.NET, uses Partial Rendering to update only portions of the webpage
- ASP.NET AJAX, Microsofts Ajax Framework, uses some concepts from Anthem.NET. Some parts of the Framework are "Managed" and uses Partial Rendering to abstract away JavaScript (UpdatePanels)
- Gaia Ajax Widgets, uses a JavaScript API for setting properties on the client-side from the server-side .Net code.
In addition to those also the Ajax library I am working on -
Ra-Ajax is a "Managed" Ajax Framework.
The disadvantages in using Managed Ajax depends highly upon which Managed Ajax framework you are using, but mostly it can be closely coupled with the disadvantages of using a Managed Programming Langague. Speed and responsiveness. Often you can create a more responsive and faster application using "un-managed" Ajax Frameworks like
MooTools,
Prototype.js,
jQuery or
Dojo, but you will spend longer time, and the "can" part is crucial since due to the complexity in rolling your own JavaScript adds up and "leaks", you will often end up with less responsiveness and less flexibility. This is especially true for developers who haven't done a lot of JavaScript development from before and are not "Rock Star JavaScript Developers".
This is nothing new though, the same "leaks" exists in Assembly, C and C++ programming languages. Unless you are very skilled in those programming langagues you will end up with *slower* solutions than if you used a Managed Programming Language. Very few developers can in fact outperform the StringBuilder or String classes from Java and C# in C++, C or Assembly.
However, this has nothing to do with flexibility, "configuration" or "drop in components". You still have the same flexibility in most Managed Ajax Frameworks as you do have in JavaScript Frameworks. If for nothing else than the fact that you can "mix-in" un-managed Ajax in most of these Frameworks as you wish and use "Managed Ajax" for the most parts in your application and if/when stuck resort to "un-managed" Ajax to do the small bits when needed. Also in Ra-Ajax we are rendering Controls mostly on a "one-to-one" relationship with DOM/HTML elements. Like for instance our
Ajax TextArea control. The TextArea control is actually just a wrapper around the
<textarea HTML element, though instead of having to add up the blur, focus, changed etc events on the client and change the style attribute, css attribute or any other attributes on the client - this is being done on the server in a Managed Environment in *another* programming language.
This makes it possible for you to write your entire application in one programming language and for the most parts don't even bother about what the XMLHTTPRequest is, or at least you don't have to manually create one yourself since if you have defined the blur event on the server, then the Managed Ajax Framework will take care of creating an XHR request for you and do all the mappings towards your user code. It's about *simplicity* and not "lack of flexibility". Most things you can do in JavaScript Ajax Frameworks are just as easy to do in Managed Ajax Frameworks...
The same way most things possible to achieve in C, C++ and Assembly programming languages is just as easy (easier in fact) to achieve in Java, C# and Ruby.
My bet is that the current state of Ajax is roughly as the current state of development in general was 30 years ago when we were all developing in Assembly and C, JavaScript development feels inevitable, but it is not the future. And as time goes by fewer and fewer will choose to develop in "Assembly" Programming Languages and more of us will resort to "Managed Ajax". And in that process we will become far more productive and have far less Time2Market for our Ajax Applications...
Have a nice day in Wild Wild West where Jesse James is lurking in the shadows. ;)Thomas