Slashdot Mirror
Building Richly Interactive Web Apps with Ajax
FalsePositives writes "Ajax: A New Approach to Web Applications (from Adaptive Path and via Jeffery Veen) introduces their experiences with what they are calling 'Ajax' as in 'Asynchronous JavaScript + XML' aka the XmlHttpRequest Object. It is used by Google (Google Maps, Google Suggest, Gmail), in Amazon's A9, and a few others (like the map of Switzerland spotted by Simon Willison). ... Is this 'The rise of the Weblication'?"
yet an other buzzword?
Webplication? Please.
First of all, almost any PC will have a semi-recent IE installed (or Firefox for the more enlightened), and that is already enough to run Google's stuff.
Compare that to the Java plugin requirement, which, sad to say, is pretty far behind in availability on most PCs.
Also, Javascript-based stuff is easier to program, trust me on this. Layout of elements is much easier - and it can be done in any decent HTML editor. Finally, there's no thread-related insanity that AWT/Swing bring to the table.
http://zero-to-enterprise.blogspot.com/
I bet someone else will post the exact same thing, but instead they will replace Java with Flash...
I think the point is that you don't need to insert an object or rely on a 3rd party enviroment. You can do it in Javascript.
Also, the reason this is so very cool is that it doesn't tie your applicaiton into a backend of any kind, you can scale your backend as long as it spits out XML. I think this is the reason so many of the big companies are going to it. They require a bit more flexibility on that end.
Fantasy remains a human right; we make in our measure and in our derivative mode... -- JRR Tolkien
I'd' normally agree with you on this one, but you have to ask yourself why Google would do it the Javascript way. Speed. No, this isn't a "Java is slow" troll. I see this Javascript clientside stuff as exciting, because we're using the clientside scripting strengths of the browser, which, even though they differ slightly from browser to browser, offer much in terms of execution speed.
Also, many people are used to the concept of a "web-application" by now (CSS, tables, fun JS stuff, whatever). Being able to extend this now familiar interface by making it look like what the user's used to (for example, a web-driven mail inbox) and add the facility to be able to change these familiar looking pages and make things appear and disappear and load and unload, etc etc etc all without a page reload or launching a VM is very enticing to many web developers.
One last note: Your point about Java is good. However, not all JVMs run EXACTLY as they should on all platforms. Today I had to upgrade my JVM because our corporate site needed something juuuuust slightly different. yuck.
ZERO
What will they search now? I can't see many sites, especially shopping sites, powering their interfaces this way. Suddenly they'd lose all their search engine hits and PageRank becomes that much less useful. Sure it's good for the likes of email sites and interactive maps, where the data wouldn't be indexed much anyway.
Adaptive Path Services: "We evaluate your site and offer detailed recommendations."
wait wait, this is rich, let me get this straight: a web design company wrote a article saying what you're using now is the "old" sucky way and their new stuff is the way to go??
hold on! this is revolutionary! ;)
Not that AJAX isn't great, i'm sure it is, but this is like reading a article on how great a new car is that was written by the manufacture. Perhaps a more unbiased article needs to be submitted before I believe it.
oh and mod me +5 flamebait cuz i have so much karma i'm sniffing clouds.
my karma will be here long after I'm gone
function getDataDOM(url){
data = (!window.XMLHttpRequest)? (new ActiveXObject("Microsoft.XMLHTTP")):(new XMLHttpRequest());
data.onreadystatechange = readyStateChangeFunction;
data.open("GET",url,true);
data.send(null);
return data;
};
You were saying?
Nothing like someone who doesn't get the joke to make a joke all the better.
Ummm, yeah but Javascript in each variation of this or that browser *is* a 3rd party environment in many ways. If I write something like this in Flash, I don't need to worry so much about browser quirks and the like. Plus Flash has a rendering engine designed for apps like this ... something like Google Maps could have been just as "neato" in Flash and would've been much easier to write.
And Flash has 99% penetration, which is probably better than the numbers for browsers which properly support Google Maps. The only real advantage of the "Ajax" approach for that application is you can write the whole app in Emacs, sans $500 Flash IDE.
(Score:-1, Wrong)
Some slashdotters have already identified this technique of using a combination of using javascript, xml, and dhtml has been around for some time (the article even says its mature). It has been refferred to in the past as javascript remoting or dhtml depending on what your talking about. I work for a company with a web database app that uses a similar technique. Our product, Sysbotz Enterprise has been in development about a year now which show you the age here.
I think the big deal here is not some much the technique or the new label they are giving it (ajax). Rather a educational effort to inform developers to thing past the traditional load page, post form, process, return results back to web browser concept of web apps. The web app needs to broaden its abilities and needs to be more interactive which greatly limits its uses.
Cool?
Developing applications using a particular technology because it's cool? Un-f*****g-believable. If you can get something on the web to interact almost as well as a client application it should be considered a miracle of design. The only advantage I see on web apps is that you don't have to install anything on the client PC, and even that's a stretch if you consider the apps that require flash, MSXML or all the different media players.
It's like calling lemmings cool because they invented base jumping.
PS: Yes, I have developed web apps with popout menus and using MSXML to generate SOAP requests for interactive content. It still sucks.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
Bullshit Bullshit Bullshit.
Can I say it again?
Bullshit Bullshit Bullshit.
I write these kinds of apps. I have been doing so for years now. I haven't written a browser-fork in code in AGES. I don't even use the hacks in CSS for chrissakes. They aren't needed.
Remind me never to hire you mmm kay?
No Comment.
Am I missing something, or is this company coming in late to the party and trying to coin the term "Ajax" as if they started the party themselves? Sounds like marketing BS to me. Just take a look at some of their wording. It's as if Google used Adaptive Path to create their client-rich interfaces:
Google is making a huge investment in developing the Ajax approach. All of the major products Google has introduced over the last year -- Orkut, Gmail, the latest beta version of Google Groups, Google Suggest, and Google Maps -- are Ajax applications. (For more on the technical nuts and bolts of these Ajax implementations, check out these excellent analyses of Gmail, Google Suggest, and Google Maps.) Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon's A9.com search engine applies similar techniques.
eTrade SUCKS
Please, point us to all the apps you've written using this "old technology". Point us to ANY app that uses this technology that is more than a couple years old. Point us to any book that uses this technology. Point us to a library/framework that makes this technology easy to use. The truth is that this "old technology" has a lot of promise. The fact that almost no one has used it in a real app goes to show how immature this "old technology" really is.
If one wants to look up addresses every single day, and requires advanced features of some form to do so, I'm sure your solution would be a "better" one. But since I just need to find directions now and again, Google Maps is the perfect solution - minimal, yet extremely user friendly and intuitive.
As for "custom protocol" and "dedicated network client"... Why? We have technologies like XML so that we don't need to write a new format or parser for every task we have. Who knows, though, if you're quick developing such a system the hardware developments in the meantime might not make your efficiency gains negligable. But I doubt it.
There are things that custom client/server models are good for. This is unlikely to be one of them for its user-base. And the people who need a faster network map system probably already have one.
If you're going to be a developer, you'd better get used to it. As hardware advances, so does software and there's always some guy around the corner with the latest, greatest language/tool/etc.
The thing that occured to me, years ago was the shift from 'no, we can't do that' to 'we can do that' which was mostly as the result of much faster hardware with more storage. Ways of doing things which required a lot of power were impractical within the confinements of old hardware suddenly became possible, only to encounter new things which were too grand for the hardware, etc. If you can, imagine trying to run on a 20 year old computer what you can run on a new one. It'd choke the old thing.
So, as the hardwave evolves, so the software and you're able to develop incredibly complex (and probably as unsecure) applications with toolkits which would have once entailed hundreds of thousands of lines of code in a few drag and drops and fill in the properties. It always gets me when I see some application which isn't really doing a hell of a lot is tying up 30 MB of RAM. We ran an entire college on 2 88 MB HD's once...
A feeling of having made the same mistake before: Deja Foobar
Which existing technologies? Google's use of remote scripting (that's the name it's had for years, I don't see the need to change it) uses HTML, CSS, Javascript and XMLHttpRequest.
Given that XMLHttpRequest has been used in relation to these technologies for just under six years, and that before that, invisible inline frames were used to do similar things, I fail to see how this is a novel combination of technologies. In fact it's hard to conceive of a use of XMLHttpRequest that didn't use these technologies.
GMail is the most complex example of it I have seen. GMail is the most popular example of it I have seen. But "complex and popular" does not mean "innovative" unless you are looking in a Microsoft dictionary.
Please go back and read what I wrote. I know this is impossible in those browsers. That's the whole basis for graceful degradation.
It is certainly possible to build a webmail application that works in Lynx and Netscape 4. It won't be very fancy, but it will work.
You can make it much more user-friendly for more advanced browsers in one of two ways.
Do it the Google way, and construct a Javascript behemoth that fails to function at all in browsers that don't support every feature Google wants.
Do it so that it degrades gracefully, so if a browser doesn't happen to have all the features you use, it falls back to less onerous requirements.
Quite frankly, I'm surprised that Google don't understand this better. If pages didn't degrade gracefully, the Google search engine itself would not be possible.
I should also note that we don't have to go back to browsers like Netscape 4 and Lynx when talking about this stuff - the latest releases of Konqueror, Opera and Safari have all had problems dealing with the GMail code.
I would be almost completely convinced that Ajax is the solution to the Reload Problem, if it weren't that there is one imperfection: in order for it to work, Javascript has to be enabled in the client browser. Yah, ok, almost everyone has it enabled, but it's not 100%.
Even a small percentage of clients without Javascript is a major usability issue if you're talking about an enterprise web application. I avoid Javascript altogether, not because I don't like it, but because it's not a gaurantee.
1. Java penetration is nowhere near that of Flash. If you really want to go proprietary, use Flash. Not only does it also allow XML requests to the server, it also has a very nice application creator.
2. The differences between platforms is way overstated. My apps run in Firefox, Mozilla, and IE for Windows, as well as newer versions of Safari.
Javascript is included in all browsers. Every platform that matters has an interpreter already. It's a great choice.
Do you have ESP?
Well, at least that's what makes GMail, et. al. different/innovative.
It appears they started with a UI design and worked backwards to figure out a way to implement it. If it couldn't be done in IE6/Firefox it got canned, otherwise they pulled out whatever tricks they could to get it working.
Google knows how to gracefully degrade. But the browser wars/innovation have been over for 5 years. They decided to focus on usability and leave the non-compliant browsers at the station.
The marketplace apparently approves.
When we were coding for a new major browser rev every 9 months, graceful degradation was a more useful concept. Today there are basically 3 categories of browsers: lynx, modern, and old-and-busted. They probably never considered lynx and decided to ditch old-and-busted.
If you can measure an appreciable productivity increase for a good UI, how much of that is worth sacrificing for lynx? Graceful degradation may have outlived its usefulness. Somebody's going to have to figure out how to make these apps accessible in another way.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I don't understand why developers still look at HTML fix ups to make web applications rich. Especially when a tool like Macromedia's Flash allows a developer to build a rich web application with a clean interface that truly mimics a desktop application's.
Let me know when it works on my iBook running Debian (Google Maps behaves perfectly). And I'm sure people running BSDs and proprietary Unixes are equally thrilled by Flash. Clearly Macromedia doesn't care much for cross-platform compatibility, given that they completely ignore this petition (there is even a version of RealPlayer for Linux on PPC).
- Kevin B. McCarty
I'd rather those Flash examples than something like that zoomable Swiss map which was slow and kept forcing focus on the browser window when I was trying to click across somewhere else.
BTW, that ESPN example used Flash for the shot chart, but not the Game Updates.
'Thats they exact same thing a banana wrench monkey.'