Ajax Approaches Abound: Which One Is Right For You?
by Dion Hinchcliffe
Sunday, 4 June 2006
http://web2.wsj2.com/
I’m [Dion Hinchcliffe] in New York City getting ready for the Real-World Ajax seminar tomorrow morning for a talk I'll be giving on Ajax design elements. I've been thinking a lot lately about the various approaches to developing Ajax software and trying to construct an intellectual framework for evaluating them. Clearly, a large amount of online software in the future, both SaaS and Web 2.0 (and yes, there's a difference) will be developed using Ajax. And figuring out which direction to take for now is actually getting harder right now, not easier.
That's because options for creating Ajax software are still growing rapidly and run the gamut from incredibly powerful platforms such as Microsoft's Atlas, to declarative specification appraoches such as those used by Backbase and Laszlo. On the micro-Ajax side , there's the lightweight, mostly blendable frameworks and widget bundles such as Dojo and Script.aculo.us. Then there are the translation approaches that let you create Ajax software in a more traditional programming language, which tend to have more robust tools for development, testing, and debugging. Google's GWT and Morfik are two such examples of the latter.
All of these approaches and tools have their various merits and a few drawbacks as well. With the advent of the term still not much more than a year old, industry interest and use of Ajax is surprisingly widespread (witness the virtual onslaught of books, development tools, actual Ajax software, conferences, and more). Yet we're really still in the tail end of the pioneer stages with Ajax. And we know that pioneers tend to be the ones with the "arrows" sticking out of them. This means buying down development risk is key while the next generation of Ajax best practices and techniques are identified and commonly understood.
Then there's the issue that browsers just aren't as capable computing platforms as formal operating systems. This gives us the important constraint the creating great Ajax software still requires above average architecture, design, and development skills. As I've written before, Ajax isn't for Web designers (yet), and requires some assistance from a server development team as well to build (or increasingly, find) usable Web services that will do what's needed.
When I talk to folks about the basic elements of Ajax and try to convey a sense of the common techniques to apply it effectively and build great software with it, I also try to explain that a little real engineering is required if one paints outside the lines of a growing number of Ajax application blueprints. Fortunately, we are starting to see products and approaches that are reducing the need to build an Ajax application by madly cobbling together a bunch of frameworks and code snippets found out on the Web.
So, stubbing your toe with Ajax is still common. It's very easy to do something that makes total sense in the browser but brings the server to its knees unexpectedly for example. Furthermore, Ajax applications tend to have more moving parts and dependencies, making maintenance and management a bigger issue that it ever was with HTML-based applications (which aren't going away any time soon either.) Having to be a good Web (or intranet) citizen is something that doesn't happen overnight, but through experience. Ultimately, this means that there will probably be an short-term increase in the failures of Ajax projects as less experienced Web developer shops begin take it seriously and try to do bigger and more complex applications.
Fortunately, for the long-term, there seems to be a great deal of investment in Ajax development techniques and supporting tools for development, design, testing, debugging, maintenance, and management. Soon Ajax will become just another capable client software technique in the developer's toolbox, albeit one that's special because it represents the first true Web-only software platform.
Sunday, 4 June 2006
http://web2.wsj2.com/
I’m [Dion Hinchcliffe] in New York City getting ready for the Real-World Ajax seminar tomorrow morning for a talk I'll be giving on Ajax design elements. I've been thinking a lot lately about the various approaches to developing Ajax software and trying to construct an intellectual framework for evaluating them. Clearly, a large amount of online software in the future, both SaaS and Web 2.0 (and yes, there's a difference) will be developed using Ajax. And figuring out which direction to take for now is actually getting harder right now, not easier.
That's because options for creating Ajax software are still growing rapidly and run the gamut from incredibly powerful platforms such as Microsoft's Atlas, to declarative specification appraoches such as those used by Backbase and Laszlo. On the micro-Ajax side , there's the lightweight, mostly blendable frameworks and widget bundles such as Dojo and Script.aculo.us. Then there are the translation approaches that let you create Ajax software in a more traditional programming language, which tend to have more robust tools for development, testing, and debugging. Google's GWT and Morfik are two such examples of the latter.
All of these approaches and tools have their various merits and a few drawbacks as well. With the advent of the term still not much more than a year old, industry interest and use of Ajax is surprisingly widespread (witness the virtual onslaught of books, development tools, actual Ajax software, conferences, and more). Yet we're really still in the tail end of the pioneer stages with Ajax. And we know that pioneers tend to be the ones with the "arrows" sticking out of them. This means buying down development risk is key while the next generation of Ajax best practices and techniques are identified and commonly understood.
Then there's the issue that browsers just aren't as capable computing platforms as formal operating systems. This gives us the important constraint the creating great Ajax software still requires above average architecture, design, and development skills. As I've written before, Ajax isn't for Web designers (yet), and requires some assistance from a server development team as well to build (or increasingly, find) usable Web services that will do what's needed.
When I talk to folks about the basic elements of Ajax and try to convey a sense of the common techniques to apply it effectively and build great software with it, I also try to explain that a little real engineering is required if one paints outside the lines of a growing number of Ajax application blueprints. Fortunately, we are starting to see products and approaches that are reducing the need to build an Ajax application by madly cobbling together a bunch of frameworks and code snippets found out on the Web.
So, stubbing your toe with Ajax is still common. It's very easy to do something that makes total sense in the browser but brings the server to its knees unexpectedly for example. Furthermore, Ajax applications tend to have more moving parts and dependencies, making maintenance and management a bigger issue that it ever was with HTML-based applications (which aren't going away any time soon either.) Having to be a good Web (or intranet) citizen is something that doesn't happen overnight, but through experience. Ultimately, this means that there will probably be an short-term increase in the failures of Ajax projects as less experienced Web developer shops begin take it seriously and try to do bigger and more complex applications.
Fortunately, for the long-term, there seems to be a great deal of investment in Ajax development techniques and supporting tools for development, design, testing, debugging, maintenance, and management. Soon Ajax will become just another capable client software technique in the developer's toolbox, albeit one that's special because it represents the first true Web-only software platform.
Comments