|
Is AJAX worth adopting? |
|
|
|
Written by Harshad Oak
|
|
Apr 13, 2005 at 10:50 PM |
|
Page 1 of 2 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 do that? Actually, even GMail took a long time to start functioning on Opera and older versions of IE.
As most developers would know, even making a basic HTML + CSS app work the same way across Opera, Firefox, Netscape and IE, is no mean task. If you want to support multiple versions of each browser, things become even worse. Now if my HTML + CSS is struggling, how am I supposed to make my complex javascript work across browsers? And that too when there currently are no standards behind AJAX.
With many users moving to fast broadband connections, making server trips isn't as bad today, as it was a few years back. So making the app use XMLHttpRequest and reducing old fashioned server trips isn't much of a benefit if is going to mean that my development time will go up significantly. Also for serverside development, I have compilers, debuggers, IDEs, components that I can plug in and so on...for client side development there isn't much available. So it is very likely that I could end up creating 100s or 1000s of lines of irrepairable Javascript mess.
In our projects, we have even moved input form validations away from Javascript and instead use the Jakarta Commons Validator component. Using validator has not only cut down on development time but we are also sure that the validation will work. With Javascript, it is difficult to be sure. There's always this thought at the back of your mind that I hope the client doesn't do this, this or this on this browser running on this OS.
AJAX is a great new thing and it sure has the potential to revolutionize web interfaces, but I don't think it is worth adopting at least in the near future. Once standards and tools not only emerge but also settle down, then developing an AJAX app would be a good bet.
Related:
>> The search for an AJAX developer
Reference:
>> Ajax: A New Approach to Web Applications
>> Very Dynamic Web Interfaces
>> Validator - Commons
|
Comment by Guest on 2005-04-20 23:16:10
Like the J2EE certification by Sun, can't there be a browser compatibility certification by some organization like the w3c?
|
Comment by Guest on 2005-04-22 13:41:42
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. |
Comment by Guest on 2005-04-23 16:32:45
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. |
Comment by Guest on 2005-04-22 19:15:37
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] |
Comment by Guest on 2005-04-29 18:17:50
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 ...
|
Comment by Guest on 2005-05-05 04:04:38
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. |
Comment by swapnonil on 2005-05-06 00:02:22
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!
|
Comment by The Cowardly Visitor. on 2005-05-14 02:50:12
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. |
Comment by The Cowardly Visitor. on 2005-05-14 11:38:43
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. |
Comment by Noname on 2005-05-18 00:18:40
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
www.backbase.com |
<< Start < Previous 1 2 Next > End >>
|
|
Home | 
