Slashdot Mirror
The Current State of Ajax
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."
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.
I think we've been seeing this shift for a while now, since people went from fat client software towards more streamlined C/S replacements, due mostly to convenience and easier features, server updates etc. Plus you can't argue with the repeat revenue stream generated by services that you can offer your customer, as opposed to a single sale.
When did you move your email handling from a fat client to webmail? My first move was from Eudora to Outlook, then Outlook (yuk) to Pegasus (don't ask) and then to Hotmail and now Gmail. I don't think I'll move away from Gmail, but you never know.
Ajax unplugs you because you get the immediate, targeted response from the server that wasn't available before. So refreshing a whole page when I only need to see a small widget change is really what Ajax fixes. I look at Ajax as being only a bugfix to the intarweb and nothing else, really. Seriously, why do I want to refresh a whole template when I want to send only a little widget of text in the middle?
Frames were not the way to handle this kind of presentation/data separation, mostly because they could be indexed and that would confuse visitors coming to the center frame and not the whole display. Eventually many people just stopped using frames because they are clunky, and have strange display problems on varrious systems. Ajax remedies this problem, really. Hypothetically you could set up a site that had a bunch of frames that interacted independantly and achieve a similar result to Ajax, but who would want to have to handle the cross platform and cross browser problems that arrive when you rely on frames?
Ajax is definately going to push for more service oriented contracts and eventually I can see products dwindling or becoming wrapped into services and monthly subscriptions instead of out of the box solutions that are popular today.
I will bet that eventually we'll see some very thin looking clients in the near future, thanks to Ajax.
The dangers of knowledge trigger emotional distress in human beings.
SERVICE UNAVAILABLE
You could see the dupes as the editors approved them.
"Ajax hasn't even been around a year yet"
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.
...here's an article by Curt Hibbs on Ajax with Rails. He's got an "Ajax in 60 seconds" history lesson at the top of the article...
The Army reading list
Ruby on Rails and AJAX makes everything else obsolete. A coworker and I just implemented the J2EE spec in 25 minutes. We're working on the win32 api on monday!
Conformity is the jailer of freedom and enemy of growth. -JFK
Comment removed based on user account deletion
Does anyone here know of a good reference for balancing the "gee-whiz, nifty" aspects of ajax techniques with designing towards accessibility? I like the thought of, say, livesearch, but dislike the idea of breaking support for text-to-speech readers, assistive devices, et cetera.
In fact, the article in the story might have a terrific section about just this issue. But I wouldn't know, because the server fell over worse than I do after a gin-and-tonic bender.
Ajax is a buzz-word for Asynchronous JavaScript and XML. It generally refers to web based applications that feel more responsive than traditional pages because they don't refresh the whole page every time the user does an action. There's plenty more on Wikipedia.
Once you get down to the brass tacks of writing an app, here's a good way to deal with implementation problems people run in to.
more of the same on Twitter.
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 whatev
There are lives at stake here!
"Ajax hasn't even been around a year yet"
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
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
The person who makes a technology popular receives technical fame for a good reason -- by making more of the world aware of a good technology, in a way that leads to deployment, the world becomes a better place. Sometimes, popularization adds more value than invention to an idea.
We need to write out business apps in Javascript now because this is the only standard browser vendors can agree on?
Javascript, it's non-standard browser-specific extension syntax and the restrictive, incomplete and non-standard HTML DOM is an awful environment to write apps in, and it illustrates clearly just how dysfunctional the modern software industry is today.
AJAX is a shit way to write apps, it's central concept revolves around badly hacking around a problem that shouldn't even exist in a language that was never intended for use in such a way, its like we've got the worst aspects of every major technology available today, grudgingly provided by browser vendors who are want to take their ball and go home since nobody wants to use their proprietary ActiveX or XUL - in an incompatible fashion and we're supposed to see this as a step forward?
It's stupid, AJAX is stupid, and browser based apps are crap.
I gots ta ding a ding dang my dang a long ling long
Now I'm not saying that these are mutually exclusive technologies (Macromedia itself has put out some examples of them working together), but as someone who started out writing a lot of Javascript and moved over to Flash in part to escape browser incompatibilites, what is the technical advantage of Ajax as compared to Flash.
As far as I can tell, Flash is more accessible (they've built in hooks for this), and Flash uses less bandwidth. (It comiplies to a binary format.) There's an open source compiler (MotionTwin). Flash also seems to provide a better user experience. (Compare Google Earth to Flash Earth.)
I know everyone here doesn't like Flash because it's used for advertising, but people here talk a lot about how wrong it is to attack a technology because of how some people choose to use it.
So, seriously, I've been thinking about looking into Ajax some more, but right now I don't have a good reason to. Convince this Flash programmer that Ajax is a better solution.
I just finished about 4 months of work writing two AJAX apps using PHP with javascript and while the end result is what we were hoping for and the app runs beautifully, it took me a tremendous amount of time to code it as compared to a standard fat-GUI-app that runs on the client machine.
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
MATT---
I'm working on a script for a Matt Damon movie, "The Bourne Shell".
FLASHBACK - INT. CAR - NIGHT
"Kill zcat," sed ed.
"Awk!" sed perl.
"Make sum nice tee, joe," sed man.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison