Thursday, December 13th, 2007
Server-side Ajax Framework: IT Mill Toolkit 5, now with GWT
I’ve long been a proponent of server-side Ajax frameworks — frameworks that store state on the server and use an Ajax engine in the browser to drive the display. The advantages: state and control logic stay on the server, so security compromises that exploit client-side state and logic are more difficult to pull off; developers can work in one language and, for the most part, ignore the fact they are writing a web application. The disadvantages: the server retains a large amount of state, so scaling your application can be problematic.
There’s one other large disadvantage to these open source server-side frameworks: for every 100 Java developers who use the framework, there is only 1 of them that can do serious JavaScript development. That means that the lifeblood of these frameworks — the development of new and cool JavaScript widgets — is sluggish at best. That has certainly been the case with the best known 3 frameworks: Echo2, ZK and ThinWire (though ZK does wrap a number of Ajax widget libraries, such as Dojo).
Back when GWT was introduced, it struck me that this would be the perfect way to write the client-side engine, to let the other 99 Java developers join in. I had the good fortune of being seated next to Joonas Lehtinen, IT Mill’s CEO, at the GWT Conference in SF this past week and was blown away when he demo’d IT Mill Toolkit 5, his server-side Ajax framework (dual Apache 2.0 and commercial licenses) that, yep you guessed it, uses GWT for its client-side engine.
One important thing to consider is that IT Mill has extended the default GWT widgets so that they can be fully "rebranded" with CSS. They do provide an extensive reference manual that will guide you through developing your own custom components and integrating them with the server side.
I’d like to see the other server-side frameworks follow IT Mill’s lead in using GWT for the client side, but given the amount of effort that they have put into building their client-side engines, that may be a ways off.












About a year ago IT Mill was the first (and only) open source Ajax framework to go closed source, but I understand that they’re back in the open source space again. Is Backbase now the only company that is able to make decent money with a non-open source Ajax framework? Or is it a requirement for most projects to go open source to get adoption?
When we released IT Mill Toolkit 4 with commercial license, the reception was underwhelming even though it was the first RIA framework to support smartphones. We identified the problem to be that only few developers are interested in evaluating any other than open source frameworks. Now when we released IT Mill Toolkit 5 with really open Apache license (with no strings attached), the interest in commercial license and support has been a lot higher.
There are other serverside ajax frameworks, that takes that very idea much further, to be honest.
Mikael, can you tell me the name of those frameworks so I can take a peek?
Mikeal, I’m also intrested in these other “better” frameworks.
I said it took the idea further, I’m not prepared to say it’s better. :-)
Server- side frameworks with decouple-able presentation layer are what developers want to look at. one of the other “better framework” i believe is Visual WebGui. This framework is server based, providing the good of server side but offering on top, WinForms model development, very effcient bandwidth usage and chose your presentation layer. at the moment the developer can chose any standard browser or MS SilverLight. I had seen SilverLight POC, it is amazing, it flies like a jet. worth having a look as this is no doubt on of the better framework
@Mikael – now you’ve dropped two comments with nothing to back them up. Care to share?
The link is the name signing the comment.
As I mentioned, maybe it’s not better, but it’s one of those frameworks “that store state on the server and use an Ajax engine in the browser to drive the display”, which defaults that idea to the core.
In this case, it’s an xml runtime, and not java thought.