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?"
not just a new fad (Score:2, Insightful)
Ruby is more likely to be just another fad, AJAX is actually something new. That's not to say someone won't make a better way to do what AJAX does (they probably will), but AJAX is definitely somet
Re:not just a new fad (Score:5, Informative)
But I'll not toss away a mod point to say so, only to have it trashed by some Ajax fanboi in metamod.
1. Ajax does NOT eliminate the round trip between client and server. It just lends the ILLUSION of doing so. Sure it looks cool and wonderful, but requests still have to go to the server, and responses still have to come back over the wire. It only *looks* seamless if you've a broadband connection, which lots of folks still don't.
2. Ajax is NOT new. The technology has been around for a while now. For that matter, it's not even really dependent on XmlHttpRequest - you could do much the same thing with IFRAME elements, at least on your own site.
And Ajax has at least two potential problems in common with frames - poorly-implemented apps don't provide a way to bookmark results - if you use content from another provider, then you're dependent on that being available, and you need to provide a fallback in case they aren't.
I don't object to Ajax, I actually think it's pretty cool. But it's not new, and it doesn't change the way the Web actually works.
(And for anybody who thinks I'm just miffed by the parent's cheap shot at Ruby - I personally don't use or care about Ruby. But it was a cheap shot.)
Thank you Captain Obvious (Score:2)
1. "...essentially eliminates" is what was said. He even went on to say, "A button click just sends the data that's pertinent..." Which is quite ironic as this statement also serves to point out the idiocy of mentioning broadband vs dial-up in your response. As if unessential data in a request/response is actually better for dial-up.
2. The proliferation of Ajax is absolutely new. Just as the proliferation of the Interne
Re:not just a new fad (Score:3, Insightful)
While this is completely true, in many instances, it does significantly reduce the quantity of data transferred. This is especially true in systems like Amazon.com where lots of
Watch out about Ajax (Score:2)
Re:not just a new fad (Score:2)
If he was there in 1999-2001 or so, it's nothing new.
Name 5 ways "AJAX" differs technologically from "DHTML".
Re:not just a new fad (Score:4, Insightful)
But javascript didn't change application architecture other than offloading field validation or allowing table column sorting, image swapping and stuff. AJAX breaks the web document model. A bigger change has come with other applications that use the web (ie http and URIs) outside of the browser - like RSS for instance. and websites that provide an API with xml-rpc or something similar. that's huge. the javascript change is nothing compared to that. web services, I guess they're called.
so to answer the question: is it a fad? yes, in the sense that now is the time to cash in with your 1115 page Bleating with AJAX book with DVD-ROM in the back and your smug mug on the front. yes, in the sense that lots of people will do unnecessary AJAX implementations for entirely selfish resume-style reasons. no, in the sense that the existence of AJAX points out the disconnect between the browser concept and what we want for applications on the net.
Re:not just a new fad (Score:2)
Re:not just a new fad (Score:3, Insightful)
In my opinion, when someone uses "ajax" but with html and javascript only its really dhtml. Now if someone is really using xml documents and doing something original i'll give them credit for the latest fad.
Re:not just a new fad (Score:2)
9 years ago I used hidden IFrame in the browser that communicated with the server and then passed the data back and forward between that hidden frame and the main window. It was exactly like AJAX but instead of XML I was using a simpler, a faster way to transfer data: key-value pairs. And I came up with that on my own too, but I know that others came up with the same (similar) solutions.
Of-course XMLHttpRequest makes the job easier, but actually the XML pa
Re:not just a new fad (Score:3, Informative)
Re:not just a new fad (Score:2)
Re:not just a new fad (Score:2)
Re:not just a new fad (Score:2)
Re:not just a new fad (Score:2)
Re:not just a new fad (Score:2)
Re:not just a new fad (Score:2, Insightful)
Is there something terrible
Re:not just a new fad (Score:2)
Re:not just a new fad (Score:2)
Thank you for your 'attention'.
I second that (Score:2)
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
Re:not just a new fad (Score:2)
There would be two ways to do that: 1)have a program that can parse a standard formatting language, and have a server push a description of the interface out to you or 2)push out a custom program that does the user interface work. It is also possible to have a combination with a standard program that can imbed the custom program.
Wait... Isn't that how the web already functions? A standards compliant web browser parses the language (HTML) and presents a user interface (web page.) Pr
Re:not just a new fad (Score:2)
Re:not just a new fad (Score:2)
It's already here, and called "Flash". Although I'm happy to write Javascript all day long, and have used it for games, windowing systems etc, I see a lot of the AJAX examples and wonder why the authors haven't just used Flash for the job. Admittedly if the app is embedding a lot of HTML content, then it makes sense to use AJAX, but for many other projects, it seems a bi
Flash is too expensive for hobbyists (Score:2)
Because they learned AJAX as a hobby when they didn't have $699.95 plus tax to throw away for a copy of Macromedia Flash [ytmnd.com].
Re:not just a new fad (Score:2)
Re:not just a new fad (Score:2)
AJAX means ease of deployment (Score:2)
That's not what web technologies were meant for. But as soon as XMLHttpRequest was added, that's what they became meant for.
The advantage of AJAX over EXE is that AJAX is an order of magnitude easier to deploy. You don't have to convince your users to install it, and you don't have to hope that your users can
Re:not just a new fad (Score:2)
I said Ruby was more likely to be a fad because it is essentially just another programming language that does more or less the same things as any number of others, and like any language has its advantages and disadvantages. When a new language comes out it's always a fad, but at the end of the day, it's only whether the fad sticks around long enough to take root and get people
What's so special about AJAX? (Score:2, Insightful)
Nothing! The tech for it has been around forever, they just slapped a new name on it.
It IS nice to make web applications that can behave more like desktop applications.
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.
Slashdotted? (Score:4, Informative)
They should have invested in some more bandwidth and better servers to cope with all that AJAX overhead.
Re:The overhead of AJAX. (Score:2, Informative)
Don't forget about AJAX's ability to SAVE you bandwidth. If all you do is strap AJAX on then yeah, it increases bandwidth. If you use it cleverly to say, change the table and only the table instead of reloading all the sidebars as well as teh button to update the table, you can SAVE bandwidth. Or if you use a drop down to avoid wildcard searches, you can save unnecessary queryies from ever being ran. Pre
Re:The overhead of AJAX. (Score:3, Insightful)
You'll especially save the bandwidth formerly used by those customers which left you because they can't bookmark your pages any more.
It's the latest fad (Score:2, Insightful)
Unfortunately, that platform is the web browser, and attempting to run applications in it
Re:It's the latest fad (Score:2)
Java is slow and clunky, if you're talking about the applet form. It's alright to make stuff in, but the fact that it almost universally sits inside a browser window invalidates your point about not using browsers. NeWS and and remote-PC applications, those I can agree with you on. Except the former would, like Linux and Mac, only be adopted by a niche and create even more diver
Re:It's the latest fad (Score:3, Insightful)
All this really seems to indicate is that "we" as a business entity haven't quite figured out with REAL numbers what the most efficient and productive use of computing resources is, yet.
If we knew for a fact that putting "X, Y, and Z" applications on the server, while those doing jobs related to "A, B and C" need to have that computing done on their desktops...
We might stand a chance in hell of becoming a real Engineering disipline someday.
"Best Practices" are nice, but show
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
Re:What ever happened to XUL? (Score:5, Insightful)
Ajax also lacks an installation step. As far as I can tell you always had to download and approve XUL code before it could run, and sometime requires you to reboot your browser.
Availability is always going to trump elegance when it comes to environments.
Re:What ever happened to XUL? (Score:2)
The only detail I'd nitpick is that the installation bit only affects certain classes of application. I'm not sure what makes an app require a
Re:What ever happened to XUL? (Score:3, Insightful)
Re:What ever happened to XUL? (Score:3, Informative)
Re:What ever happened to XUL? (Score:2)
http://www.hevanet.com/acorbin/xul/top.xul [hevanet.com]
Re:What ever happened to XUL? (Score:2)
You always have to download DHTML pages and their associated Javascript and CSS too. You don't have to approve them because the designers of Javascript took the position of limiting what the language could do instead of the approach taken by XUL, Java, .NET and ActiveX which was to require user approval for actions that could potentially be dangerous. As for rebooting
Re:What ever happened to XUL? (Score:2)
if XUL catches on as a means for rich interfaces for remote applications, Microsoft will just write their own implementation
They did, it's called XAML and has about the same rate of adoption as XUL. The problem with both of these languages is that they are markup languages targetted at programmers. Programmers don't want markup languages, they want programming languages. UI Designers want markup languages, but they are not programmers so languages like XUL with its reliance on Javascript to do anything
Re:What ever happened to XUL? (Score:2)
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.
Re:What ever happened to XUL? (Score:2)
Can someone comment on if Mozilla is still pushing for XUL as a way of creating general purpose UIs for the web (maybe they never were?), or have they given up on that in favor of using it strictly for thick client apps such as Firefox?
-Peter
Re:What ever happened to XUL? (Score:2)
The project continues, I know,
Re:What ever happened to XUL? (Score:2)
Yes, the advent of Gmail, and Google Maps changed the landscape. It proved that using XmlHttpRequest and Javascript is a practical and cross browser way for rich applications.
XUL would have been better since the front end is not as "active" as Javascript.
There is something called XULRunner that is supposed to be a standalone application for XUL front ends, and not tied to a browser.
Re:What ever happened to XUL? (Score:2)
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.
I'd call it a Cognitive Avalanche (Score:5, Informative)
The ideas are as follows:
None of these ideas were really important enough to push through to the web developer consiousness and have just kind of quietly developing while no one was noticing- Then some dude calls this stuff AJAX and BAM! the web 2-dot-whatever avalanche begins in earnest.
Re:I'd call it a Cognitive Avalanche (Score:5, Funny)
AJAX Javascript is actually quite powerful look at their source code make your program do something flashy isn't as slow as it actually is browsers have this thing called DOM Standard web forms web bad idea data quietly developing AJAX.
Re:I'd call it a Cognitive Avalanche (Score:5, Funny)
Separate each of them, too. Small humans are kind of primitive; slower, tedious documents -- better idea. BAM!
I think he's conveying instructions on how to teach children: One-on-one teaching, using simple and straightforward teaching materials.
Re:I'd call it a Cognitive Avalanche (Score:2)
Re:I'd call it a Cognitive Avalanche (Score:2)
And then hit them. BAM!
Also happening gradually over the last few years.. (Score:2)
Like many of the other people weighing in, I'd developed web pages with features basically amounting to AJAX years ago. The problem was, especially if you were developing a commercial website, is that there'd still be a decent-sized chunk of people using old-ass browsers that didn't support JavaScript (or who had turned it off.)
Most companies aren't willing to flip even 5-10% (or
Re:I'd call it a Cognitive Avalanche (Score:2)
Serving up documents is not a bad idea. Taking data that is not a document, mangling it into a document and serving it up is a bad idea. Round peg in square hole, and all that.
Re:I'd call it a Cognitive Avalanche (Score:2)
If you asynchronously fetch data (ala XML) and format it onto the screen as a document with Javascript using AJAX this is clearly a danger. But "serve up data, not documents" is definitely a philosphy behind AJAX.
Re:I'd call it a Cognitive Avalanche (Score:2)
Well, the problem with JavaScript was never that it is not powerfull enough (although before DOM it indeed was much less powerfull). The problem always was the security risks. And those still exist. Especially with XmlHttpRequest!
I strongly disagree! I don't want to be dependent on an internet connection when I access my da
Re:I'd call it a Cognitive Avalanche (Score:2)
Please don't. Google are good at server-side stuff, good at user-interfaces, and good at picking out the best mix of unusual features. They suck at client-side web development. GMail is great, yes, but that's because of the features and because they chose to use XMLHttpRequest - not because of the actual quality of their code. If you learn from Google's code, you'll learn wrong. I
Not a fad (Score:5, Insightful)
Slashdot's new comment system uses AJAX to make my Slashdot experience better. They're not done with it yet, but what they've got so far makes it easier to browse Slashdot. The link to read the rest of a very long truncated comment now loads the rest of the comment inline into the page, instead of reloading the entire page like it used to; I can read replies without opening the links in a new tab and switching back and forth like I used to, I can even change my thresholds without reloading. Sometimes I like to open several articles on my laptop and read them when I'm offline; that works better now. Next will be a more convenient way to moderate, and a better way to write replies.
Will AJAX go away? Sure, after a better technology comes along. But until then, AJAX is genuinely useful.
Re:Not a fad (Score:2)
but... the current tools for ajax lack the common patterns of solid software development systems. mvc for one. with a traditional mvc framework (struts, turbine, whatever) it's very easy to tie an html data item to a back end data store. it's even fairly simple to tie an entire page of data (view/model) to a backend object store (also known as rdbms) and have the "business logic" or controler handle the flow of the applic
Re:that box (Score:2)
I agree that having it reappear all the time is annoying. They should make it stay gone when you close it, then have an obvious way to show it again when
Re:that box (Score:2)
Re:that box (Score:2)
Re:Not a fad (Score:2)
I can see how it would be annoying on dialup, because it loads all the comments on the page (truncating the really long ones) right away, thus making the whole page take much longer to load.
(I read at -1, and I have to adjust the threshold for each thread? Fcuk that!).
Wait a minute, what? You read at -1, does that mean you always see every comment in its entirity and just manually scroll past
AJAX/Remote Scripting Hype (Score:5, Insightful)
The AJAX hype is like the DHTML craze all over again. IMO if you can't create a site using remote scripting without suppressing the urge to advertise to the world that you're doing so, chances are you're abusing the technology. Why should your user base care what the hell technology you're using? It should just work.
Re:AJAX/Remote Scripting Hype (Score:2)
Spot on. The coolest apps are those that *don't* waste the user's time by singing and dancing and shouting, "Look at me! I'm a cool app!"
Re:AJAX/Remote Scripting Hype (Score:2)
Isn't it obvious? (Score:5, Funny)
Re:Isn't it obvious? (Score:2, Funny)
Re:Isn't it obvious? (Score:2)
Stronger than dirt!!! (Score:2)
What's in a name? (Score:4, Insightful)
Re:What's in a name? (Score:2)
You mistake synchronicity for causation. The term AJAX was coined when the first very-widely-used "cool app" to use the technique (Google Maps) was noticed by the online public. Many dozens of other organisations were already developing their "cool apps" using this technique before Google Maps was released, and much
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:"All-in-one" is the wrong way to do things. (Score:2)
From a technical standpoint, I understand and agree with what you're saying. From a human standpoint, requiring multiple applications to be used at once to accomplish one task decreases usability and increases complexity. Considering that lots of people try to do more than one thing at once on a computer, for anyone who's not a UNIX guru (and there's a fai
Re:"All-in-one" is the wrong way to do things. (Score:2)
Deja Vu all over again (Score:3, Insightful)
I see Ajax-based applications as being very reminiscent of the what used to be called "full-duplex" applications. Unix, because it was based on using teletypes for I/O to the user, and because teletypes were inherently full-duplex, seemed much more interactive, at least with some applications. Nothing quite like Ajax, but a step in that direction. Conventional main-frame apps, based on either half-duplex (I type, then I hit carriage return, and the keyboard locks until the system responds) or electronic versions of that (such as with the famous 3270 displays, which would lose characters if you typed when the system wrote to the screen), were much more
So, it seems to me that, from the user's viewpoint, Ajax can allow the app builder to effectively decouple user input and system output, and make the whole "flow" between system and user be much more continuous, and less synchronized. Another way of seeing this is thinking of an overseas phone call in the days of poor channel allocators, which really made it necessary to stop talking when the other person started, or neither of you would hear the other. Nothing at all like a really engaged, face-to-face, conversation.
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:Google is Evil (Score:2)
Re:Google is Evil (Score:2)
Re:Google is Evil (Score:2)
I'm not sure of the cosmic significance, but if your browser doesn't support Ajax, Google presents the submenu on the main page where you (and I) want it. Perhaps this is a subtle warning from God that she disapproves of AJAX and will eventually smite those who embrace it mightily.
Re:Google is Evil (Score:2)
This is whats so special (Score:4, Funny)
The Calcuim carbonate, sodium carbonate, anionic surfactants, bleach, the quailty control agents, fragrance, and the color!
Ajax Security (Score:2)
http://www.cgisecurity.com/ajax/ [cgisecurity.com]
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.
Arg, they have no idea (Score:3, Informative)
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.
The evolution of web fads... (Score:2, Insightful)
Answer: When people first used them, they way over-used them, but then they just kinda sank into the mix. In time they all became useful, but in small doses. AJAX is no different. For a great example, see finance.google.com [google.com].
Probably a fucking a botnet (Score:3, Funny)
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.
Re:What's so Stupid About Ajax! (Score:2)
Ajax is no different to any other kind of JavaScript - if you know what you are doing, there's no reason it should cause problems for the blind or people without JavaScript. You have formed this opinion because lots of people who don't know what they are doing are using Ajax, not because Ajax inherently has this problem.
Re:What's so Stupid About Ajax! (Score:2)
So if I want to build a dynamic query, which is basically a decision tree, using select menus.... and pull the info from a db... I have to load up all the possible combinations of select menus which could be 9*9*9 (9 options with 9 2nd options and 9 3rd options) and then HIDE all but 3 of the menus?
Or maybe I should reload the page each time someone makes a selection which since it's being built from a db means no cacheing and thus there will be a refresh of the rest of the page?
Thank Goodness for NoScript (Score:5, Informative)
These AJAX sites expect you to have JavsScript enabled, before they will work at all, and this is where they sneak in tracking crap like Google Analytics, Tacoda, etc. NoScript lets me see the sources of the scripts in each page, and whitelist only the ones required to get the site to work. I regularly see tracking scripts that are not declared, that have nothing to do with the service provided by the site.
Slashdot is embedding Tacoda scripts in every page: have a read of their privacy policy [tacoda.com] for details of what they admit to collecting and selling back to OSTG. If you examine the source code of a Slashdot page, get the script URL and open it, you can how see the script is obfuscated, it generates another script as it runs. Why are they hiding what they do? Why does Slashdot collaborate with these bloodsucking bottomfeeders? How much are Slashdot reader eyeballs worth?
new and shiny embraced (Score:2)
The Name is spreading the Ajax Wildfire (Score:2)
Re:I hate AJAX.... (Score:2)
I haven't got a clue what you're talking about.
Now if you'll excuse me, I have a chicken to sacrifice.