What's Spreading "the AJAX Wildfire"? 192
An anonymous reader writes "AJAXWorld Magazine is running an article entitled "What's So Special About AJAX?" in which the majority of the contributors agree among themselves that AJAX "heralds a new, global sense of what the web can be and what the web can do, in ways that are so different but so much better than what we have been used to." While many of those the magazine consulted adduced technical reasons for the spread what one of them, Rich Internet Application pioneer Coach Wei, calls "the AJAX wildfire," only two mention how human nature — including that of software developers — is, well, notoriously susceptible to the latest fad. Which side would you agree with?"
Re:What's so special about AJAX? (Score:5, Interesting)
To be fair, while Microsoft introduced the XMLHTTP object in 1999, other browsers didn't implement a similar interface until 2002 or later (2002 being the first implementation of XMLHttpRequest in Mozilla). So if your definition is of "forever" is "the last four years" then this has been aroud forever. (Note: I'm ignoring hidden iframe solutions that really have been around "forever", where "forever" is defined as "since rich web browsers have been around, such as IE4 and Netscape 4".)
I do agree that "AJAX" is just a flashy name for an already-existing technology, and any good web developer would've already been using the technology in appropriate places prior to the name change. However, "AJAX" does put a fancy name on the technology, and while it certainly can be overused it's not really a bad thing for the technique to get more publicity. "AJAX" as a fad will eventually die down just like "enterprise", "push", etc have in the past. The technology behind it won't, and will continue to be used where appropriate long after the Web 2.0 bubble has burst.
What ever happened to XUL? (Score:5, Interesting)
How is this on topic? Well, it seems like AJAX is delivering a lot of the rich UI stuff that XUL was supposed to, but in a slightly less elegant way (from my peripheral understanding of both technologies). Am I fundamentally misunderstanding something here, or is AJAX a popular but pale immitation of what XUL was supposed to be?
-Peter
AJAX is putting the D into DHTML (Score:5, Interesting)
Now that we finally see dynamic HTML happen (even if the name has changed), how could we not expect the hype about the real thing to at least match the past hype about the early attempts?
Sure the name is stupid, but who cares! We do need some good hype to get standardization of something like that xml request object done and a catchy name can only help.
If it's a wildfire then, get me some matches, stat (Score:5, Interesting)
Now obviously, that's the programmers fault...webmail should never throw anything away regardless of the user clicking Back and Forward on their browser. And I think that's the theory behind the AJAX effect. Really, back and forward are supposed to be the last things I'll ever hit. In fact, Google Maps I believe has to go through considerable kludges to even have entries show up in the Back and Forward browser list...and I can tell you there are plenty of times I wish I could go "Back" to my previous map location but instead, got taken back to the original empty Direction page I started at. So, if AJAX is done right...everything I ever need to click is right there. And that's what have been valuable since Windows was born. A poorly written web application/interface is like having to use Calc.exe Notepad.exe Paint.exe and CharMap.exe to make a document instead of WinWord.exe doing it all in one place.
In fact, I'm a little upset the whole stampede behind AJAX apparently caught so many developers and programmers napping. I've been hiring PHP/MySQL programmer for years now but, I start asking questions like... can't we have it so when someone clicks this header it just drops down a propigated list of choices instead of having to pop them up in a window or regenerate the page? And they stare at me like I'm asking for the moon or wanting an entire database of 400 items preloaded on the page before it renders. The guys with "AJAX" on their resume are...well they apparently know what that buzzword is worth and have their hands full writing the next Flicr or Digg or whatever.
And I'm one of them. I've had an idea for a web-based application but...because it involves just so darn much data, I've been having it developed as a template/macroset in Word because I can piggyback on the already present features like AutoText and Toolbars to provide an interface and packaged output. Now, I'm excited that I can have something just as dynamic and immediately accessible, but available on any platform and any location and without relying on software I don't control (I've already found two critical bugs in AutoText that Microsoft has admitted are bugs present since Word 2000, cannot be fixed by any option/registry setting, and will hopefully be fixed in the next version but possibly the one after that...oh gee thanks). So I want to start my own wildfire by creating something that would make a wonderful application, but have ability to distribute that application to thousands and tens of thousands of users as easily as sharing a link. That's amazing. That's why it's a wildfire. I just wish the store wasn't sold out of all the matches.
- JoeShmoe
.
Re:not just a new fad (Score:5, Interesting)
This is the classic progression of technology. A tool is being used for something it was not meant to, while technically feasable it is distasteful. This technology will be refined until it becomes apparent that a new framework is needed.
I see the most likely scenario as ajax being replaced by something designed to do the job far easier which is basically: Networkable GUI's
Google is Evil (Score:5, Interesting)
Google drifts evil every once in a while, and then to their credit they drift back, but currently they are drifting evil.
Okay, so, it's a little off-topic, but since there was no thread about Google's big change this week I needed to vent. (They also switched dictionary.com to answers.com which is more spam-mey and popup-ey).
Re:What ever happened to XUL? (Score:5, Interesting)
Mind what I'm saying; I'm not saying real menus or a real tree widget isn't useful; I'm saying they haven't made it worth cutting out the IE chunk of your audience. I'd love to see the W3C standardize a tree widget into (X)HTML, but that seems unlikely right now.
The behavior of XUL is specified with Javascript, and that's indistinguishable from how conventional HTML pages already have the full power of Javascript.
So, the only part of the traditional XUL platform left is XBL, which A: doesn't appeal to your average "cowboy" coder anyhow because they can fully understand the costs of using XBL but can't see the benefits and B: Has basically missed the window where it could impact anything because it's been buggy as all hell for a long time, to the point where even if they fix it a lot of us wouldn't notice. Basically, it works for writing a browser but my experience [jerf.org] is that the minute you step outside of that domain, all hell breaks loose. Granted, that experience is from 2005, but it didn't materially differ from my experience in 2000 (no typo).
If you get down to the real causes, I think the basic problem with XUL/XBL etc. is that while it had promise in theory, it brought a lot of baggage into developing even simple applications (you need to understand XML, because XUL and XBL are based on it, plus you need to understand XUL and XBL itself, then you have to understand Javascript, DOM, and to really use XUL/XBL you also need RDF which is another can of worms entirely, and finally it was buggy and implemented just enough to write Mozilla in it and not much more), but it really doesn't offer a significant advantage over, well, much of anything else, really. Having tried to make XUL actually do something several times now, I'd rather develop in Visual Basic. Pre-dot-Net. And I say that as someone who really doesn't like Visual Basic. Basically, six+ years after starting to develop this stack and the advantages are still theoretical; the only existing apps, as near as I can tell, require full-time teams to fix up the Mozilla core in conjunction with the team actually writing the app, and that's just stupid when you've got so many great choices already available to you, from Visual Basic all the way to my preferred Python+wxWidgets (or PyGTK, or PyQt, or heck, even the Tk interface). By the time you get to the point where you are skilled enough programmer to master the stack of Mozilla technologies, you are aware of better choices.
Including just sucking it up and going pure HTML, which is what I ended up doing, writing my own XBL-esque technology to help me. And I've noticed a number of the Javascript libraries like Dojo share the same basic Widget design as my library, so even the majority of advantages of XBL are available in conventional HTML now with readily available open-source libraries, again, leaving what's left not worth it. (Especially if you count the XBL bugs.)
So, the basic problem with XUL, considered as a whole stack, is that the costs are staggering and the benefits very, very marginal. As a result, it's basically dead; there's never a case where XUL is a better solution than either pure HTML or a real app.
Definite Need, HTML-centricism suuuucks! (Score:4, Interesting)
If we have to rely on JavaScript tricks to get it, then that is fine by me. There may be better ways if we start from scratch, but it takes years to mature such technologies, and JavaScript/DOM is already in every browser.
I don't like fads either (look how I bash OOP, see sig), but this one at least tries to satisfy a big existing need instead of try to sell you on a problem you didn't know you had.
I call it the tail wagging the dog (Score:5, Interesting)
Three years later when Mozilla started supporting off-channel requests they did it in native mode, while Microsoft was still using an ActiveX object. MS had all that time to set a new standard for dynamic web pages and they just sat on it. Finally, somebody comes along and invents a buzzword for it and somehow gets it in everybody's face. A few people write packages to make it a little easier. Now Microsoft is playing catch-up with their own version called Atlas. At least that's a cooler name, but jeez. AJAX is a case of Microsoft dropping their own ball and then showing up late to join the game.
What's so Stupid About Ajax! (Score:4, Interesting)
However, these Ajax yappers completely miss a few points.
Just like 'FLASH' Ajax will have adverse effects if used in a site:
1. Makes it unreadable for the blind or anyone else using a browser that doesn't use a fancy javascript.
2. Makes it less readable or unreadable to google and yahoo search engines.
3. Adds yet another step in the web development pipeline
4. Further supports M$'s "we'll make our own javascript" cause. IE handles AJAX differently then the rest ( big surprise ).
5. Breaks the standard accepted policy of unified pages ( essentially re-introducing frames )
Lastly and most importantly,
AJAX yappers talk about response and app like look and feel. If you encounter one of these people then rest assured that they don't know what good layout design and CSS are!
They more than likely have 5+ things happening on the screen at the same time or have too much information on the screen such that user interaction causes the page to have to be completely reloaded.
With proper layout and CSS you can make a web site or application respond and look just like an Ajax one without having to use Ajax or code up some JavaScript piping. The browser will cache the layout correctly and thus the extra 3k of information that AJAX supporters say they avoid is in fact already avoided.