Is AJAX worth adopting?
AJAX is everywhere. In a remarkably short time, AJAX has become the most talked about topic in Java circles.
** Be part of the Best Java Blogger 2 Contest (May 2005) **
Why is AJAX so hot? Google deserves the credit for that. Google has kept surprising users with amazing user interfaces on Gmail, Maps, Suggest and what not. We saw GMail, we said “Wow this GMail interface is awesome!”, assumed that the Google guys had worked very hard on their Javascript and forgot about it. We knew there was some bigger explanation to it, but we didn’t care.
However once this Google approach got a name and a following, it could not be ignored. It now became something that every techie had to atleast be aware of.
I am no exception and so I spent some time trying to understood AJAX, and I already am having visions of me struggling to make my AJAX based applications work on 10s of browsers. Google is Google. it can spend the time and money required to make each application run on 10s of browsers, irrespective of how complex the Javascript is. However can you / your companyÂ
Outdated Article already.
I was curious as to how Backbase was able too meet their claim that they are ‘Cross-browser’ so I decided to take a peek at the technology. My conclusion is that Backbase is basically a just a hack that generates javascript a custom tag language. To get a feel for just how fragile this ‘platform’ is, one only needs to peek at the browser identification logic in the back ase code, here’s a taste:
function L(){
var Fd=navigator;
var Fe=Fd.appVersion;
var Ff=Fd.userAgent.toLowerCase();
this.DOM=(document.getElementById&&document.createElement);
this.navigator=navigator;
this.appVersion=Fd.appVersion;
this.userAgent=Fd.userAgent.toLowerCase();
this.ie=(Ff.indexOf(‘msie’)!=-1)?true:false;
this.ie4=(document.all&&!document.getElementById)?true:false;
this.ie4up=(document.all)?true:false;
this.ie5=(Ff.indexOf(‘msie 5.0’)!=-1)?true:false;
this.ie55=(Ff.indexOf(‘msie 5.5’)!=-1)?true:false;
this.ie6=(Ff.indexOf(‘msie 6.0’)!=-1)?true:false;
this.ns=(Fd.appName.indexOf(‘Netscape’)!=-1)?true:false;
this.ns4=(this.ns&&Fe.indexOf(‘4.’)!=-1)?true:false;
this.ns6=(this.ns&&document.getElementById)?true:false;
this.ns60=(this.ns6&&navigator.userAgent.indexOf(‘6.0’)!=-1)?true:false;
this.ns61=(this.ns6&&navigator.userAgent.indexOf(‘6.1’)!=-1)?true:false;
this.ns7=(this.ns6&&navigator.userAgent.indexOf(‘7’)!=-1)?true:false;
this.moz=(Ff.indexOf(‘mozilla’)!=-1&&Ff.indexOf(‘gecko’)!=-1&&Ff.indexOf(‘netscape6’)==-1)?true:false;
this.opera=(Ff.indexOf(‘opera’)!=-1)?true:false;
this.mac=(Fd.platform.toLowerCase().indexOf(‘mac’)!=-1)?true:false;
this.mac=false;
this.xwin=(Fe.indexOf(‘X11’)>0)?true:false;
this.compatible=this.DOM&&!(this.mac&&this.ie);
this.compatible=true;
return this;
}
Also, took a look at the online code sample at Backbase, and unless I’m missing something, the language makes use of XPath in an ass-backwards and fragile way… that is it is used to set values within the HTML presentation tags. The results is that one change to the presentation structure and all the XPaths break. XPath was intended to be used with validated XML structures, not unstructured HTML. This seems to me a very bad idea that will create a whole new generation of problems for developers. In fact, I get the feeling that the folks at Backbase are more intent on hiding the messiness and platform issues inherent in AJAX than actually solving any problems for developers or creating a development environment that makes any sense.
I was curious as to how Backbase was able too meet their claim that they are ‘Cross-browser’ so I decided to take a peek at the technology. My conclusion is that Backbase is basically a just a hack that generates javascript a custom tag language. To get a feel for just how fragile this ‘platform’ is, one only needs to peek at the browser identification logic in the back ase code, here’s a taste:
function L(){
var Fd=navigator;
var Fe=Fd.appVersion;
var Ff=Fd.userAgent.toLowerCase();
this.DOM=(document.getElementById&&document.createElement);
this.navigator=navigator;
this.appVersion=Fd.appVersion;
this.userAgent=Fd.userAgent.toLowerCase();
this.ie=(Ff.indexOf(‘msie’)!=-1)?true:false;
this.ie4=(document.all&&!document.getElementById)?true:false;
this.ie4up=(document.all)?true:false;
this.ie5=(Ff.indexOf(‘msie 5.0’)!=-1)?true:false;
this.ie55=(Ff.indexOf(‘msie 5.5’)!=-1)?true:false;
this.ie6=(Ff.indexOf(‘msie 6.0’)!=-1)?true:false;
this.ns=(Fd.appName.indexOf(‘Netscape’)!=-1)?true:false;
this.ns4=(this.ns&&Fe.indexOf(‘4.’)!=-1)?true:false;
this.ns6=(this.ns&&document.getElementById)?true:false;
this.ns60=(this.ns6&&navigator.userAgent.indexOf(‘6.0’)!=-1)?true:false;
this.ns61=(this.ns6&&navigator.userAgent.indexOf(‘6.1’)!=-1)?true:false;
this.ns7=(this.ns6&&navigator.userAgent.indexOf(‘7’)!=-1)?true:false;
this.moz=(Ff.indexOf(‘mozilla’)!=-1&&Ff.indexOf(‘gecko’)!=-1&&Ff.indexOf(‘netscape6’)==-1)?true:false;
this.opera=(Ff.indexOf(‘opera’)!=-1)?true:false;
this.mac=(Fd.platform.toLowerCase().indexOf(‘mac’)!=-1)?true:false;
this.mac=false;
this.xwin=(Fe.indexOf(‘X11’)>0)?true:false;
this.compatible=this.DOM&&!(this.mac&&this.ie);
this.compatible=true;
return this;
}
Also, took a look at the online code sample at Backbase, and unless I’m missing something, the language makes use of XPath in an ass-backwards and fragile way… that is it is used to set values within the HTML presentation tags. The results is that one change to the presentation structure and all the XPaths break. XPath was intended to be used with validated XML structures, not unstructured HTML. This seems to me a very bad idea that will create a whole new generation of problems for developers. In fact, I get the feeling that the folks at Backbase are more intent on hiding the messiness and platform issues inherent in AJAX than actually solving any problems for developers or creating a development environment that makes any sense.
Only a version ago Opera couldnt use AJAX ~ no XMLHTTP support. Then there are theolder versions of all the other browsers, and the text-only browsers – all of which have varying support, if any at all for javascript and XMLHTTP … I design for standards-compliance, usability and simplicity (for maintainance, readiblity, etc) – AJAX provide lots of wonderful things, but not on a wide enough scale. You cannot always design for the lowest-common denominator (like me), but what has really shitted me since I ever started using the internet back in the early 90’s was the ‘only supports IE’, ‘only supports Netscape’, ‘view in 1024×768+’, etc etc ~ dont get me started on flash sites and their awful precursors – sites made entirely in imagemaps.
*bitchmoan
~ MaryMary
Only a version ago Opera couldnt use AJAX ~ no XMLHTTP support. Then there are theolder versions of all the other browsers, and the text-only browsers – all of which have varying support, if any at all for javascript and XMLHTTP … I design for standards-compliance, usability and simplicity (for maintainance, readiblity, etc) – AJAX provide lots of wonderful things, but not on a wide enough scale. You cannot always design for the lowest-common denominator (like me), but what has really shitted me since I ever started using the internet back in the early 90’s was the ‘only supports IE’, ‘only supports Netscape’, ‘view in 1024×768+’, etc etc ~ dont get me started on flash sites and their awful precursors – sites made entirely in imagemaps.
*bitchmoan
~ MaryMary
Backbase, a company specializing in rich internet applications, has published a whitepaper entitled ‘AJAX and Beyond’ to explain the Backbase Presentation Client, designed to interact with their Presentation Server.
They also have a Backbase Development Environment for Java and .NET. All of the products are expected to be available around the end of May 2005, with a current download being available in their developer section.
BPC leverages many of the more recent W3C standards as well as AJAX and a custom UI declaration language called BXML (Backbase eXtensible Markup Language) to create highly interactive web sites. There are a number of demos available that show Backbase Presentation Client in action.
The Backbase RIA solution has the following differentiators:
# Full commitment to web and internet standards (XHML, CSS, JS)
# Cross-browser and cross-OS compatible.
# No proprietary plug-ins or runtime virtual machines required
# Layout and look-and-feel can be fully tailored to your wishes
# Fast to learn: developers can reuse existing web (HTML) development skills
http://www.backbase.com
Backbase, a company specializing in rich internet applications, has published a whitepaper entitled ‘AJAX and Beyond’ to explain the Backbase Presentation Client, designed to interact with their Presentation Server.
They also have a Backbase Development Environment for Java and .NET. All of the products are expected to be available around the end of May 2005, with a current download being available in their developer section.
BPC leverages many of the more recent W3C standards as well as AJAX and a custom UI declaration language called BXML (Backbase eXtensible Markup Language) to create highly interactive web sites. There are a number of demos available that show Backbase Presentation Client in action.
The Backbase RIA solution has the following differentiators:
# Full commitment to web and internet standards (XHML, CSS, JS)
# Cross-browser and cross-OS compatible.
# No proprietary plug-ins or runtime virtual machines required
# Layout and look-and-feel can be fully tailored to your wishes
# Fast to learn: developers can reuse existing web (HTML) development skills
http://www.backbase.com
AJAX is nice, and using the Google tools is much improved to older HTML only interfaces. However, as noted in this article, the difficulty with writing AJAX that works across a broad range of browsers is not something to be underestimated.
That very issue piqued my interest in alternatives, and of those I’ve looked at, I really like [URL=http://www.openlaszlo.com]Laszlo[/URL]. Open source, very broad browser support with a consistent language and a truly rich user interface experience (take a look at the demos, and the Amazon demo in particular — drag and drop to the shopping cart, sliding panes; attractive and responsive).
It’s unlikely that AJAX, Laszlo or other currently available technologies will be the end-all solution, but I for one am very interested and excited about the capabilities that these technologies are enabling for user centric, web deployed applications.
AJAX is nice, and using the Google tools is much improved to older HTML only interfaces. However, as noted in this article, the difficulty with writing AJAX that works across a broad range of browsers is not something to be underestimated.
That very issue piqued my interest in alternatives, and of those I’ve looked at, I really like [URL=http://www.openlaszlo.com]Laszlo[/URL]. Open source, very broad browser support with a consistent language and a truly rich user interface experience (take a look at the demos, and the Amazon demo in particular — drag and drop to the shopping cart, sliding panes; attractive and responsive).
It’s unlikely that AJAX, Laszlo or other currently available technologies will be the end-all solution, but I for one am very interested and excited about the capabilities that these technologies are enabling for user centric, web deployed applications.
Agree. Sure Google interface work/look great, but how much works has gone into them? While web interfaces can be pushed to be very interactive they will never match desktop apps. Companies are too quick to adopt web interfaces because they seem simple to develop and use. In fact, as UI becomes more complex, they become more difficult to both develop and use.
Here is a simple little example. User changes default list size from 20 items to 1000 items. Fine. Then user pops up a list with 1000 items. Still fine. Next he clicks the checkbox that select all items. Of course, it is a JavaScript … you know what I mean. Well the PC is now frozen for about a minute running JavaScript that is selecting 1000 checkboxes?!?!?! I haven’t seen the code, not sure how efficient it is or not. The point is that it doesn’t scale very well.
AJAX is fine so long as you put proper thought, design and resources into it. Otherwise you’ll end up with a very buggy interface.
Agree. Sure Google interface work/look great, but how much works has gone into them? While web interfaces can be pushed to be very interactive they will never match desktop apps. Companies are too quick to adopt web interfaces because they seem simple to develop and use. In fact, as UI becomes more complex, they become more difficult to both develop and use.
Here is a simple little example. User changes default list size from 20 items to 1000 items. Fine. Then user pops up a list with 1000 items. Still fine. Next he clicks the checkbox that select all items. Of course, it is a JavaScript … you know what I mean. Well the PC is now frozen for about a minute running JavaScript that is selecting 1000 checkboxes?!?!?! I haven’t seen the code, not sure how efficient it is or not. The point is that it doesn’t scale very well.
AJAX is fine so long as you put proper thought, design and resources into it. Otherwise you’ll end up with a very buggy interface.
Wether or not you use AJAX really depends upon the type of application you are building.
You could have a simple data entry form, where simple client side validations would suffice, and on the other end of the spectrum you could have an interactive chart, which would allow you to drill down and see details.
Refreshing or changing pages during such a drill down investigation would really be annoying to an user. If I can use AJAX here pull data asynchronously, this surely would lead to better usability!
Wether or not you use AJAX really depends upon the type of application you are building.
You could have a simple data entry form, where simple client side validations would suffice, and on the other end of the spectrum you could have an interactive chart, which would allow you to drill down and see details.
Refreshing or changing pages during such a drill down investigation would really be annoying to an user. If I can use AJAX here pull data asynchronously, this surely would lead to better usability!
This is not to say that I actually do this, but technically your argument that you have to use a different set of languages between the client and the server is false. You could use JavaScript on the server and client side, and even serialize data between the two using any of a number of different data formats. Server-side JavaScript implementations include Rhino (Java) and SpiderMonkey. Also, Flash MX’s ActionScript is nearly identical to JavaScript.
As to whether or not JavaScript is ‘business-hostile’, I think that’s a wildly subjective claim.
This is not to say that I actually do this, but technically your argument that you have to use a different set of languages between the client and the server is false. You could use JavaScript on the server and client side, and even serialize data between the two using any of a number of different data formats. Server-side JavaScript implementations include Rhino (Java) and SpiderMonkey. Also, Flash MX’s ActionScript is nearly identical to JavaScript.
As to whether or not JavaScript is ‘business-hostile’, I think that’s a wildly subjective claim.
1) use good component oriented web framework , namely : tapestry, echo, phpSiteManager .. encapsulate javascript within the component
2) avoid inline javascript, use anonymous function to assign event listener.
3) refactor javascript code into classes in .js then include..
We have been doing with tapestry and phpSiteManager … and the customer were impressed …
1) use good component oriented web framework , namely : tapestry, echo, phpSiteManager .. encapsulate javascript within the component
2) avoid inline javascript, use anonymous function to assign event listener.
3) refactor javascript code into classes in .js then include..
We have been doing with tapestry and phpSiteManager … and the customer were impressed …
AJAX is just old wine in a new bottle. Nothing’s new here. XML, HTML, CSS, Javascript, and XMLHTTP are all pre-existing technologies that more clued-in developers have been using for years to make their web interfaces snappier. My current project makes a ton of XMLHTTP calls.
The problem with AJAX is that it doesn’t address the fundamental difficulty in developing web applications–the unbridgable client-server divide. You still have to use a completely different set of languages and tools for writing the GUI on one hand, and the server components on the other, with no possibility of sharing code in between. A web interface that TRULY matches the responsiveness and sophistication of a rich client, backed by a complex object architecture, would inevitably involve having to replicate a lot of server logic in a business-hostile language know as Javascript, in addition to building a whole suite of mapping services invoked with XMLHTTP.
Color me unimpressed.
A truly revolutionary web paradigm would allow developers to use the SAME language and object model in developing both the client- and the server-side. The server would retrieve an objects from the datastore, serialize it, and pass it off to the client for editing. The client would be able to modify these same objects (defined in the same class libraries) and pass it back to the server, which re-validates them and persists them back into the datastore. No need to reinvent the object graph with XML. No Javascript. Simpler mapping architecture.
The only technology that offers this prospect is Avalon.
AJAX is just old wine in a new bottle. Nothing’s new here. XML, HTML, CSS, Javascript, and XMLHTTP are all pre-existing technologies that more clued-in developers have been using for years to make their web interfaces snappier. My current project makes a ton of XMLHTTP calls.
The problem with AJAX is that it doesn’t address the fundamental difficulty in developing web applications–the unbridgable client-server divide. You still have to use a completely different set of languages and tools for writing the GUI on one hand, and the server components on the other, with no possibility of sharing code in between. A web interface that TRULY matches the responsiveness and sophistication of a rich client, backed by a complex object architecture, would inevitably involve having to replicate a lot of server logic in a business-hostile language know as Javascript, in addition to building a whole suite of mapping services invoked with XMLHTTP.
Color me unimpressed.
A truly revolutionary web paradigm would allow developers to use the SAME language and object model in developing both the client- and the server-side. The server would retrieve an objects from the datastore, serialize it, and pass it off to the client for editing. The client would be able to modify these same objects (defined in the same class libraries) and pass it back to the server, which re-validates them and persists them back into the datastore. No need to reinvent the object graph with XML. No Javascript. Simpler mapping architecture.
The only technology that offers this prospect is Avalon.
If you want cross plateform behaviour, use a cross plateform tagblib. Like [URL=http://struts.application-servers.com]Struts-Layout[/URL], [URL=http://myfaces.apache.org/]MyFaces[/URL]
If you want cross plateform behaviour, use a cross plateform tagblib. Like [URL=http://struts.application-servers.com]Struts-Layout[/URL], [URL=http://myfaces.apache.org/]MyFaces[/URL]
But if Google is working for his own browser, and deliver it for all main platforms (Windows, UNIX world (Lunix included), Mac OS, we can be sure it will facilitate their tasks.
I am pretty sure it’s easier and cheaper to develop his own browser and write application for this one only, than write applications for all browser of the market.
But if Google is working for his own browser, and deliver it for all main platforms (Windows, UNIX world (Lunix included), Mac OS, we can be sure it will facilitate their tasks.
I am pretty sure it’s easier and cheaper to develop his own browser and write application for this one only, than write applications for all browser of the market.
Like the J2EE certification by Sun, can’t there be a browser compatibility certification by some organization like the w3c?
Like the J2EE certification by Sun, can’t there be a browser compatibility certification by some organization like the w3c?