AJAX sucks?

[cgm225]

So I read Rasmus' 30 second AJAX Tutorial, and for the first time I felt like I really understood AJAX.  However, then I read Why Ajax Sucks and AJAX and the Road to Bad Web Sites, and now I don't know if there is any reason I should use AJAX for my small site.

 

What are your thoughts on AJAX, and are there any good reasons to use AJAX on a small personal site?  If so, for what?

 

[i am looking for opinions, not technical help; therefore, I put this thread in the "Miscellaneous" forum; please move if inappropriate location.]

[The Little Guy]

I feel AJAX is good if you want to save bandwidth, or you have a large size page that takes a long time to reload, especially for users on a 56k.

 

Another reason to use AJAX is if you want to and a "Newer" way to add functionality to your site.

[.josh]

From "Why Ajax Sucks"

Ajax breaks the unified model of the Web and introduce a new way of looking at data that has not been well integrated into the other aspects of the Web. With ajax, the user's view of information on the screen is now determined by a sequence of navigation actions rather than a single navigation action.

 

Navigation does not work with ajax since the unit of navigation is different from the unit of view. If users create a bookmark in their browser they may not get the same view back when they follow the bookmark at a later date since the bookmark doesn't include a representation of the state of the content on the page.

 

Even worse, URLs stop working: the addressing information shown at the top of the browser no longer constitutes a complete specification of the information shown in the window. If an author copies the URL in order to include it as a hypertext anchor in one of his or her own pages then that anchor will not lead readers to the desired view but to the initial state of the page. Similarly, if a user decides to send an email message to a friend with the recommendation to check out a page, then copying the URL from the browser will not work if ajax is used since the URL points to the initial page and not to the current view (with the information of interest to the friend). Given that social filtering is one of the most powerful mechanisms for information discovery on the Internet, it is an utter disaster to disable the URL as an addressing mechanism.

 

This can easily be solved by creating a unique id based on what is being "tweaked" on the page.  For instance, if I am customizing a computer at some online store, there are several options for several components. Ram options, HD options, monitor options, processor options, etc... Each component can be represented by a value and those values can be stored in a specific position in a string.  I (as the store) can then take that string and parse it and rebuild exactly what was selected.  

 

My point is, I do not think it's a failure on AJAX's part that people cannot send a link of what exactly they are looking at, to other people.  I think it's a failure on the programmer's/designer's part to implement a system of data persistence.  

 

The November 2005 browser statistics from Interse show the following distribution of browser usage:

 

   * Ajax Compatible Browsers: 78%

   * Speech Browsers: 2%

   * Mobile Browsers: 11% of users

   * Other browsers or earlier versions: 10% of users

 

Percentages sum to 101% due to rounding. Thus, 13% of users would not even be able to use a site with ajax. Sure, it is possible in principle to use graceful degradation to serve alternate content to these users, but most designers don't bother designing two versions of their pages and reserve the no script option for a "helpful" link to the download site for an ajax-supporting browser version.

 

This is bullshit.  AJAX is a javascript method.  It is nothing special or different or separate from something. It is javascript.  If someone cannot use ajax, it is because they either don't have a browser that handles javascript (virtually non-existent) or else they have javascript disabled.   And again, even the author admits that the real problem is laziness on the designer's part to accommodate those situations.

 

78% of users are using Ajax compatible browsers. A combination which has one of the worst usability problems to be seen on the Web so far: the BACK button in the browser simply didn't work with ajax sites. The BACK feature is an absolutely essential safety net that gives users the confidence to navigate freely in the knowledge that they can always get back to firm ground. We have known from some of the earliest studies of user navigation behaviorthat BACK is the second-most used navigation feature in Web browsers (after the simple "click on a link to follow it" action). Thus, breaking the BACK button is no less than a usability catastrophe.

 

This argument is so weaksauce I don't even want to acknowledge it.  The BACK button continues to work exactly as it was made to work: it takes you back to the previously clicked url link.  If you are having issues of going "back" to a previous decision/path/etc... within a specific page, then yet again, that's a design flaw of that page.

 

Many browsers cannot print ajax pages appropriately. Of course, most browsers don't print anything really well, but at least regular pages normally print in full. With ajax, it is common to have the print command result in the printing of a single column. Printing the full page is difficult with ajax layout: should only the visible part of the content be printed or should the content be allowed to expand and take up more room than it does on the screen?

 

Once again I call bullshit.  Printing difficulties are a result of a failure on the designer's part, not on AJAX.  A good design will involve being able to navigate to a printable version of a page in the first place.   "Should only the visible part be printed or all of it? (paraphrased)"   That is irrelevant to AJAX.  Printing should be done in a WYSIWYG manner.  If a page uses ajax to dynamically show/hide data, and you have something hidden then it should not print that hidden part.  If you get upset because it's hidden, then click the damn button that shows it.   If you want to argue that there's a hundred buttons and you shouldn't have to click them all to get a printout, then take it up with the designer.  He should have a "toggle all" button somewhere, or something.  The point is, that's a user or else design problem.

 

The original release of HTML was simple enough that many people learned it without any problems. Ajax is another matter, though. Newsgroups like ajax.web.technology are filled with questions from Web authors who desperately need to know why their ajax doesn't work as intended. Ajax is currently so hard to learn that many page authors write buggy code.

 

Yet another stupid argument, because this can be argued for anything beyond simple HTML, be it dhtml, javascript (even thought ajax IS javascript), php, asp, cgi, etc.. etc.. in short, anything that makes a webpage dynamic.  And that's why it's a stupid argument.  It's singling out ajax, when it's a "problem" for virtually everything.  That statement just reeks of "I should be able to make webpages do whatever I want to without having to actually learn anything.  Who do I talk to for that magic wand?"  If we subscribed to that logic, we'd still be riding bikes instead of driving cars, because driving a car is harder and it's harder to make a car and fix a car and etc...

 

Search engines have trouble with ajax since they don't know what page states to include as navigation units in their index.

 

Once again, that's a failure on the designer's part.  lrn2SEO.  

 

Many websites that offer users a choice between regular and ajax versions have found that most users prefer ajax-free designs.

 

Proof?  I don't see any proof of that.  Where's the proof?  There is an obvious typo in that statement.  Don't worry, I'll fix it:

 

"If given the choice between regular and ajax versions,  I prefer ajax-free designs...and since I prefer it, everybody else must prefer it as well."  

 

There you go Mr. Author, got that all fixed up for you. No worries.

 

When It's OK to Use Ajax

 

If you are working in a Web2.0 company that needs to provide evidence of their technical expertise in order to gain new clients.

 

What the hell?  This whole time he's been arguing that AJAX breaks the internet experience, is flawed in 10 million ways, and most of the time is not even correctly implemented.  And yet he says it's okay to use it as proof of one's technical expertise?  OH TEH IRONIES.

 

In the long term, we will need a richer model for hypertext nodes on the Web than can be supported by frames. For example, composite nodes, typed nodes, hierarchical nesting of nodes, nodes with different views, and nodes with actions that influence other nodes are all ideas that have been explored in hypertext research. It will be important to retain the positive attributes of the Web as we move toward these richer information structures.

 

Gee.  I mean, I'm no expert, but doesn't that sound just like AJAX (or javascript in general)?

 

Fail.

 

 

[.josh]

...and from "AJAX and the road to bad websites":

 

Again, all those arguments against AJAX are beefs with design flaws.  The author of that article even admits it at the end of his article:

 

Then again, my complaints may only stem from the fact that most implementations are done by people who simply cannot do it right. It also appears that the number who can do it right is minuscule.

 

That pretty much sums up my previous post. 

[Liquid Fire]

i did not read the article but AJAX does not suck, developer who use it might tho.  There is a time a place to use AJAX and a time and place not to use AJAX and if you use it in the wrong place and in the wrong way they yes AJAX would sucks there.  When AJAX is used properly, it is extremely nice.

 

About about only 78% of people having AJAX enabled browsers.  last time i check W3C javascript enabled stats, it was around 5-6% had it disabled(and i believe all you need is javascript to be able to use AJAX).

[Zane]

I believe CV summed up every bit of an opinion I can muster up on this.

 

Any kind of development, whether it be AJAX, PHP, VB, etc.....if the developer sucks....then the program sucks

there's no reason to judge a ..... language by it's....speaker.  For lack of a better expression.

 

 

It's all about making something work for You, get your imagination out there and if you're imagination doesn't SUCK it may draw a crowd and hopefully some money.

 

 

Of course you're not going to be enthused by AJAX after reading an article about how much it sucks.  That's why they wrote it.

 

I myself like AJAX, I still haven't found a way to use it to it's full potential though.

 

 

[Daniel0]

Blame the tool if you can't use it properly. Right...

 

Seriously, nails and hammers are completely useless; I always hit my thumb instead of the nail (or you could say I hit the wrong nail).

[ober]

IMO, there is almost zero reason to use AJAX on a personal site.  AJAX should be reserved for applications where the functionality gain outweighs the need to reload the entire page.

[.josh]

I will agree that in many cases it's overkill and not necessary but that's not the same as saying it's bad, as those articles were asserting.

[ober]

Agreed.  AJAX and it's competing technologies are great when utilized appropriately.

[Daniel0]

Except ActiveX. It sucks always.

[DarkWater]

Except ActiveX. It sucks always.

 

I second that.

[corbin]

I hate when new web designers are like "OMG AJAX OWNZORS MI USE EVERYWARE" and use AJAX in situations where it's entirely unneeded, as in it doesn't even add to the user experience.

[DarkWater]

I hate when new web designers are like "OMG AJAX OWNZORS MI USE EVERYWARE" and use AJAX in situations where it's entirely unneeded, as in it doesn't even add to the user experience.

 

I kinda lol'd at the (absolutely true) quote.

[obsidian]

Agreed.  AJAX and it's competing technologies are great when utilized appropriately.

 

Therein lies the key, I believe. Rather than rehashing all of what was previously stated, keep in mind that, as should be observed with any technologies, you must have a reason to use it and then decide on the implementation. It is entirely wasteful to simply use a technology to say you have used it. Come up with a project that could be better suited with the use of AJAX, implement it properly (and minimally), and you should have a much better understanding of how it works. In my opinion, one of the ways to tell an experienced, well rounded developer is his ability to decide when not to use a technology... this is one of the reasons that Flash still has a bad rep in many cases: people went overkill and used it in situations where it has no business being used.

[corbin]

One of my pet peeves is when people use Flash for something JavaScript could easily do.  In like 4 lines of code.  Like count downs.

[Liquid Fire]

One of my pet peeves is when people use Flash for something JavaScript could easily do.  In like 4 lines of code.  Like count downs.

I know a few people who believe that you should always use flash for anything that does animation and never javascript for that.

[.josh]

One of my pet peeves is when people use Flash for something JavaScript could easily do.  In like 4 lines of code.  Like count downs.

 

I don't necessarily think it's fair to say something like that.  That just boils down to the "Which is the better language, x or y?" argument. 

[GingerRobot]

That just boils down to the "Which is the better language, x or y?" argument. 

 

Not sure I agree - i think the question of "which is the better language,x or y for this particular application?" is a valid question.

[.josh]

Okay well I think what I really meant to say was this: just because language x does some particular thing better than language y, doesn't mean you need to go learn x, if you already know language y.  I'm personally not interested in mixing and matching a hundred different languages to get the job done, simply because the "best" way is spread out like that.  Is that the case here?  We don't really know. 

[GingerRobot]

Okay well I think what I really meant to say was this: just because language x does some particular thing better than language y, doesn't mean you need to go learn x, if you already know language y.

 

Agreed. It would depend on many things including the extent to which language x is better suited than y, whether or not it's just a matter of opinion, the difficulty of learning language x and the future opportunities for using language x. 

[ardyandkari]

Okay well I think what I really meant to say was this: just because language x does some particular thing better than language y, doesn't mean you need to go learn x, if you already know language y.  I'm personally not interested in mixing and matching a hundred different languages to get the job done, simply because the "best" way is spread out like that.  Is that the case here?  We don't really know. 

 

then again, if you know flash, but know that javascript is better for this app, a lot of times you can find something on the net with good instructions as to how to set up.

 

http://dynamicdrive.com/ has all kinds of scripts in javascript/dhtml etc...free!  you just leave the credit (i have only found credit in the commented code, so that isnt an issue of seeing it on the site.)

[corbin]

I've seen tons of horrible JavaScript snippets all over the internet.  I mean HORRIBLE.

 

 

Edit: That wasn't a direct jab at dynamicdrive.  Just meant to say there's a lot of garbage out there, so people who don't know JS should be careful.

[obsidian]

I've seen tons of horrible JavaScript snippets all over the internet.  I mean HORRIBLE.

 

 

Edit: That wasn't a direct jab at dynamicdrive.  Just meant to say there's a lot of garbage out there, so people who don't know JS should be careful.

 

Definitely agree. In addition, I would take it a step further and say that I have seen many horrible scripts offered on tutorial and other seemingly "professional" coding sites. Many people who are developers do not take the time to learn JavaScript well, and as with any language, just settling for getting something to work is not always the best approach. Read and learn the best way to handle it and make sure that the code base is solid.

[CroNiX]

There are also ajax history managers that allow you to use the browser back button properly and bookmark pages properly.  http://digitarald.de/projects/history-manager/