Slashdot Mirror

JavaScript was originally just going to control some minor browser behavior; moving windows around, etc. So it didn't need to be efficient or well thought out. Then it got extended and overused so much that it slowed down computers so noticeably that it caught the attention of everyone.

Actually, web technologies were horrible, with every major browser adding its own incompatible extensions and the W3C barricaded in an ivory tower, and Microsoft extended their version of Javascript to support the insane uses of Internet Explorer as the Windows Update control panel and stuff like that. Then Microsoft won the browser wars, and web technology stagnated, until some people figured out that "the XML HTTP thing" could be used to create web applications that communicated in objects instead of reloading all the time, and Jesse Garrett gave it the name Ajax. Then there was a business use for Javascript to be fast.

Then Douglas Crockford discovered that Javascript has good parts, the WhatWG started doing HTML5, and now many web sites don't show anything at all without Javascript, but at least you can compile a sane language into Javascript.

Sorry, your rambling - that is supposed to be a question I presume - is a tad incoherrent. But I do think I catch your overall drift, so I'll chime in:

I think the overall issue is basically about programming languages. Wether it's some software runtime enironment or the other - in the case of JS Node.js just happens to be the first to revive JS on the serverside.

To the case:
Wether or not a PL takes over is dependant on things that usually have nothing to do with the PL itself. Once a PL is sufficient enough .... ok, scratch that. Take for instance PHP. PHP was a joke when it becam popular. 2 guys had a thing called Zend engine and they decided to craft it around a Perl based templating "language" that was becoming popular - mostly because Perl is quite bizar to handle and it was the most popular web scripting language back then. They built PHP 3 based on the zend engine, then a mod-php was added for the popular webserver Apache and the rest is history. All things went web, as a result we have PHP pissing into serious Java territory today. I remember when PHP was a joke and JSP seemed to be posed to rule the webworld for decades to come. That didn't happen, mostly due to political reasons. ...
Had Netscape released their webserver as FOSS back in the mid-90ies, we'd all be using JS as serverside language ever since, since JS was the serverside language on the Netscape Enterprise Server.

I think compiled languages are impractical for web environments, for reasons everyone can come up with, so that rules out C and C++. For every environment that is set up from scratch I can't think of a single expert that would recommend .Net. .Net exists because it banked on the existing Windows/MS legacy. The MS CLR may be a neat feat, but it is a MS lockin trap, and today it's mostly pointless, since abundant server power, virtualisation and simular things have made optimisation concerning multiple runtimes on one setup a non-issue.

This leaves us with JIT/bytecode compiled or interpreted languages. Here I see Java vs. all the rest (Python, PHP, JS, Ruby, etc.). It's basically Java vs. FOSS languages. Java *is* a FOSS language by now, but the problem is that Oracle is a very bad herald for FOSS Java, and the FOSS alternative, OpenJDK/SDK is bad/slow.

For the future of web I do see Node.js gaining lead position. Google put serious cash into aquiring V8 technology, improving it and putting it into Chrome. Flash was killed by Steve Jobs/iOS, pushing brilliant no-Flash-allowed devices (iPhones and iPads) into millions of end-user hands, so Google had to come up with a serious alternative. Hence JS/V8.

Not being stupid - selling software is *not* Googles business - they released the impressive V8 engine as FOSS, and some smart people put in the effort to port that engine to the serverside, where it is about to kick PHPs and Rubys ass, simply because it's at least as good as either of those *and* it is the same primary non-lockin language on the serverside as is on the clientside. Mind you, clientside JS only became popular once a guy wrote a famous blog article in which he renamed "doing important smart things with JavaScript" into "Ajax", which is a cool name and thus made JS on the clientside popular with a lot of people who formerly had no interest in looking into JS seriously. We have the same effect when some smart guy decided that plain Java objects weren't used and other things like EJBs were more popular simply because regular Java objects didn't have a cool name. So he named them Pojos (Plain Old Java Objects) and solved the problem. Any serious respectable Java toolkit today uses Pojos at its heart.

Bottom line: Wether a tech or PL catches on, gains traction and becomes the next big thing is usually rooted in issues one would not think as relevant right away - things like 'Does the tech have a cool name?', among others. That sa

The name is barely even five years old and already people forgot where it came from? Here's the blog entry where the term was coined. The technology was around before the term was coined, but that doesn't make it a backronym. After all, when we discover new things and don't come up with a name until later, that's not a backronym, it's just a name. Sure, Ajax is an acronym, but its letters weren't given a meaning after the fact like you would with a backronym (e.g. "bump" meaning "bring up my post" on message boards). Rather, the letters were given meaning at the same time that the term itself was coined, as the blog entry I linked shows.

I remember the day Jesse James Garrett posted that article where he coined the term Ajax, and he introduced it as "shorthand for Asynchronous JavaScript + XML". So unless he first named it after a Greek god, a scouring powder or a Dutch soccer team, it's not a backronym.

What TFA describes is not Ajax, but a much older technique using iframes. Congratulations, you just rediscovered the Web of your ancestors.

Glad to hear that they are developing the Aurora project. Very interesting piece of software, you can find the home page at http://www.adaptivepath.com/aurora/

Yep, that be correct.

What are the issues in designing an interface that is clean, easy to understand, and easy to use? What are things to be considered? What are things to be avoided? What are good over-all philosophies of UI design? Reading the questions posted, I'd recommend becoming familiar with the broader principles that inform nearly any sort of design; then narrow your reading and research to specific GUI-oriented design. Developing a healthy sense and understanding for what makes an effective user experience is important to any sort of consumer design work (and effective UI design definitely is about understanding your consumer/target audience); "usability" as a discipline has yielded to the larger field of Experience Design (XD) as a key area of study for GUI-designers. Let's start from the 10,000-foot view: Books I'd recommend for your conceptual skills are: --Bill Buxton's *Sketching User Experiences: Getting the design right and the right design*. Bill's background at Xerox PARC and later at SGI/Alias|Wavefront (creators of the Maya 3D CGI software, among others) have made him a pretty revered figure in the industry. This book's a terrific primer on the process of thinking about design. --The upcoming O'Reilly release, written by Adaptive Path, *Subject To Change: Creating Great Products & Services for an Uncertain World*. What's the distinction between product and service? Adaptive Path--the outfit from which came Jesse James Garrett's seminal white paper on Ajax three years ago--started thinking about this as they examined the success of the iTunes and iPod experience; the book grew from there. Moving down to 5,000 feet: For best-practices from the usability perspective (hey, an easy-to-use site usually has a well-designed GUI), it's hard to beat the two canonical books: --Steve Krug's *Don't Make Me Think!* (now in its second edition) --Jakob Nielsen's *Designing Web Usability* Both books arrived as website usability emerged as the successor to the David Siegel School of "third generation web design" in the late 90's. Nielsen codified usability best practices through a research-intensive method, and Krug made usability accessible for the creatives who thought Nielsen a bit pedantic. Solid, foundational material that hasn't needed radical revising in nearly 10 years. Ground-level: Here's where you and/or your team go to work, and I heartily recommend you check out another O'Reilly title, *Designing Interfaces: Patterns for Effective Interaction Design*, by Jenifer Tidwell. There are several solid tutorials out there on in-the-trenches GUI design, but I've still seen nothing as effective as this one. Hoping this helps, --Steve Weiss Executive Editor O'Reilly Media Links: http://www.billbuxton.com/ http://adaptivepath.com/ http://www.useit.com/ http://www.sensible.com/ http://jtidwell.net/

AJAX = Asynchronous Javascript And XML. The name was coined by Jesse James Garrett at when he wanted to tout the merits of Javascript, the DOM and XMLHttpRequest to a client, so yes it describes old technologies with a new buzzword.

I also used to balk at it - in much the same way as most of you also balk at web2.0 - but I feel it's helped inspire great design concepts and propel the development of such Javascript projects as Prototype, Mootools, Dojo, and the stalled-but-promising TIBET from Technical Persuit, as to make it all worthwhile. Certainly it has generated more excitement than "DHTML" did in its day.

In moderate doses AJAX can do great things for a web-site. But just as with Flash, Java and animated GIFs, too much can be a disaster. Use sparingly.

if you were any sort of DECENT consultant, you would have stated this on a blog, with link-whoring to scoble (no link because WE DONT LINK!!!), adaptive path, wikpedia, patented the term "1's and 0's" (in the process starting a flamewar with any site using them), and started a range of high priced conferences in exotic locations.

It would be typical with a forum full of engineers to simply pass up web 2.0 as some marketing buzzword for a new implementation of something old. In many ways the attributes associated with what is being collectively called 'web 2.0' are simply old ideas implemented in a medium where they can succeed in a big way.

It's important to understand that the difference in the web is not in the implementation but in the experience of the end user and how content is created, managed, and distributed. Adaptive path has a writeup about this at http://adaptivepath.com/publications/essays/archiv es/000547.php

The difference is important because it changes how developers and designers percieve the web when they are creating new things. There are many features of newer web software that contribute to the ways in which people use and experience the web.

My favorite is the preference in designing software for the long tail. Which is mentioned in Wired http://www.wired.com/wired/archive/12.10/tail.html This is the practice of serving many niche markets with targeted software instead of building software to service all of the market and doing it badly. This causes less confusion, less clutter, better software and faster turnaround.

Some of the other features of the newer web software you might have already noticed are decentralization, remixability, co-creation, and their side-effect of emergent systems. Web services, niche software and the network effect all make these things much more feasible than they have been in the past since there are well defined frameworks for distributing services that are easy to work with and adding more niche services increases the value of all web software by a large amount.

Notice I didn't say AJAX or Ruby on Rails or Django or [insert your new framework or technology here]. These are merely details of implementation. If a framework makes your company faster then that's good. If a technology lets your user's client fetch web service data for them, that can also be good. These things are only technologies used to reach an end product. Web 2.0 could have been done in many languages and frameworks and on many platforms. That's not to say that certain languages, frameworks, etc. didn't have an effect on the design of the software, as any language or framework has a certain effect on the overall style of the developers using it.

This was about a need for developers and designers to move beyond what was status quo for interaction between websites and their users. They are taking full advantage of the tools they have created and the network that was built up over the past few decades. To belittle their efforts into something meaningless is to surely miss the entire point.

First Ajax does not require XML

Wait, what? AJAX: Asyncronous JavaScript and XML.

Ajax when done properly includes REST, Web Services and a decoupled architectured.

AJAX: Asyncronous JavaScript and XML - no web services and no decoupled architecture. It quite tightly coupled, considering that each subsequent trip to the server updates specific pieces of a browser based UI.

Ajax is a SOA client that makes Web Service calls.

No. AJAX stands for Asyncronous JavaScript and XML. To further define AJAX have a read here (i have a feeling that you already have): http://www.adaptivepath.com/publications/essays/ar chives/000385.php

AJAX is not based on SOAs, it never will be because the client will always execute asyncronous javascript calls (read, browser) and it will (happen) to use xml as the data structure to return the information.

You seem to be pretty good with buzzwords, you should invent a new one that more aptly describes the concept you are trying to convey. AJAX was coined (by AdaptivePath) to refer to a specific style of web application in which the browser does not refesh the entire contents of a page, this in turn enhances the usabilty of the interface. AJAX was *not* coined to refer to a variety of applications that have the ability to exchange arbitrary data via WS, XML encapsulated in HTTP transmitted with TCP/IP.

It sounds like you are on to something, just stop calling it AJAX.

Uhh...sorry, but the guy who coined the term "Ajax" in the first base does NOT describe it as an SOA client that makes web service calls.

See:
http://www.adaptivepath.com/publications/essays/ar chives/000385.php

I will agree however that that is potentially the best use of it.

That being said, why would I bother learning a brand new technology which has nothing to offer over either a java or .NET thick client?

What drivel! M$ "invented" Ajax?!

Your own link demonstrates that M$ did no such thing!

http://www.adaptivepath.com/publications/essays/ar chives/000385.php

It quotes Jesse James Garrett as coining the term...although leave it to M$ fanboys to attempt to steal yet another idea/technology and try to pawn it off as their own...

Are you sure about it being an acronym? From the Adaptive Path site:

"Q. Why did you feel the need to give this a name?

A. I needed something shorter than "Asynchronous JavaScript+CSS+DOM+XMLHttpRequest" to use when discussing this approach with clients."

More unfortunately, Adaptive Path, the coiners of the original term/acronym also do not.

Unless I'm missing something...

It sounds like you think Ajax is something exclusive of web standards. Really good Ajax is just like good DHTML, it degrades gracefully. So no, they're not incompatible.

Here's the numero uno reason to use Ajax over whatever else there is in the world (Java...): light-weight asychronous data transfer, used towards tightening user interaction and feedback.

Read the original article if you still don't get it. http://www.adaptivepath.com/publications/essays/ar chives/000385.php

PS - While I make no claims to my personal ability to do the same, your website doesn't give me a lot of confidence as your to your ability to *design* websites.

I'm increasingly of the opinion that for all but the simplest of sites, there just aren't any good "off the shelf" content management systems, unless you have no problem with your site looking like the default installation of whichever CMS you chose.

Here's the logic:
1. A very basic site (read: a blog) with a very basic CMS is generally not hard to set up.

2. The technical issue: as sites get more complicated, the level of sophistication required by the user to install and maintain them increases. (In the extreme case, I submit Xaraya, a CMS so complicated that trying to create a site as simple as "I just want a page with our contact information on it!" becomes an exercise capable of inducing intra-cranial hemmorage). Additionally, any templating system required grows more and more arcane, until it is essentially indistingushable from the actual programming language in which it's written.For example: the easiest way of getting a Drupal site laid out and usable quickly is to use the PHPTemplate plugin - in other words, to just write PHP code. David Heinemeier Hansson, no stranger to controversy, went a step further than this and labeled general-purpose CMSes "pipe dreams," and said "I believe the time has come to mark a date in the not too distant future for celebrating the death of the general-purpose content management system." (Not like he doesn't have his own thing to push, but that's as may be. See also Jeff Veen's frustration with open source CMSes

3. The social issue: as the content management system grows more and more complicated, they become more and more intractable for the average end user. Responsibility for day to day site updates is pushed to the IT department, which is absolutely not where it belongs. (Once again, I give you the one, the only, Jeffrey Veen.)

Thus they become part of the language. See "Google" or more recently, "AJAX".

Ahh.. AJAX. Yet another word we can live without. You realize that acronym was invented for an existing set of technologies by a company called Adaptive Path in order to sell conference passes? (Even though the first Asynchronous Javascript & XML application was created by Microsoft, and popularised by Google with Google Maps).

Yeah! Ha ha! Apple should have created their own handhelds, including an OS, from scratch to avoid using Microsoft technology! They could have had this all implemented by 2015 if they were lucky. Where does this stupid "Apple vs. Microsoft" thing come from? Microsoft makes software for Apple computers. Apple hardware runs on Windows computers. There's no "war" there.

I'm not implying a competition. My point is that Apple's "retail revolution" is a thin facade of marketing based on real products from other companies. It's much like that "revolutionary technology" AJAX, which is basically marketing hype (to sell conferences and seminars) around a particular use for Javascript and XML.

Really? And who came up with this blurb, who is marketing it?

Adaptive Path.

Not really "just a function", but a substantially new/different way of architecting a web application, no? A paradigm-shift, if you will. ;-)

I won't. It's not even close to new - Microsoft pioneered the technique back in the 90s for Outlook Web Access. It isn't just a function, that is true. It's just an object. Has a few interesting methods and properties. In retrospect, it's so damn obvious it's a wonder netscape didn't include it in their first iteration of Javascript.

Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what's possible on the Web.

Ajax isn't a technology. It's really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

• standards-based presentation using XHTML and CSS;
• dynamic display and interaction using the Document Object Model;
• data interchange and manipulation using XML and XSLT;
• asynchronous data retrieval using XMLHttpRequest;
• and JavaScript binding everything together.

As others have noted, a shorthand term comprised of the intials of a series of words, and is itself pronounable as a word, is an acronym. Revisionist hostory not withstanding.

The XML part is typically ignored in AJAX discussions, either because people find XML all scary and complex (and so use html/tag-soup), or because they do not understand the inplications for character encoding and internationalization.

Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what's possible on the Web.

Ajax isn't a technology. It's really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

• standards-based presentation using XHTML and CSS;
• dynamic display and interaction using the Document Object Model;
• data interchange and manipulation using XML and XSLT;
• asynchronous data retrieval using XMLHttpRequest;
• and JavaScript binding everything together.

As others have noted, a shorthand term comprised of the intials of a series of words, and is itself pronounable as a word, is an acronym. Revisionist hostory not withstanding.

The XML part is typically ignored in AJAX discussions, either because people find XML all scary and complex (and so use html/tag-soup), or because they do not understand the inplications for character encoding and internationalization.

Maybe he deserves some credit for giving it a name. Maybe. All I know is that every time someone mentions Ajax as the "next big thing" (and maybe even puts up a link to that horrible article again) it sets my teeth on edge.

/rant

MS bashing aside, it kills me that something as vague as AJAX is touted as a specific technology with a birth date. The only thing with a birthdate is the term. Wikipedia says it's when Jesse James Garrett first coined the term, in an article dated 2/18/2005.

DHTML has been used for a long time, and describes such a huge variety of techniques that it's not terribly useful when we want to talk about the use of XMLHttpRequest usage

The same criticism applies equally to AJAX. The things people call "AJAX" often don't use XMLHttpRequest or XML at all. It's basically just DHTML by another name. You might argue that these people are using the term incorrectly, but you'd be wrong - even the original article that coined the term describes applications that don't use XMLHttpRequest or XML as "AJAX".

So if you are ready to argue that DHTML is too vague a buzzword to use, surely you must think the same thing about AJAX?

A key enabler of AJAX is XMLHttpRequest (Apple Dev Connection , JJ Garrett's previously mentioned article). MS was an early implementor of this feature, in MSIE 5.0 back in 2000 (see this MSDN article). It seems that the capability lay in wait for years. Only recently has this synergistic combination of technologies truely come into focus. It's looking like AJAX and broadband could threaten the MS hegemony - we no longer need a local install of MS-Office, at 600+ Mb and $250+. A web server-based implementation may work just as well, a lot cheaper, a little slower, and without the problems inherent with installing software on Windows. note to intolerant moderators: I'm not bashing MS - Windows (the OS) works fine for me, I just wish I could say the same for the software I install and use under Windows. Would I be surprised if MS choose to cripple, subvert, or remove XMLHttpRequest? No. But I do expect them to FUD the landscape, and introduce a proprietary .NET "alternative".

Dynamic web pages were just as good a term, and the big thing is that the term existed before AJAX. Then some clueless tech press bought a buzzword and spread AJAX, so that managers could make money off it.

Actually, Jesse James Garrett of Adaptive Path coined the term. Say what you will about Adaptive Path and their self-important website, but clueless they are not.

I don't particularly care how or why the term came into existence, to be honest. What I do care about is meeting my customer's needs. Like it or not, Ajax has entered the collective consciousness of web clients. Bitching and moaning about it will not get you any money, and correcting your clients over such a small issue ("My acronym is better because it's older!") may actually net you less money.

Besides, it's not managers that are making more money with this stuff. At least in my case, it's actual web designers, developers, and their support structure that do it. Given the recent popularity of small teams handling web development, a unified and well-publicised set of terms means we have everything to gain by falling in line.

The point is that this is not new, but based on hype from Gmail it's been rebranded to appear as new, and people are buying into it.

So what? Lots of things are like that. DHTML may be more literal, but I fail to see where you get it as more or less descriptive. Both are greek to clients, and you can find books about "DHTML" starting as early as 1999, detailing techniques that are neither platform generic nor terribly useful compared to today's techniques.

Ajax means Web2.0 means whatever-term-they-use-next-week means Better Web Apps and leaving behind legacy browsers. I'm all for it, whatever people want to call it.

AJAX Special Hazard Precautions

Anyone who tries to tell you that AJAX is a " new approach to web applications" is just rebranding old technology and hyping buzzwords, not engineering software in the real world. Because of browser and DHTML incompatibilities and limitiations, AJAX is like cocaine: it seems glamorous until you actually start using it, then the unintended consequences totally fuck you up.

Special Hazard Precautions for AJAX:

INGESTION: NAUSEA, VOMITING, AND DIARRHEA. EYES: EYE IRRITANT UPON DIRECT CONTACT. SKIN: MAY CAUSE SKIN IRRITATION UPON PROLONGED CONTACT. INHALATION: NONE UNDER NORMAL USE. PROLONGED INHALATION BY UNORTHODOX USE (NON-WETTED) OR ABUSE (SNIFFING) COULD PRODUCE LUNG DISEASE (SILICOSIS). N/K

Emergency/First Aid Proc: INGEST: IF EATEN/DRUNK--YOU MAY THROW UP. DRINK SIPS OF WATER/MILK. IF VOMIT CONTINUES, CALL POISON CTR/DR. EYES: IRRIT. FLUSH W/WATER 15 MIN. IF IRRIT PERSISTS, CALL POISON CTR/DR. SKIN: IRRIT. REMOVE WET CLOTHES. FLUSH W/WARM WATER 15 MIN. IF IRRIT PERSISTS, CALL DR/POISON CTR. INHAL: IF INHALED, MAY COUGH. TAKE SLOW DEEP BREATHS OF FRESH AIR, SIP WATER. IF COUGH PERSISTS, CALL DR/POISON CTR.

Here's the entire Ajax information sheet, with more warnings and hazard precautions.

-Don

ATLAS is Microsoft's attempt to compete for some of the attention AJAX is receiving by integrating AJAX calls into .NET code.

Here's the history for AJAX:

1. Microsoft creates Outlook Web Access and uses iframes to transfer data back and forth without having to refresh
2. In an attempt to make OWA better, the Outlook team develops an ActiveX control (called XMLHTTP) that can be called to send and receive data without refreshing. The ActiveX control is then integrated into IE.
3. To offer support for what would eventually be called AJAX, Opera, Netscape, Mozilla, Safari, etc. build in support for an object called the XMLHTTPRequest.
4. As browser support spread, web developers began using the XMLHTTPRequest and Microsoft's XMLHTTP ActiveX control in conjunction with other Javascript capabilities to develop speedy, applications, most notably Google Suggest, GMail and Google Maps
5. Jesse James Garrett and the rest of the crew at Adaptive Path http://www.adaptivepath.com/publications/essays/ar chives/000385.php decided to call the method AJAX (Asynchronous Javascript and XML), popularizing the technique as well as screwing it over with a gay name
6. A lot of people(like me) think they're cool 'cause they don't have to refresh their page to send and receive data.
7. Microsoft pops back into the game in an attempt to integrate AJAX techniques into .NET web applications. Good idea, but it's a little late. They should have started development about a year ago.

It's spelled e-c-m-a-s-c-r-i-p-t, or even better, d-h-t-m-l.

And I agree-- 'ajax' is a marketing term. Even those guy who coined the phrase admitted it (see the Q/A at the bottom).

The AJAX acronym was born on Feb. 18, 2005, when it first appeared in a paper titled "Ajax: A New Approach to Web Applications", which was written by Jesse James Garrett, a founder of Web consultancy Adaptive Path LLC. The term has generated a lot of buzz among developers and bloggers so far this year, but it's only the name that's new.

If you want to be more specific --Adaptive Path, specifically by Jesse James Garrett:

http://www.adaptivepath.com/publications/essays/ar chives/000385.php
(it's not worth linking to, and giving them hits for it, though)

And I agree -- the term right up there with 'blog' as terms that need to go. (the only good thing about the term 'blog' is that it's close to 'bog', which seems to suggest the contents of them)

But this doesn't make sense: systems that people call "Ajax" don't even use XML. There's no particular reason for them to use it, either. Saying you throw on the 'x' because you use "XMLHttpRequest" is ridiculous too, considering that XMLHttpRequest is misnamed -- it might as well just be HttpRequest.

Furthermore, you're coming up with justifications for the 'X' after the fact -- which is silly. The guy who came up with the term explains his whole irritating thought process. So if you wnat to know where the 'X' came from (and the retarded acronym, "AJAX"), you just read what he wrote. E.g.

Q. Some of the Google examples you cite don't use XML at all. Do I have to use XML and/or XSLT in an Ajax application?

A. No. XML is the most fully-developed means of getting data in and out of an Ajax client, but there's no reason you couldn't accomplish the same effects using a technology like JavaScript Object Notation or any similar means of structuring data for interchange.

So according to the Ajax master-blaster, you don't need XML to get shit in and out of an "AJAX" application.

Here's a nice piece by a guy who sees things my way, and explains it in detail, step-by-step, with references (OK, he's not totally pissed off the way I am but...) he covers my main points:

* AJAX was invented as a marketing term ("masturbatory acronaming")

* it doesn't have to use XML

This is so going on my nerves I can't tell anyone.
Once again:
As long as JavaScript doesn't behave predictable across Browser DOMs just as CSS has learned by now to behave 95% predictable across plattforms and browsers this whole AJAX thing is NOTHING BUT F*CKING POINTLESS!
The concept of rich clients (what Ajax is all about) in ancient! The only thing that lacks is a cross plattform enviroment that people are willing to use by default in favour of dumb clients.
We've got Java (to difficult for most people - especially for those getting high on Ajax just now), Flash/ActionScript (good but reputation spoiled by same people) and XUL (Firefox/Mozilla only - xulrunner still in the works) but tres cool and a real GUI kit.

So, if you think rich clients are cool, build them in XUL. That's ten bazillion miles ahead of Ajax.

Ajax is nothing but, and I mean absolutely nothing but a marketing hype scheme started by these people. So would you please just ignore it. There are a lot of other much more mature technologies for this that would actually deseve the attention. I mentioned XUL allready, but those countless open source Flash/AS projects out there are also worth a look.

Well, you could simply explain that client-side scripting has matured in modern browsers over the last five years or so, and therefore it's much easier to develop an application that works consistently with modern browsers. Point them to articles about AJAX (such as this one) and explain that it's becoming the rule, rather than the exception. You could point out that most modern web apps (such as almost everything Google develops) use the technologies mentioned above and work well with almost any modern, standards-compliant browser.

It's an example of AJAX. According to the Wikipedia entry on AJAX, this article first coined the term, and the first example it gives is Google Suggest.

http://www.adaptivepath.com/publications/essays/ar chives/000385.php

For your reference, this is how "Ajax" got started. I'd say about 75% of the article is useless, but about 25% is actually useful. The main value of the article can be summed up in two words: Mi>eye candy. Jesse James Garrett is good with graphics.

Ajax: A New Approach to Web Applications

Ajax, which stands for Asynchronous JavaScript and XML, does not necessarily imply Java on the backend. Many Web application frameworks, such as Ruby on Rails, include Ajax helpers. I'm sure many Java Web app frameworks have also added support for it.

Adaptive Path has a nice article introducing Ajax called Ajax: A New Approach to Web Applications.

It's funny, I wrote almost the exact some post as I did above when an article about AJAX was posted here. I think that article linked to this one:
http://www.adaptivepath.com/publications/essays/ar chives/000385.php

Unless I've missed something very fundamental, AJAX too is bells and whistles on top of HTTP. It can work asynchronously in the background while you use the application, which makes a big difference in user experience, but there are still no actual server-initiated requests to the client over the network. It just might (or not) seem that way. If the server-side data is totally unpredictable, as with a chat client or a multi-user game, so that the browser can't precache intelligently, then the AJAX engine has no choice but to keep asking the server, "Any changes?" "Any changes now?" "What about now?" It does this in the background, so it may seem like "server push" to the user, but it's really exactly the situation I described above.

Again with a disclaimer that I might be totally lost here. I think not though.

I am leaning towards things like Ajax for my future web devel. Look at the way 'Google Sugest' or even the spellcheck in Gmail works; it's feels like it's a desktop app, there's no pausing to download a plugin or anything. Bringing more of a desktop response to web apps is going to be where it's at in the future, and I think Ajax is the one to watch.

Sorry, but I see that guy's name everytime there's a Mozilla mention. Oh, and congrats to the developers that are porting to Mozilla; it will be a great day when *any* web user can use all webapps. (personally I see a promising future in AJAX) http://www.adaptivepath.com/publications/essays/ar chives/000385.php

Microsoft created XMLHttpRequest, true, but Adaptive Path came up with the buzzword du jour that is AJAX.

As for the jokes to your comment, I have them covered allready.

This is not about any particular framework. It's about OSS server technology slowly creeping into everyday webapps and beyond. And Firefox/Mozilla Rich Clients in XUL lurking around the corner. Same goes for Flash stuff like Flex or Breeze. MS is fighting those too with new Products like "Office Live Meeting" and such. In MS much fear I sense about that.

Ajax on the other hand is a new buzzword for an ancient technology that usually is called "Doing neat client side stuff with Javascript". Some type A new economy wiseguy over at AdaptivePath brought it up and wrote an essay on rich clients with the assistance of the official web economy bullshit generator. And now - naturally - MS is picking it up. MS is king when it comes to buzzwords (and bullshit) and since they've got it all set up allready they now have a reason to sell more ASP.Crap servers for 10 Bazillon Dollars each.
That's all it is about.

BTW: If you want to check out a wepapp-juggernaught I'd suggest Zope, aka 'What RoR wants to be when it grows up'.

Main weaknesses:

• AJAX - relies on JavaScript/DHTML and so is a security risk and prone to failure due to cross-browser incompatibilities. Won't work if users (wisely or otherwise) turn JavaScript off.
  
• RoR - Same weaknesses as most one-way program generators:
  • Once a site is generated, modifying the generated code slows things to a near-halt since, to do this you must understand the generated Ruby code and internals of the RoR framework,
    
  • There is no round-trip capability (i.e., if you hand-coded changes to a web app, regenerating the app in RoR will wipe out those changes.
    
  
  

Both RoR and AJAX are being pitched to communities not particularly skilled in development. This is unfortunate since only a skilled developer can fully utilize either. Developers who use PHP or Perl will see little new in RoR or AJAX since program generators and frameworks (e.g., MayPole, Catalyst, Class::DBI, CGI::Application, Mason, EmbPerl, etc.) have been available for years in Perl and PHP.

If you have a simple CRUD website that will remain simple, then you might experiment with RoR, (but I would not). I don't recommend AJAX under any circumstances, because of the high maintenance issues.

It's no secret that Apple rumor sites receive a large spike in traffic during events such as the WWDC. I found it interesting that this year, one rumor site is attempting a new approach to reduce their bandwidth consumption Mac Rumors (http://macrumors.com/) has teamed up with Equiknox to deliver update via Javascript and XML (recently coined AJAX http://www.adaptivepath.com/publications/essays/ar chives/000385.php). They believe that this technique, combined with a lightweight http server, will allow them to serve 3300 hits/sec over three servers and to withstand the any severe spike.

If you want, you can read more about this on their technology reviw or on my blog.

For those interested in examples of AJAX apps or interested in building them:

- jpspan.sourceforge.net - PHP/Javascript object serializer
- www.dojotoolkit.org - Rich Web Application toolkit for AJAX apps
- www.feedtagger.com - AJAX based/tagging RSS aggregator
- http://www.adaptivepath.com/publications/essays/ar chives/000385.php - comprehensive outline of AJAX for the beginner

More info about AJAX: http://adaptivepath.com/publications/essays/archiv es/000385.php

Well... Funny thing, I was researching AJAX earlier today. It certainly looks cool, particualry if you read this article: http://www.adaptivepath.com/publications/essays/ar chives/000385.php that's linked in the Wikipedia article and look at the cool stuff that Google's been doing with it. But I'm not convinced that it's far enough along for companies that don't have a ton Phds on staff to jump into... Has anyone here implemeted AJAX?

While I love GMail's functionality, I think it could probably use a UI overhaul if they are going to start adding content blocks or make GMail a portal of any sort.

That said, how cool would it be to have a full AJAX client in Gmail that returned search results from the web/images/video, maintained my open inbox, let me read RSS, watch video clips, IM or IRC... a man can dream...