The Current State of Ajax 347
Dion Hinchcliffe writes "Ajax hasn't even been big a year yet and already open source development tools by the dozen are pouring out. Not to mention big names like TIBCO and Microsoft already have previews on the way of full-fledged IDEs for developing Ajax applications. Ajax may be the biggest software development story of 2005. Dion Hinchcliffe has a detailed article about how Ajax has evolved over the last six months and assesses the current state of tools, libraries, and mindshare. He also points out that Ajax will inadvertently end up being a driving force for Service-Oriented Architecture (SOA) for many organizations since it requires high performance back-end XML services."
Wow (Score:1, Informative)
More than a year thanks (Score:5, Informative)
Which is strange, because in 1999 I was making web applications that utilised hidden frames to post information to the server and return JavaScript arrays which I would then use to modify the limited parts of the DOM I had access to at that time. It worked in Netscape 3, Netscape 4, and IE 3 and IE 4.
So the techniques in question have been around for ages, and the use of Xml and the XmlHttp objects appeared several years ago with Outlook Web Access.
The ONLY thing that has been around for approx' a year is the utterly stupid name for it, "AJAX".
I'm glad other people are picking up on it and using it, it's very powerful, but let's not credit Adaptive Path with creating a technology or method that many people have been using for a long time.
If you have to use a name, then RIA (Rich Interactive Applications) is far more suitable and doesn't restrict the developer to asynchronous work only for it to be included in that.
Since it's Slashdotted... (Score:5, Informative)
Re:Wow (Score:4, Informative)
Doubt it. More like they saw the "mysterious future" post themselves and the subscribers hitting their machine before the post appeared before all
Comment removed (Score:4, Informative)
Re:What is it? (Score:2, Informative)
Compare maps.google.com to mapquest.com. With Mapquest, when you zoom/move the map, it posts to the server and refreshes the frame. In google maps, there is no post, the map just moves/zooms like it would on a thick client.
-Rick
What is it? Its this (Score:4, Informative)
Ajax is using Javascript to fetch only part of a web page and then updating the page with DHTML and JavaScript, reducing round trip time and server load and making the application "feel " more native.
qooxdoo (Score:3, Informative)
Weird name, but very impressive. Though not an "AJAX" framework, with some effort it can be "bound" to an OOB request factory or something similar to have your cake and eat it (rich client-side stuff + backend server). Very cool. And it works with IE and FF, but obviously better with Firefox.
BTW, I love how this "AJAX" thing is just a cute name for a Microsoft technology that was first introduced with IE4. The first "AJAX" app was the Exchange OWA client.
Re:More than a year thanks (Score:3, Informative)
We were having performance issues with our Intranet home page. The page was data-driven and requests took too long to execute. People would get impatient, hit refresh, add more items to the queue, and eventually things would melt into a puddle.
I rewrote as much as possible using static javascript includes and cookies, greatly improving performance. There were still a couple things personalized to the individual. Those I threw into a hidden frame which filled in a couple drop-down boxes and populated a line that said "Hello username." (not my idea).
If the database was down or busy, those things wouldn't be available, but 90% of the time the users wanted to click one of the static links.
Re:What is it? (Score:5, Informative)
Once you get down to the brass tacks of writing an app, here's a good way [codedread.com] to deal with implementation problems people run in to.
Re:What is it? (Score:1, Informative)
i stopped reading here: (Score:5, Informative)
excuse me?
ajax the functionality has been around for 6 years or more
the buzzword "ajax" and the google maps implementation that skyrocketed the word to buzzword status has only been around for less than a year
i'm usually not one to champion geek snobbery
but when geek snobbery is pitted against cattle herds of phbs spouting buzzwords with little understanding of the buzzword itself, geek snobbery is more appealing
Annoyed (Score:3, Informative)
You can't (via "AJAX") query any site but the one that served the script without the browser imposing this scary security warning. We run the sites in question, they just have different domain names.
Sigh.
I realize there's worry about cross site scripting attacks, and in the end it's not a big deal, it just means moving the request to a server side proxy. It's just added complexity that wouldn't exist if someone didn't impose something "for our own good".
Re:What is it? (Score:2, Informative)
Thin Client, My Ass! (Score:2, Informative)
AJAX requires a client that supports javascript in the first place, along with XML and whatever other bits of things (hidden frames.. god knows what else) to get and manipulate all this data.
So truly thin-clients (think Lynx circa 1996, guys) are SOL. Now it's AJAX or bust.
And you're probably thinking "well who the hell uses Lynx or some other, archaic, web browser?"
Well there are those people out there, but that's not all. I'm thinking about the non-human factor, computer applications that come in whatever form to consume the information available on the web. Many (though not all) don't have a javascript engine to execute the various instructions needed to get at the data. So once AJAX becomes ubiquitous (enough), search engines will either need to start using smart crawlers that can execute javascript, or their indexes will start to really be meaningless.
And that's just one of (what I vision) many non-human processes that take web pages and process them (the data marked up by HTML... remember, that's what the web has always been about, data structured with HTML) to produce more useful information for users, sometimes human, sometimes other non-human applications that futher analyze, compress, etc.. the data they find.
When Flash hit the streets, we saw this problem come up rather quickly, although many simply chose (and still choose) to ignore the issue. You still can't (really) bookmark a single page inside a Flash movie... so if there's vital data you need, you have to watch/move through the movie to get to the key page you're after. AJAX will prove to be no different.
So what? Use RSS or web services or some other means to provide information to non-visual applications (everything besides a web browser developed after 1998).
But RSS,SOAP,etc. is simply re-inventing the HTML wheel. They exist simply because HTML isn't being used the way it was always intended to be. You can write an application to parse heading tags and present their contents in a list format. You can write an application to submit a query via a POST operation (form fields) and parse the results back to the user.
Simple shit. Being done since the 1990s with great results.
But not anymore. The web is abused so much we reinvent HTML with XML. Now we only need a 4kb file to present a 20 character string to a consumer process. Bloated. Ugly. Inefficient.
And you think XML will be the answer? HELL NO. XSLT has no business even existing, and yet there it is. XHTML? Give me a break.
The web is a piece.
AJAX is just helping to quicken the flushing of the web down the toilet, and not helping to clean it.
Re:What is it? (Score:4, Informative)
Re:High Performance Back-end Services (Score:3, Informative)
Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems
Agility, Service-Orientation, Enterprise Architecture, and Software Development
State of Ajax: Progress, Challenges, and Implications for SOAs
A lot of bits have been pushed around the blogosphere on the topic of Ajax over the last few months. This includes my own post back in March, which gave a general overview of what Ajax was and what it does. A lot of exciting stuff has happened since then, and Ajax has rapidy matured into a development of major significance. Coverage has been all over the map and runs the gamut from Rasmus' been-there-done-that 30 second Ajax tutorial to Alex Bosworth's list of Ajax Mistakes to the uber-repository of Ajax knowedge, Ajax Matters.
Many of you already know that Ajax is a web client programming style which eschews traditional HTML web pages, which are only sprinkled lightly with JavaScript and reload pretty much every time they are updated or clicked on. Instead, an Ajax web client receives an Ajax JavaScript library into a hidden frame which provides run-time visuals on the main browser window that look and feel very much like a native application. Ajax web clients, once loaded, communicate with XML services on the back end (via a browser's built-in powerful XMLHttpRequest API), and then use JavaScript to manipulate what the users sees programmatically via DHTML.
All of this allows Ajax to provide a compelling user experience because 1) it doesn't reload the web page, and 2) it runs asynchronously allowing background server-side requests for information to be issued, all while the users clicks, types, and otherwise interacts with the application in the foreground. Google Maps is the pre-eminent example of a modern Ajax application: rich, interactive, easy-to-use, and predictive in that it loads the map tiles that are just offscreen in case you need them. This is all very good for web client client development, but why all the attention across the board?
Figure 1: Ajax: The first compelling new client application model since the modern web browser
Because Ajax is a sincerely compelling synthesis of the ubiquitous features found in the most popular Internet browsers is why. Practitioners of Ajax get high-intensity user interaction (end-user productivity), asynchronicity (efficient backround processing), web browser access to web services (web service access, reuse, and interoperability, as well as SOA integration), platform neutrality (browser and operating system agnosticity), and the Ajax feature set can be delivered as a framework you don't have to create yourself (developer productivity).
Individually, these items are very nice, but taken as a whole, working solution and you have something extremely special. While many folks thought the web browser story had stopped around the year 2000, Ajax takes us to a whole new place. Slashdot recently highlighted a notable new article in Wired that claims that the industry, mostly on the basis of Ajax, "has affirmed the viability of the web as a standalone software development platform."
This is no small thing, and has the potential to repave the modern application development landscape. Why? Because Ajax creates a rich and fertile new space for developing software solutions that can reach almost anyone, anywhere whatever they're browsing with. It doesn't require anything more specific than your local browser, is based on standards, and leverages all the services that most organizations have in place in their back office, especially if they have been building service-oriented architectures.
Of course, there are some problems with Ajax, as there inevitably are with any major new approach. One is testing. You not only still have to test your applications, but even more thoroughly. Given that JavaScript, DHTML, XmlHttpRequest, and DOM support all vary slightly between browsers, you need to test your Ajax applications in all supported browser versions and in multiple screen resolutions to make sure you have
Just developed 2 large AJAX-enabled apps (Score:5, Informative)
I basically did a port of the functionality I had in two Perl/TK apps, but I wanted portability and easy updates of code and I had just done a stress test of AJAX in Firefox and IE and they both seemed to handle the load OK so I started developing.
I did not use any tools aside from a text editor and the browsers to test in. The tools like SAJAX just created bloated code that crashed the browsers once things got too complex for them so I decided just to hand-code it from there on. I built in some session security and user authentication both of which ended up working rather well.
These apps are querying other pages to get updates on phone system extensions statuses(from Asterisk) and other bits of information and updating DHTML elements constantly, so they do generate a lot of HTTP requests and use at least three times of the bandwidth that the fat-client perl/Tk app used to, but the database and web server seem to take the traffic OK and we thought that both of the browsers did too until we did some time tests.
We were able to leave the AJAX app running in the same Firefox session for over 2 weeks before we had to reboot the machine for other reasons which was wonderful and much longer than we thought. But, Internet Explorer never lasted a day. It seems that in the ActiveX element that handles XML requests(IE itself doesn't do it internally like Firefox does) there is a memory leak and within 2 hours our app was chewing up over 120MB of RAM and was getting slower. We tried several fixes and the only way to get the memory back was to kill the iexplore.exe process(This was on IE5.0 through 6.1). And that is the reason we recommend only Firefox for intensive AJAX apps.
In case anyone has read this far, the apps are GPLd and available on sourceforge. They are apps that extend the functionality of Asterisk PBX phone system extensions. You need to have Asterisk and the astGUIclient suite installed in order to test them:
astGUIclient project page [sf.net]
MATT---
Re:More than a year thanks (Score:2, Informative)
XML = Extensible Markup Language. Not exactly an extremely informative name there, but certainly acceptable. I rather it be AJAX instead of:
UJATDUIXFTDUPWRTWPOLANWP = Using Javascript And Templated Documents Usually In XML Format To Dynamically Update Pages Without Refreshing The Web Page Or Loading A New Web Page.
Re:Ajax compared to Flash (Score:3, Informative)
AJAX will work with nearly any major browser off the shelf. poof. No downloading plug-ins once or twice based on how many browsers you are using, no nothing. Just come to the site and begin using the application.
With FLASH, you must download a plug-in. That may not sound like a lot but it is huge. It is at least one barrier for customers (who are by and large tech-retarded) to overcome just to use a vendor's service. And if there are multiple browsers there will be multiple plug-in downloads and there are times when the plug-ins wont work.
So bottom line is, by taking out the need for customers to visit a 3rd party, the User experience is exponentially increased and brand brainwashing commences immediately and without any hiccups. Believe me, no one wants to ever expose 3rd party tools when they are trying to sell something.
OpenLaszlo is more portable (Score:3, Informative)
An OpenLaszlo app behaves essentially like an Ajax app; data requests are made for XML data (or media) in the background, and the user interface is presented as a seamless window-system style desktop app.
Simple Example [laszlosystems.com]
Re:Ajax compared to Flash (Score:1, Informative)
What OS are you using that has such a problem with plug-ins, and the publisher can't/won't negotiate with Macromedia to make sure the plug-ins are preinstalled for their users?
Wait, let me guess, is it Windows from Microsoft?
You're going a little too far. (Score:3, Informative)
Just because something is an over-used, over-hyped fad doesn't mean it has no uses at all.
Re:What is it? (Score:4, Informative)
Re:Simple fix for cross-domain AJAX (Score:4, Informative)
Re:OpenLaszlo is more portable (Score:3, Informative)
Article Leaves out Echo2 (Score:2, Informative)
I've used it on TrackIt [sf.net] for a few weeks now and in my opinion, it is head and shoulders above any open source Java web framework, AJAX enabled or otherwise.
Re:Just developed 2 large AJAX-enabled apps (Score:3, Informative)
The leak is not with the XMLHTTP object, but with Javascript itself. You have to be very careful about DOM manipulation order to avoid circular references that can't be garbage collected, and you pretty need to avoid using closures entirely (which sucks because closures are damn cool). Make sure you clean up after yourself when pages unload (detach events and such), and as long as you're careful you should be fine.
IE's problem is that the DOM is not a pure javascript implementation. Each DOM object is a COM object, and Jscript's garbage collector doesn't handle COM objects properly. Thus, if you get into a circular reference (a node has an expando property that references a jscript method that references the node), the GC can't clean it up because it can't clear COM objects. So long as the node reference stays around, the jscript can't be cleaned up and you're leaking memory.
There's a lot more to it than that, and a lot of other scenarios that can cause leaks. More information [microsoft.com], including suggested practices to avoid leaking as much as possible.
Hopefully IE7 will fix these memory leaks, but I wouldn't hold my breath waiting.
Re:Thin Clients, Fat Pockets (Score:3, Informative)
Re:Thin Clients, Fat Pockets (Score:5, Informative)
MS added XMLHttpRequest to IE4 around 1998-1999. You wouldn't have had to kill anyone.
http://en.wikipedia.org/wiki/AJAX [wikipedia.org]
Re:Ajax compared to Flash (Score:3, Informative)
Quite untrue. Konqueror supports AJAX, I'm posting from it right now, and my Online RPG [dyndns.org] uses it in a few places. Opera also supports AJAX. That leaves us with what... text based or PDA browsers? Most of those don't even support Javascript, good luck getting Flash or something else similar working on it. You never did mention what you would prefer over AJAX, what would you prefer over AJAX anyways? I presume that whatever you would prefer would magically work on cell phones, PDAs and text based browsers too, as you seem to think that that's a major issue for AJAX.
If they have, I haven't encountered it. Besides IE doing it's own thing like usual, every other browser has the same implementation. Unusually enough, in this case, working around IE [dyndns.org] is pretty simple.
That can be said about the majority of web technologies, if you want to support IE, you get to jump through lots of hoops. If you don't care about IE, you can write standards compliant code and expect it to work and look the same in Konqueror, Firefox, Opera, Safari, etc. As always with web development, IE is the problem, working around it is where you will spend/waste the most time.
Having said all of that, like any other technology, you should use AJAX to enhance the experience, not have everything depend on it. Your web site/application/whatever should still be accessable without all of the handy dandy technology, regardless of what it is. That's much harder if you've used Flash or anything else that depends on a plugin for everything, because it means you need to totally rewrite code.
Re:More than a year thanks (Score:3, Informative)
jeff