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.
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!
I started in about 2000 with hidden frames, Javascript, and DOM. I got the idea from someone else on the web; I thought it was brilliant at the time. I was able to auto-update forms without clearing the form, etc. All the stuff that AJAX is doing now.
It's nothing new. Other folks just think it is.
Microsoft is to software what Budweiser is to beer.
Dion Hinchcliffe writes...
'Dion Hinchcliffe has a detailed article about how Ajax has evolved'
It is never a good sign when someone talks about themselves in the 3rd person.
You gotta love those consultants, always after some free ad space in search of the dollar...
The "name" AJAX hasn't been around long, but client JavaScript loading XML from servers for dynamic page rendering, inrteractive with client GUI events, has beeen around as long as JavaScript and XML. Before XML, it was data in proprietary or app-specific formats. Along the way it was FRAMES. The technique has always been the wizardry of the most aggressive web developers.
But now the marketers have a buzzword for it. It's good to have them back. They got so spun out as the Bubble popped that we haven't been able to get them to get anyone to buy stuff for years. Now it's time for them get back to work, marketing the tech that the rest of us have been producing for the past 5 years. It's good to have you back on the team - now show us the money.
--
make install -not war
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.
What i learned with the painful development with javascript, is that standards are good, using the DOM model instead browser specific extensions is a good thing, better compatibility, the API is more stable, for this reason i think that the right thing to do is embrace the Document Object Model (DOM) Level 3 Load and Save Specification standard for asynchronous communication instead XMLHttpRequest.
Rich web applications... what a great idea.
I've been telling clients for years (since about 2000) to give up on any grandiose ideas of a highly interactive web site. Javascript and DHTML were just hype and didn't work worth a shit in the real world.
Ironicly, my main example was Google... a dead simple interface that lived within the limited means of HTML and was still extremely usefull. Nowadays, Google is leading the way into more interactive web applications. So, I guess it's time to change my advice.
Still, AJAX is basically a dirty javascript hack to achieve rich interactivity in today's browsers.
I hope the evolution of interactivity in the browser doesn't stop here. It seems like there's got to be a less hacky way. One good thing is that the use of XML should allow client side technologies to evolve independently without having to rewrite server-side code.
Anyway, it's about time!
-cbare
At the end he asked us our favorite things we saw demo'd...I was so tempted to yell out "Firefox!" but I refrained :)
I can't believe nobody has mentioned XAML yet. Doesn't anyone remember hearing Miguel de Icaza ranting and raving about how XAML was going to spell the end of cross-browser, cross-platform web applications as we knew them, because everyone would be writing stuff that requires a browser that has the entire .NET API embedded inside it?
It's becoming very clear that AJAX is going to stop XAML dead in its tracks. Microsoft was pushing this whole "rich vs. reach" thing, but with AJAX you really can have it all. No need to restrict your user base to Windows XP or Vista in order to get rich controls in your web apps.
I think that's the more interesting story here. The monopolistic Windows desktop isn't going to disappear overnight, but the continued existence, improvement, and increasing pervasiveness of web applications will continue to make the non-Windows desktop more viable and widespread. (Click on the link in the previous paragraph to read a longer piece on why this is the more interesting story.)
Tired of FB/Google censorship? Visit UNCENSORED!
And if you're going to be doing AJAX with Firefox, then you may as well use XUL. I'm very excited for the day when we see intensive XUL/AJAX applications. THAT's going to be slick.
Thanks for the critique, this was the first non-trivial large project I've done in PHP in about 4 years so I do admit that my PHP and Javascript were a little rusty going into this.
I usually do a lot of separate print or echo lines while developing and for ease of commenting out parts at times, just a preference of mine.
I found through writing this AJAX code that writing linearly is your friend. Yes, there is a TON of duplication in the code, but every time I started heavily using functions in Javascript, things started not working right, and nesting functions and calling functions within functions several levels deep will not always execute as expected, but the same code written in a more linear fashion will execute much more reliably in Javascript(NOTE: the only AJAX code in the project is in the 'agc' folder of the package)
Thanks for recommending switch, wish I'd known about that earlier, but I've been out of active daily development in PHP for years. I do plan on using that in future projects.
Consistent HTML case has always been a weakness of mine.
I'm actually not even using XML formatting for the passing back to the main script of the data from the XMLHTTPRequest scripts. I just use pipe-separated or one element of data per line output and parse the data differently for each type of request. The AJAX code in the project is confined to the 'agc' direcotry, I do have a lot of other PHP and Perl code in the rest of the package that has nothing to do with AJAX.
Thanks again, It's rare that you get good constructive feedback on coding if it's not a very widely distributed package.