- Related Stories
-
Google's first mashup goes green
May 30, 2006 -
Web 2.0 meets the enterprise
April 28, 2006 -
IBM eyes programming for the masses
April 26, 2006 -
Microsoft offers early peek at designer tools
January 24, 2006 -
Ajax gives software a fresh look
October 4, 2005
Since that evening, I've spent quite some time researching the AJAX phenomenon, and I've come to a conclusion: I don't get it. AJAX allows a client that is running in a Web browser to communicate asynchronously with a server and to update the browser page dynamically. OK, that's nice; I have always hated browser-based applications that force you to click your way through endless forms and exhibit noticeable delays in updating the screen after you've done anything at all.
In fact, with a few exceptions, I have hated just about every browser-based application that I've ever used. For me, the browser just isn't a good application container. Yes, it is workable, but you constantly find yourself fighting the browser's weaknesses rather than leveraging the browser's strengths. Back button and history issues, security issues, session management issues and HTML/JavaScript incompatibilities all come to mind.
AJAX happens to solve one of the problems--a problem that wouldn't exist if the browser weren't such a lousy application container.
It seems like most legitimate use cases of AJAX make a browser-based application behave more like a rich or smart-client application. What's wrong with rich or smart-client platforms for developing rich or smart-client applications? What's wrong with serving a rich, interactive GUI (graphical user interface) as a Java applet or even as a Java Web Start application, for example?
Over many years, I have seen some beautiful examples of such applications that communicate asynchronously with a server and leverage the complete set of powerful, built-in GUI components.
AJAX is new. AJAX is sexy, but it is hardly revolutionary. I am neither a GUI nor a browser specialist, but I have been able to develop some really nice, portable application interfaces as Java applets for years now. They were at least as portable as AJAX applications are, and they did some things with trivial effort that you would have to work really, really hard for in AJAX.
I certainly admire what the Google engineers did with Google Maps, and I agree with 99.9 percent of people that a rich e-mail client GUI is much nicer than the silly old-fashioned Web mail client interfaces were. I thought to myself: "Man, how did they do that in a browser without applets or embedded objects?"
I admire these solutions the same way I would admire a really smart library that gives a COBOL application similar list-processing capabilities to a Lisp one. There's nothing wrong with the engineers who created the solution. It's the people who wrote the requirements that baffle me. Why do we keep working around browser limitations when someone could be making the browser a better application container?
Before jumping on the AJAX bandwagon, be sure to ask yourself the following questions:
What problems am I trying to solve?
Are there other possible solution approaches, and should I re-evaluate them if the last time I looked at them was five years ago?
What are the security implications of publishing all these XMLHttpRequest endpoints?
Don't misinterpret my discontent as an endorsement of applets over AJAX. Rather, think of it as my reason for asking, "What exactly is it that makes AJAX so wonderful?" Could I have filled a 300-person auditorium with a presentation on "Rich, dynamic Web clients using Java applets?" I'm sure I couldn't have.
Biography
Alex Krapf is the president and co-founder of CodeMesh, a provider of language integration products.
See more CNET content tagged:
AJAX, GUI, Java applet, Java, Web browser
20 comments
Join the conversation! Add your comment
1. Zero footprint. All you need is a browser that was released in the last few years for our applications to work. No framework, Java or otherwise.
2. Ease of deployment. We make changes to the server and all of a sudden thousands get the benefit. Its instantaneous.
3. R.A.D.. In case you haven't really looked around there are tons of vendors that provide wrapped up AJAX frameworks and controls that take all of what you are calling hard work out of it. It's almost zero code now to get your normal postback web apps you already have built to use AJAX.
4a. Scalability. AJAX is lighter in weight than having 10,000 people download your applet.
4b. Scalability. I have several apps that operate as near-real-time displays. They poll every 10 seconds or so. I've done the research and it is tons better to have 10,000 clients hit my lightweight web servers every 10 seconds than it is to maintain 10,000 open TCP connections. Think about it, you'll only see a couple of hundred transactions per second, even with that much load. And web servers scale out so well now with farms and load balancers, why wouldn't you?
I would hope that you take some more time to play with AJAX, not just the raw objects themselves, but some controls, some frameworks. I think you will see its usefulness.
The article was written with a real Java bias. Yeah you can write java applets that work pretty well, but try and deploy them when you have a dozen other apps in your enterprise that want different (and old) versions of the JVM. Then it becomes a nightmare. Trust me on this.
Browser apps are just far easier to manage and deploy. If they weren't, the web wouldn't be what it is today.
"What's wrong with rich or smart-client platforms for developing rich or smart-client applications? What's wrong with serving a rich, interactive GUI (graphical user interface) as a Java applet or even as a Java Web Start application, for example?"
Answer:
For rich-client, when the application is updated it's difficult to get the end-user to update the application. So defects or security holes don't get fixed. Case in point Windows and IE. There are still people using IE 5.x when a much more secure, less buggy, and more performant IE 6 has been available for a couple of years.
For smart-client, the technology is far from perfect.
Java applets require using to have a Java run-time environment with a Virtual machine installed AND the necessary browser plug-in for them to work. Also, they can be a rather large files to download especially over a dial-up connection.
Ajax is another attempt to get the most important part of what Java should've provided which is a program that any client on any platform can run as long as their browser meets some fairly lightweight reuirements.
Every so often I think about learning how to write desktop apps: there are lots of good libraries to do this, and there are even good cross-platform libraries if you want to write things that work on MacOS, Linux and Windows. Still, I'm always left with the question of... What if I want to use this app at work? What if I want to use this app on the Mac Mini in the living room? What if I want to use it on my Athlon 64 hog upstairs? Do I need to keep compiling and installing it? Or can I just write a web app that runs on one server and use it on every computer everywhere?
Javascript is getting better and better all the time, and with AJAX and related technologies, the range of things that we need desktop apps are shrinking... Sure, it's rough around the edges, but sites like
<a class="jive-link-external" href="http://polyhedra.org/" target="_newWindow">http://polyhedra.org/</a>
show that even highly graphical applications can be browser based.
<a class="jive-link-external" href="http://blogs.ittoolbox.com/eai/software/archives/a-different-view-on-ajax-9882" target="_newWindow">http://blogs.ittoolbox.com/eai/software/archives/a-different-view-on-ajax-9882</a>
In general, I agree with lots of your points. However, I disagree with a Swing point.
AJAX fits very well with the rest of the mainstream web technologies that everyone uses unlike Swing that pretty much requires download of the extra infrastructure (and that can get pretty bih) in order for it to successfully run.
Not every user wants Swing when he or she is casually browsing for the tickets, buying books, searching web (Google suggest).
AJAX applications can be a maintenance nightmare with ever changing browser quirks.
There's a little golden rule in that, one that should have been guiding the progress that's stagnated in the last five years: if you feel like you're stretching the limits of your application environment, it's time for a new environment.
The main problem with these AJAX applications is consistency. Because there's no control, because everything you do is a hack on early-90s client-side technology, there's no chance of a standard UI. Some apps support right-click, some don't. Some use the browser's back button to take you to back in the app, some will kick you out of the app, and some will just crash.
Java's plenty powerful and capable to do pretty much any Internet-based app I can think of, but it fails on the UI point. As a Windows user, I'm constantly annoyed at how Swing apps flount Windows UI conventions by attempting to make a "similar looking" cross-platform system. It's the little things that count here - for instance, in any non-Java app, I can scroll up and down with the right edge of my laptop touchpad, something that can only be accomplished with the good old Windows scrollbar. It NEVER works in a Java app.
I'm a casual .NET programmer, and that's a pretty good system for Windows programming (I haven't tried Mono, is it any good?). But as some people here said, one of the main advantages of AJAX is not having to download and install anything. So why can't we fix this once and for all? Ideally, I think this would be perfect:
The W3C or Microsoft or even Opera, Mozilla, or Google should step up and make a new spec for online apps. They'd be downloaded upon entering a URL, like AJAX apps, and run inside your standard browser container (most likely as a separate popped-up window). But, instead of being limited to Javascript, they're just as easy to use as a desktop app on the native OS. They wouldn't be cross-platform without a little effort, but there are some HUGE advantages. On Windows, I'd get a real menubar and Windows toolbars at the top of the screen. Right-click menus, textboxes, and everything other "control" would be not simulated, but displayed as an actual Windows control. In short, except for how quick it took to load the text-based code for the app and how easily the developer can change it (since it's still stored server-side), it's indistinguishable from a desktop app.
Congrats, you finished my rant... bring the flame.
;-)
AJAX is basically Javascript and everything else. Not exactly your ultimate tool for the job but it'll do. AJAX is not the last tool of choice for the same effect. Applets, Flash, SVG and the new WPF/E from Microsoft are some of the choices available. It just happens, that by default, Javascript is the most popular tool supported by almost all popular web browsers. It has little version compatibility issues. It's not bound by the platform. And all it needs is a browser that is Javascript enabled -- and therefore, free!
AJAX will have its time as developers continue to build for the web browser. But I believe that the future is outside the web browser...
What better container can you have for your application but the same that the house is built upon? You got it right... it's your OS.
Plus JavaScript itself is a runt of a language stuck between a web browser and a hard place - Mozilla's plans to update it to 2.0 hold a lot of promise but for now it has very poor features for development for the large code bases that modern web apps are starting to throw at the client - think hundreds of kB of code, at the mercy of the browser's cache as to whether it is loaded or not. We need JS packaging, JS signing and many, many features that applets and other embedded languages for browsers already have. JS 2.0 can't come a moment too soon...
Pioneer-soft said that they are going build GUI-API that is more flexible than Java/Swing for both SVG and XAML/WPF/E. They have provided more than substantial proof at their web site: <a class="jive-link-external" href="http://cbsdf.com/technologies/DHTML-Widgets/TECH-Summary.htm" target="_newWindow">http://cbsdf.com/technologies/DHTML-Widgets/TECH-Summary.htm</a>
The webpage says:
To build great Ajax GUI applications one needs great reusable Ajax GUI Classes (a Class Library or GUI-API) that are more flexible and easy to use than desktop GUI Classes, for example, Java/Swing or Windows/VC++.
All one needs to know is: how he can build GUI Class for one component. The same process can be used to build a GUI Class for any other GUI Component.
Of course, they havent yet created a full GUI-API for all the components, but have presented all evidence one needs, which is backed by many SVG examples to clearly illustrate that it is possible to build such reusable GUI Classes.
<a class="jive-link-external" href="http://www.cbsdf.com/technologies/demo-links/demo-links.htm" target="_newWindow">http://www.cbsdf.com/technologies/demo-links/demo-links.htm</a>
<a class="jive-link-external" href="http://cbsdf.com/misc_docs/gui-api-brief.htm" target="_newWindow">http://cbsdf.com/misc_docs/gui-api-brief.htm</a>
Can any one prove that any piece of their evidence is flawed? The GUI Chars are more flexible than any charts I have ever seen. No flaming. If you dont agree just prove them wrong.
Pioneer-soft said that they are going build GUI-API that is more flexible than Java/Swing for both SVG and XAML/WPF/E. They have provided more than substantial proof at their web site: <a class="jive-link-external" href="http://cbsdf.com/technologies/DHTML-Widgets/TECH-Summary.htm" target="_newWindow">http://cbsdf.com/technologies/DHTML-Widgets/TECH-Summary.htm</a>
The webpage says:
To build great Ajax GUI applications one needs great reusable Ajax GUI Classes (a Class Library or GUI-API) that are more flexible and easy to use than desktop GUI Classes, for example, Java/Swing or Windows/VC++.
All one needs to know is: how he can build GUI Class for one component. The same process can be used to build a GUI Class for any other GUI Component.
Of course, they havent yet created a full GUI-API for all the components, but have presented all evidence one needs, which is backed by many SVG examples to clearly illustrate that it is possible to build such reusable GUI Classes.
<a class="jive-link-external" href="http://www.cbsdf.com/technologies/demo-links/demo-links.htm" target="_newWindow">http://www.cbsdf.com/technologies/demo-links/demo-links.htm</a>
<a class="jive-link-external" href="http://cbsdf.com/misc_docs/gui-api-brief.htm" target="_newWindow">http://cbsdf.com/misc_docs/gui-api-brief.htm</a>
Can any one prove that any piece of their evidence is flawed? The GUI Chars are more flexible than any charts I have ever seen. No flaming. If you dont agree just prove them wrong.
The same goes for the Ruby on Rails crowd...in fact, Dear Author: please focus on them next :)
You also have to ask you're self, "what problems am I trying to solve and what would be the best way to solve it." Most often the three methods preferred by the author don't make sense.