Ajax Sucks Most of the Time

as in all new directions... by yagu · 2005-12-07 05:03 · Score: 5, Insightful

Up front Disclaimer: I realize the article is "just saying no to Ajax" with constraints. My post here is to the objection I think the article states Ajax problems too harshly.

Reading the article it seems to me:

most of the listed grievances are not unique to AJAX, have been addressed in the past, and are probably soluble for AJAX too. (e.g., how many remember the broken first browser paradigms where there simply was no easy way to get the information from a web page to some printer? It's not perfect today, but it's doable. This problem is ultimately soluble for AJAX too)
AJAX is the (to many) latest and greatest. Many will hold on and gain purchase. Some will bail. I think AJAX or some derivative thereof is here to stay. Like technology before AJAX, there will always be naysayers, and there will always be glitches. For this to justify a "Just Say No to AJAX" philosophy is naive and maybe even misguided.

From the article:

Ajax is currently so hard to learn that many page authors write buggy code.

Huh? So? Is this unique to only Ajax?

Also from the article:

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

When an article wants to rant or complain about a technology, an un-cited and broad statement like this is a huge red flag. It doesn't state what the percentages are, it doesn't state the reasons for preferences. In the middle of an article espousing "no Ajax", this is a non-sequitor. Please expand.

I'm having great fun experimenting with AJAX and am getting interesting new approaches for old solutions improving customer and user experiences. I'm not about to walk away from this until a more thorough trial. So far I'm liking what I'm seeing. Yeah, there are glitches to solve, isn't that kind of what we're here for?

Re:as in all new directions... by CaymanIslandCarpedie · 2005-12-07 05:15 · Score: 5, Informative

It is worth noting this statement at the bottom of the page.

This is a spoof article. Please compare it with the original and you will see how little it has been changed.

That said some of the points are valid, but the article was basically showing how those same things were valid at one point for using frames as well.

--
"reality has a well-known liberal bias" - Steven Colbert
Re:as in all new directions... by the+eric+conspiracy · 2005-12-07 05:18 · Score: 1

My post here is to the objection I think the article states Ajax problems too harshly.

Perhaps, but I think the problem set the author chose to examine is not where the deep and most fundamental problems with Ajax lie.

The basic issue is simple - HTTP isn't a client - server protocol. There are several technologies that try to get around this issue, Java Applets, Flash Remoting and now Ajax. They all have their own set of issues, but the place that the break is in the design decision to try to turn an HTML browser into a rich client. It is always a matter of trying to bolt the fuselage of a 747 onto a balsa glider, it just won't fly and you will always be frustrated by this fact.
Re:as in all new directions... by interiot · 2005-12-07 05:22 · Score: 2, Informative

most of the listed grievances are not unique to AJAX
In fact, they're so non-unique that the HTTP protocol actually specifically points out that method=POST, PUT, and DELETE should not be retried. Also, I can't find the reference, but most browsers won't cache passwords when you go back and then forwards, as a security precaution, and that's basically standard practice. The back button has LONG been broken.
That doesn't mean we should ignore the criticisms of AJAX, but I think the take-home message should more be "be aware that there are these downsides, and web authors should everything they can to minimize those downsides. In some situations, this may mean using a simpler method than AJAX. However, AJAX as a whole is something that is beneficial, rather than harmful."
Re:as in all new directions... by Ian+Wolf · 2005-12-07 05:25 · Score: 4, Insightful

Ajax is currently so hard to learn that many page authors write buggy code.

I swear, I've heard the same argument about PHP, Perl, C, and even the concept of object oriented programming. In every case the person uttering those words was an idiot or simply too entrenched in their chosen language to accept a new way of doing something. It all reminds me of a line from Scott Adams' Dilbert Principle. As best as I can recall it went something like this.

"Every technology has its detractors. I'm sure that somebody once stated that the pointy stick would never replace the fingernail as the fighting man's weapon of choice."

As for my disclaimer, the only thing I know about Ajax is that its not effective as Mr. Clean.

--
"The words of the prophets are written on the Slashdot walls."
Re:as in all new directions... by Anonymous Coward · 2005-12-07 05:32 · Score: 0

Exactly. The author is using many of the same tired arguments that were initially used against frames, flash, embedded java and even in some cases heavy use of java script in webpages: bookmarks don't work exactly right, URL doesn't indicate what's on the page, alternate browser types, etc. etc.

And then in the classic "I don't like change on the internet so I'm going to try to make new technology seem harmful" style, he promptly fills up the rest of the article with the way he feels things 'should be'.

You all remember (well, er, some of you) remember the people that got their panties in a bunch when they came across a website that wasn't lynx compatible right? This is the same thing. There are always goign to be people like this pissing on the posies of the innovators because it doesn't fit into their model of how things 'should be'.

Just because not everybody uses the technology well, doesn't mean that it's cause to reject it.
Re:as in all new directions... by 14erCleaner · 2005-12-07 05:41 · Score: 0, Troll

the article was basically showing how those same things were valid at one point for using frames as well.
Please clue me in, then: do frames no longer suck?

--
Have you read my blog lately?
Re:as in all new directions... by mpcooke3 · 2005-12-07 05:43 · Score: 3, Insightful

That said some of the points are valid, but the article was basically showing how those same things were valid at one point for using frames as well.

For "valid at one point" consider using "always valid".
Re:as in all new directions... by ChrisGilliard · 2005-12-07 05:43 · Score: 1

Right on. Every new technology has these issues. The author probably could have writen a similar article about the internet in the early days.

--
No Sigs!
Re:as in all new directions... by publius_ovidius · 2005-12-07 05:49 · Score: 1, Funny

What the heck do you think you're doing reading the entire thing? This is /. You're supposed to not read it or just read the first couple of paragraphs and then come back here and try and sound like a pundit.

That being said, I fear that many will read that article and take it quite seriously. It always amazes the luddite stances that technologists seem to adopt about their technology.
Re:as in all new directions... by AKAImBatman · 2005-12-07 05:59 · Score: 1

That's not as big of a problem as you're making it out to be. Some types of Mainframes relied on stateless communications years before the web was invented. As long as you can get the data you need when you need it, the protocol doesn't matter. Granted, AJAX is unsuitable for anything that's time senstive and requires data to be pushed immediately (such as a live auction), but those applications are rare and can always be done with a Java or Flash applet.

--
Javascript + Nintendo DSi = DSiCade
Re:as in all new directions... by 2short · 2005-12-07 06:00 · Score: 1

"HTTP isn't a client - server protocol"

Um, yes, actually, that's exactly what HTTP is. The client software everyone has (web browsers) has pretty limited features, and is kind of quirky, which leads to all kinds of pain. But there's notrhing wrong with the protocol. You could easiily write a full featured, robust http client to do whatever you want (and people do). The frustration and problems come in because it would be really cool if you could write apps for a full featured, robust client that everyone already had; and web browsers aren't that client, but they are close enough to fake it in some cases.
Re:as in all new directions... by Anonymous Coward · 2005-12-07 06:03 · Score: 0

Frames only suck on IE because they don't like standards, and for blind-users.
Re:as in all new directions... by fury88 · 2005-12-07 06:20 · Score: 1

How is AJAX difficult to learn? It's like 5 lines of code!!
These people must be getting confused with DHTML, that can get a little more complex.
Re:as in all new directions... by drinkypoo · 2005-12-07 06:20 · Score: 2, Informative

Also, I can't find the reference, but most browsers won't cache passwords when you go back and then forwards,

If you mean HTTP-AUTH, you're wrong here. The auth seems to be stored until the browser is closed. Some implementations, until the tab is closed.

These days most people are doing authentication manually with cookies (although there ARE ways to specify a cryptographically secure exchange with http-auth on modern browsers, it still doesn't integrate into the page as well) and it's all a moot point.

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Re:as in all new directions... by Golias · 2005-12-07 06:24 · Score: 1

The author probably could have writen a similar article about the internet in the early days.

What? You mean like an anti-frames rant?

That's crazy talk! ;)

--
Information wants to be anthropomorphized.
Re:as in all new directions... by diverman · 2005-12-07 06:32 · Score: 5, Insightful

I am glad that you made this statement. The whole time I'm reading the article, I kept thinking that it was basing the vast majority of its argument on false assumptions that AJAX is predominantly being used on content pages. The best use of AJAX, that I see, is with improving user interactivity with a web application. Web applications are becoming more and more of a need, and I think this is where AJAX is gaining the most ground.

The author talks about how "the page" is the basic idea that was behind the Web. Well, I hate to break it to him, but after 12+ years, things have evolved. The notion of the page has long since been an area of limitation with web applications and usability. This is why we've seen the uprising of many technologies in an effort to have more dynamic content interfaces. Users don't like having to wait for a full page load to make a small request within an application. There is complaint about the time it takes. Granted, this is largely a perception thing, but it is the reality of users.

The type of information being presented on the web has gone beyond thesis papers and simple static articles. The information that users are becoming used to is more complex, as the average user's understanding of relational information grows.

Now, the author does make some good points... but mostly these are when using AJAX in "pages". In this respect, I agree that overzealous, and possibly inexperienced web developers have gone overboard. But a good web developer considers the effects their choices have on a user, and they make the choice to go with one advantage over the loss of another. I am conscious that search engines can't necessarily index my content... so what! If I don't want it to be indexable, so be it... they can index the more "content" oriented parts of my sites, and users can then find the "features" and applications that use better technologies. The complaint about printing... please! A best practice is to take length articles and break them up into multiple pages. Ummm.. this has the same problems with printing. He kind of neglects to point that out.

As was stated previously, many of the arguments are presumptuous that the web is all about "pages". I also question the interpretation of his statistics. 1. Old browsers are likely unpatched browsers. With the vulnerabilities and security issues today, compatibility with AJAX is the least of their problems. Upgrade! 2. Mobile browsers have problems with MOST page content. Websites are designed for a minimum of 800x600 these days, if not 1024 wide. Websites still need to provide special pages to serve up content to mobile devices anyway.

So, I know this is a spoof article by the author about a previous article about Frames back in the 90's... but I think he sticks too much to the premise that existed back then, that the web was all about simple content and "pages", without recognizing that the information complexity has evolved, and that "applications" are becoming more and more necessary for usability of the information. Yes, improvements are needed. Yes, back button support should be support (but not required). Also as was said in an earlier post, many of the problems are not an issue with just AJAX, and many are an issue with the lack of understanding of the effects of the choices made when using ANY new technology.

-Alex
Re:as in all new directions... by interiot · 2005-12-07 06:34 · Score: 2

No, not HTTP-AUTH. I thought I was talking about password fields, but I can't remember specifically where I read that at (RFC2616 is hard enough to keep in your head).
Re:as in all new directions... by diverman · 2005-12-07 06:41 · Score: 1

Oops. clicked "Reply" on the wrong post. Meant to reply on one just a little ways down that pointed out the articles focuses on pages and not addressing web applications.
Re:as in all new directions... by Iriel · 2005-12-07 06:44 · Score: 3, Insightful

I think the major point of the article is that AJAX is currently being used (like a lot of upstart web technologies) in many places were it just confuses things more than needed. Give it time, and people will stop using it just for the sake of jumping on the new craze bandwagon and we'll find out where it shines and where it should never go.

Personally, I think it's great for UI tricks and acynchronous form actions (checking for currently used user names, submitting to a shoutbox, and so on). If people think AJAX itself is bad, they should see the comments on Digg to AJAX articles. There are more comments like "If I see one more damn article on this..." than there are dupe notification comments here on Slashdot!

I think this new use of JavaScript has great potential, but the real message of the article can be gleaned in the first few paragraphs: Don't go overkill.

--
Perfecting Discordia
www.stevenvansickle.com
Re:as in all new directions... by sootman · 2005-12-07 06:45 · Score: 2, Funny

"This is a spoof article. Please compare it with the original and you will see how little it has been changed."

He didn't even change the indefinite article in the graphic--"This is a Ajax free site" [emphasis added] :-)

--
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Re:as in all new directions... by osoese · 2005-12-07 07:03 · Score: 1

I used Ajax to handle a large search results page for editing of the returned records and found it easy to use, very realible, cross browser, and stable. So I say bunk to all this....I think its the particular coder. Put your noggin to work bonehead, and engineer another solution if you are having trouble with the first. I find it so reliable that I can edit three records before the page finishes loading (large record reurns)...reliably...and to boot...there are 5000 users hitting my site, so you can't argue its a fluke. The reason there is so much of a buzz about Ajax is because when combined with DHTML you can handle many fundamentals on the UI wishlist, like not having to reload the page for every little thing. Does that mean Ajax is the proper solution for all problems? obviously not. Use a proper systems approach and use Ajax where it is appropriate, however and you will be a better web developer for it.
Re:as in all new directions... by Amouth · 2005-12-07 07:05 · Score: 1

now back off on the Perl.. that stuff is damn hard to read let alone write good stuff with..

in my mined everything is a walk in the park compared to perl when trying to write something of quality... when your done it is amazing but until then you want to beat people with your keyboard and see if that helps get the bugs out.

--
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
Re:as in all new directions... by masklinn · 2005-12-07 07:11 · Score: 1

Duh, frames still suck period.

Few has changed since Nielsen's first article on them, the only thing we could add being that iframes suck just as much as regular frames.

--
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Re:as in all new directions... by Davorama · 2005-12-07 07:19 · Score: 1

They've introduced some new editors recently that just aren't very good. (Sorry /., it's just my opinion.) /. has always had problems with dupes, typos and 'post first, ask questions later' but lately It's been much worse. I'd ban an editor or two from my main page but I think they are doing 90% of the posting anymore.

The really dumb thing is with just a little thought the posts wouldn't be that bad. This one in particular, could have just been prefaced with "Here's a great spoof of and old frames rant applied to AJAX". Add the foot icon next to it and there would be nothing to complain about. Not that it would stop this crowd...

--
Davo -- Free speech, free software, AND free beer.
Re:as in all new directions... by masklinn · 2005-12-07 07:19 · Score: 3, Informative

HTTP is not a stateful protocol -- ok

HTTP is not a connected protocol -- ok

HTTP is not a client-server protocol -- WTF? What are you smoking here? Of course HTTP is a client-server protocol

--
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Re:as in all new directions... by masklinn · 2005-12-07 07:21 · Score: 1

Exactly. The author is using many of the same tired arguments that were initially used against frames

Which is extremely strange since it merely s/frames/ajax/ in a frames-oriented rant from 1996 (which still stands true, but that's another issue)

--
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Re:as in all new directions... by ill.temp · 2005-12-07 07:49 · Score: 1

this is the perfect example of fundamentalism and its inherent flaws...moving on
Re:as in all new directions... by Skreems · 2005-12-07 07:51 · Score: 1

That's not true... it just takes a little hacking. There's some website that lets you connect as a client to all of the major IM systems, and use it as you would Gaim, essentially. They manage instant communication by using ajax to keep a continual client-side request, let it hang on the server, and then push data back down as soon as something needs to be transfered. You eliminate any lag from polling... essentially you're emulating a socket connection. It's a hack, but it works really well.

--
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
Re:as in all new directions... by steveness · 2005-12-07 07:53 · Score: 1

So, I ran home, and guess what? AJAX is soluble! Although, it did turn blue while it dissolved. I was really excited to notice that it cleaned my bathroom in its new liquid form.

:)

(note to the humorless, yes, I do know that soluble has two meanings.)
Re:as in all new directions... by lahi · 2005-12-07 07:57 · Score: 1

Sorry, but there is just about everytrhing wrong with the protocol. If I remember correctly, most of what is wrong with it was obvious from the start, all the way back to HTTP/0.8. It is suited only for a subset of what it is today abused for. The useful subset is restricted to static pages and elements, and only barely. Anything that needs sessions has to use the stupid hack which is cookies or the even stupider hack which is URL rewriting, because HTTP was foolishly designed as a stateless protocol, despite using TCP. Basic authentication is a joke which at the time of its invention had long ceased to be funny. (Other protocols had at that time realized the problems with sending passwords unencrypted.) And don't get me started on the insanity of URL-encoding, query-strings, the "difference" between GET and POST methods, redirections etc etc.

-Lasse
Re:as in all new directions... by Hard_Code · 2005-12-07 07:58 · Score: 1

"valid at one point for using frames as well"

What do you mean "at one point"? The article he is spoofing is his OWN article about frames, and the advice STILL holds. How many sites do you see using frames out there? From my experience, almost none (I only say almost because I know there are but I haven't come accross anything other than the occasional garish personal geocities homepage which actually uses frames).

The spoof is not the content, the spoof is that he re-used a previous (valid) article about frames to layout the AJAX article.

Either he is genuine in his current analysis, or he needs to make it way more obvious that his own arguments are disingenuous (but I don't believe they are).

--

It's 10 PM. Do you know if you're un-American?
Re:as in all new directions... by masklinn · 2005-12-07 08:00 · Score: 1

HTTP is used by but not limited to web browsers.

The web in general uses the HTTP protocol, but it only uses a subset of it, HTTP is to be used in any and every case where you need to retrieve distant resources, it's a general purpose resource-manipulation protocol (and resource is to be understood in a very broad sense here), quite simple but extremely powerful.

HTTP is perfect for the web because the web is "nothing but" a gigantic collection of resources, andHTTP is a disconnected protocol (you don't have to maintain a TCP connection between requests) (HTTP/1.1 gives the ability be used as a connected protocol btw). HTTP also standardizes a heap of meta-informations (the HTTP headers) that come in handy to manage local vs distant resources.

--
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Re:as in all new directions... by Opie812 · 2005-12-07 08:06 · Score: 1

I swear, I've heard the same argument about PHP, Perl, C, and even the concept of object oriented programming.

I the same in an article about frames a while back....

--
I'm not a nerd. Nerds are smart.
Re:as in all new directions... by The_Wilschon · 2005-12-07 08:15 · Score: 2, Interesting

I think the major point of the article is that AJAX is currently being used (like a lot of upstart web technologies) in many places were it just confuses things more than needed. Give it time, and people will stop using it just for the sake of jumping on the new craze bandwagon and we'll find out where it shines and where it should never go.

True indeed. In fact, if you look at the author's Original Top Ten Mistakes in Web Design, number 2 is "Gratuitous Use of Bleeding-Edge Technology".

--
SIGSEGV caught, terminating

wait... not that kind of sig.
Re:as in all new directions... by Pxtl · 2005-12-07 08:16 · Score: 1

I agree, basically he's making the same point about Ajax that he made quite well abou frames - they break the web. The web has never been good at being anything but pages - possibly submitted forms, possibly just pages of info, but always pages. Imho, the only thing that web pages needed beyond basic javascript was server-side updating (forced, server-event-driven "refresh", preferably sending only a diff for efficiency's sake). All this "web app" stuff should've just been an embedded object of a different platform like Java or TCL or something.

The problem is that said platform never standardised - never ended up the same platform on every windows/mac/linux/sun box in the country the way browsers (roughly) do. Well, partially the same - I guess that's the other problem - a website deformed by incompatibilities is just ugly, while a similarly deformed client program is non-functional. Either way, Java was too ambitious and proprietary. Java was too heavy and too Sun. Plus, any such platform must communicate entirely through http or fear the wrath of the firewall gods.

But we needed something there - some standardised VM that could be embedded into a browser for web-apps. It's just that Java wasn't it - something smaller and nicer like Tcl/Tk would've been much better.
Re:as in all new directions... by AKAImBatman · 2005-12-07 08:18 · Score: 1

Meebo!

Yes, I'm well aware of the stale connection hack. (I've mentioned it here before.) However, I wouldn't trust it for something time critical. An IM client or IRC chat room will survive a temporary delay if the connection is lost. A real-time auction OTOH would not be so forgiving. Plus the overhead of the HTTP POST could delay a bid long enough to change the outcome.

Like I said, AJAX doesn't work in the rare situation where the data is both time critical AND requires data to be pushed. :-)

--
Javascript + Nintendo DSi = DSiCade
Re:as in all new directions... by Hard_Code · 2005-12-07 08:24 · Score: 1

Gah, I missed that somebody else wrote the article linking to Neilson's. But the arguments seem genuine regardless.

--

It's 10 PM. Do you know if you're un-American?
Re:as in all new directions... by islanduniverse · 2005-12-07 08:30 · Score: 2, Insightful

Also, notice if you click the link for "The Original" it was written December 1996...

I mean -- look at these 'statistics' :

The November 1996 browser statistics from Interse show the following distribution of browser usage:
Netscape 2: 13% of users
Netscape 3: 47% of users
Internet Explorer 3: 28% of users
Other browsers or earlier versions: 13% of users
Percentages sum to 101% due to rounding. Thus, 13% of users would not even be able to see a site with frames.

[Frames Suck Most of the Time (Jakob Nielsen's Alertbox December 1996): Link: 9612.html , Dec07th, 2005]
Re:as in all new directions... by Total_Wimp · 2005-12-07 08:32 · Score: 1

For "valid at one point" consider using "always valid".

Absolutely correct, and yet provides no insight into the topic at hand. Please consider posting insightful comments related to ajax in future replies to this thread.

TW
Re:as in all new directions... by Total_Wimp · 2005-12-07 08:36 · Score: 1

Please, please, please ignore my previous post. Your post is obviously quite relevant. I thought you were saying something different.

(taking foot out of mouth) :-(

Sorry,
TW
Re:as in all new directions... by KilobyteKnight · 2005-12-07 08:38 · Score: 1

What do you mean "at one point"? The article he is spoofing is his OWN article about frames, and the advice STILL holds. How many sites do you see using frames out there? From my experience, almost none (I only say almost because I know there are but I haven't come accross anything other than the occasional garish personal geocities homepage which actually uses frames).

Ajax != Frames
Comparing the two is just silly. It's just as silly as comparing frames to PHP or VBScript.

I did note the "This is a spoof" link at the bottom. I can only wonder what point the author was trying to make. While all those things are true of frames, I kept saying to myself "This is bullshit" while reading it in reference to Ajax.

For example, the gripe about printing is not valid at all. If you write the page(*) using web standards, you should have a custom printable version anyway. CSS makes that relatively easy. The difficulty involved has no relation to whether or not you used Ajax. Anyone who doesn't know how to make a custom print page has no credibility in expressing public views on web usability.

As for the back button breaking, I think most people expect the back button to be broken. It's pretty broken period. Additionally, it makes little or no sense in the context of a web app - which is where Ajax fits in.

(*I say "page", but perhaps "output target" would be more to the point.)

--
When will Windows be ready for the desktop?
Re:as in all new directions... by Haeleth · 2005-12-07 08:40 · Score: 3, Informative

They've introduced some new editors recently that just aren't very good

Um, dude, this story was posted by CowboyNeal... I'm reasonably certain he's not new here.
Re:as in all new directions... by Anonymous Coward · 2005-12-07 08:45 · Score: 0

Actually there's barely any difference between the format of a HTTP request and a HTTP response.
The protocol could easily be tweaked to work in a P2P environment if someone wanted to do that. In fact it's probably been done already in trackerless bittorrent. I'm too lazy to go check right now.
Re:as in all new directions... by Aewyn · 2005-12-07 08:45 · Score: 2, Informative

Mobile browsers have problems with MOST page content. Websites are designed for a minimum of 800x600 these days, if not 1024 wide. Websites still need to provide special pages to serve up content to mobile devices anyway.

No they don't.

First of all, there's no need to make "special pages" when the presentational fluff can be separated in CSS so that the pure HTML still makes sense.

Second, even your average poorly designed page can usually be rearranged to look OK on a small screen. Do View/Small screen in desktop Opera to get an idea of how it can look like.

Mobile devices are actually becoming quite decent as long as there's not excessive amounts of Javascript (though Flash-only sites are even worse).
Re:as in all new directions... by fatcatman · 2005-12-07 09:08 · Score: 1

The best use of AJAX, that I see, is with improving user interactivity with a web application. Web applications are becoming more and more of a need, and I think this is where AJAX is gaining the most ground.

Exactly. Who would use Ajax as a primary means of navigation on a static page?

I used it for pulling up data and navigating personal stored info in my bookmarking application, but not for any static content. Who would use Ajax to retrieve static content?!
Re:as in all new directions... by diverman · 2005-12-07 09:33 · Score: 1

First of all, there's no need to make "special pages" when the presentational fluff can be separated in CSS so that the pure HTML still makes sense.

Depends on your definition of a "page". I'm not saying you duplicate backend content. You are making a distinction between implementations, when I'm pointing out specifically presentation. To me, the same content presented with two significantly different layouts are "different pages". You still have to do the work to support/review/debug/test the different formats.

Second, even your average poorly designed page can usually be rearranged to look OK on a small screen. Do View/Small screen in desktop Opera to get an idea of how it can look like.
Really? How well does the usability of slashdot discussion threads work on my blackberry? Kinda sucks. How about Yahoo (oh wait, they have a special UI for mobiles). Sure... with SIMPLE content pages. But the point of most of my post was that simple pages with simple presentation is NOT the area that AJAX is focused on.

Mobile devices are actually becoming quite decent as long as there's not excessive amounts of Javascript (though Flash-only sites are even worse).
Oh, right... you mean where the more featureful and easy to use sites are headed? Dynamic content exists and is growing. Mobiles haven't kept up. They are getting better than they were... so why not support CURRENT (if you can call a technology that is YEARS old "current") technologies like AJAX?
Re:as in all new directions... by Onan · 2005-12-07 09:37 · Score: 0

The best use of AJAX, that I see, is with improving user interactivity with a web application. Web applications are becoming more and more of a need, and I think this is where AJAX is gaining the most ground.
Hooray for begging the question.
I, on the other hand, find the whole notion of "web application" to be a malformed one. Any technology that exists solely to serve this anti-goal can only be of negative utility.
Users don't like having to wait for a full page load to make a small request within an application. There is complaint about the time it takes. Granted, this is largely a perception thing, but it is the reality of users.
Know what makes those page loads take so long? Javascript, flash, superfluous tables, and all the rest of the crap layered on by the same designers who claim that they need such heavyweight monstrosities to improve responsiveness. Try just putting together simple pages in pure, flexible html some time, and be amazed at just how quickly they load and render.
A best practice is to take length articles and break them up into multiple pages.
Bahahah. This is a "best practice" only for site maintainers who want more pages on which to display more ads. It is incredibly unhelpful for everyone else, most notably the reader.
Old browsers are likely unpatched browsers. With the vulnerabilities and security issues today, compatibility with AJAX is the least of their problems. Upgrade!
"Non-ajax browsers" does not mean the same thing as "old browsers." I'm posting this from the currrent version of w3m, which does not and never will support ecmascript in any form.
Which is good, because it saves me the trouble of disabling it. Which is another place at which your "old browsers" assumption falls down: many of us explicitly disable nonsense like ecmascript in any browser we use, however current. I have never yet seen anything done with ecmascript that I wanted to have happen to my browser, so I find that I'm vastly better off without it.
Mobile browsers have problems with MOST page content. Websites are designed for a minimum of 800x600 these days, if not 1024 wide. Websites still need to provide special pages to serve up content to mobile devices anyway.
Oh dear fuck no. "This web page designed for 800x600!" wasn't cool in 1995, and it's not cool now. The whole bloody point of the Web, the whole thing that made it successful in the first place, was the design goal of delivering content in a presentation-flexible manner. If you write markup that breaks in the presence of something so mundane as a window size you didn't expect, then you have failed.
Tossing about meaningless phrases like "information complexity has evolved" do not give you an excuse to ignore usability standards that are every bit as valid today as they were fifteen years ago.
Re:as in all new directions... by amitola · 2005-12-07 09:43 · Score: 3, Informative

HTTP is not a stateful protocol -- sort of, if all you know is RFC 2616. But if you're using any kind of language to create dynamic content on the server, the first thing that happens is almost always to set a session cookie for purposes of maintaining state.

HTTP is not a connected protocol -- sort of, unless you count persistent connections which have been allowed since RFC 2068 (HTTP 1.1). And now XmlHttpRequest muddies that question even more.

This isn't the Constitution we're talking about; I don't know why people bother to argue from "first principles" such as "HTTP is not stateful." There's nothing morally superior about a stateless protocol. The protocol has changed over time. There's no point pretending it hasn't.
Re:as in all new directions... by 2short · 2005-12-07 09:48 · Score: 1

You seem to be complaining that http doesn't do a good job of being a state-maintaining, connected protocol. In other news, Ferrari sports cars suck for bulk freight transport. If you want a protocol that acts like telnet, might I suggest you use telnet?

HTTP is perfectly good at doing what it does, and it's existence does not prevent you from using any of various other fine protocols that are designed to do other things. I'll readily agree that the decision to send passwords as clear text was a foolish one; but it is a decision that was made by the writers of web browsers, not the designers of the http protocol. There is nothing whatsoever stopping you from encrypting whatever you want before using http to send it.
Re:as in all new directions... by Anonymous Coward · 2005-12-07 09:56 · Score: 0

I don't want to start a holy war here, but what is the deal with you AJAX fanatics? I've been sitting here at my freelance gig in front of a AJAX screen for about 20 minutes now while it attempts to copy a 17 line troll from one message thread on the hard drive to another thread. 20 minutes. At home, on my PHP account, which by all standards should bea lot slower than this AJAX, the same operation would take about 2 minutes. If that.

In addition, during this troll transfer, Netscape will not work. And everything else has ground to a halt. Even ebay.com is straining to keep up as I type this.

I won't bore you with the laundry list of other problems that I've encountered while working on various AJAXs, but suffice it to say there have been many, not the least of which is I've never seen a AJAX that has run faster than its PHP counterpart, despite the AJAX's faster troll architecture. my.yahoo.com with 8 categories of Rueters Top News runs faster than this site at times. From a productivity standpoint, I don't get how people can claim that AJAX is a superior technology.

AJAX addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use AJAX over other faster, cheaper, more stable technologies.
Re:as in all new directions... by vadim_t · 2005-12-07 10:17 · Score: 1

Well, I hate to break it for you, but after 12+ years, web sites have gone to crap.

Instead of a light page that contains exactly what it should and no more, now I need to deal with 50K Javascript monstruosities which break the back button, produce errors even in IE, and do utterly annoying things having the gall of popping up message boxes saying "Please wait until the page refreshes"!

Seriously, I tried configure a server on hp.com today. HP could have a normal page, but no, there's got to be some Javascript crap that dares to complain because I toggle options too fast on it! And my bank for some reason insists on that the "back" button is a no-no, and that I must deal with it like with old DOS applications that could only have one "window" at once. Heck, even in DOS they managed to do better than that!

The same crap also makes it impossible to bookmark multiple configurations, as the data isn't actually stored anywhere. Now I've got to print it, then go back to the page, and set the options the way I like them again. Isn't it great to have http://server.com/magic-script.asp in the URL instead of all that "foo=1&bar=3" mess?

Yup, things have evolved indeed.
Re:as in all new directions... by diverman · 2005-12-07 10:22 · Score: 1

Know what makes those page loads take so long? Javascript, flash, superfluous tables, and all the rest of the crap layered on by the same designers who claim that they need such heavyweight monstrosities to improve responsiveness. Try just putting together simple pages in pure, flexible html some time, and be amazed at just how quickly they load and render.

Actually, as I said, it's perceived time. The blinking and redrawing of the page in an application setting is perceived as taking longer for the user. Whether this is wait time, or time to orient themselves from page to page is irrelevent. Actually, most of the pages of the sites I use are very simple. They do load quite quickly, and they are not overwhelmed with Javascript. One point I agree with the author on is "sparingly".

"Non-ajax browsers" does not mean the same thing as "old browsers." I'm posting this from the currrent version of w3m, which does not and never will support ecmascript in any form.

Which is good, because it saves me the trouble of disabling it. Which is another place at which your "old browsers" assumption falls down: many of us explicitly disable nonsense like ecmascript in any browser we use, however current. I have never yet seen anything done with ecmascript that I wanted to have happen to my browser, so I find that I'm vastly better off without it.

Valid point. I still don't care about them. They're too small a userbase to give up the benefits to the rest of the users who are not so irrationally anti-client-side scripting. Again... I think sites that have an abusive level of scripting are quite annoying. Not once in my arguments have I said to embed JavaScript like mad for every link, image, field, form, and character on the page. But there is much to be gained from a WEB APPLICATION perspective. This is where AJAX really does shine. Pages don't have to reload, even though you're on the same "interface", moving your buttons relative to page location (any scrolling down), causing you to need to reorient yourself on the page.

Oh dear fuck no. "This web page designed for 800x600!" wasn't cool in 1995, and it's not cool now. The whole bloody point of the Web, the whole thing that made it successful in the first place, was the design goal of delivering content in a presentation-flexible manner. If you write markup that breaks in the presence of something so mundane as a window size you didn't expect, then you have failed.

Actually, the "bloody point" of the web was to share information through a more useable interface than existing technologies, such as gopher, specifically for graphical presentation. Images of physics results and statistics were more easily presented in a graphical manner. This notion that the web was first created in a perfect way for all-time, which so many of you seem to cling to, is just stupid. The web was created because the tools available at the time didn't do what some geeks wanted. So they stepped up the game a notch. If you recognize THAT as the foundation of the web, technologies such as AJAX and the like are very much in the tradition of the web, as opposed to the sad view that someone came up with a perfect way to present data for all time, when in fact they came up with a to do things that what existed sucked at doing.

Anyway... reread my post. I focus on appropriate use of AJAX in Web Applications and agree with the original author that simple content and pages do not really benefit all that much, but likely suffer. However in web applications AJAX provides few disadvantages compared to the advantages, within the context and needs of most web applications. Besides... if AJAX doesn't help your application or site, don't use it! If it does, by all means, use away. If your target user base can benefit from it significantly more than they lose, why would you argue that, unless you have some irrational purist sense of "how the world should be".
Re:as in all new directions... by mcvos · 2005-12-07 10:32 · Score: 1
It's hard to deny some of the points the article makes, yet I like Ajax a whole lot more than I ever liked frames. I hated frames. Still do. There's not much you can do with frames that you can't also do without. The onlly frame-based site I really like is Sun's Java Docs, and even that could have been done without frames.

Ajax, however, lets you do things you really cannot do without it. Can you imagine Google Maps without Ajax? Or all those spiffy desktop-in-your-browser sites? The company I work for has written and sells a (Open Source, btw) CMS that runs mostly in Ajax, because we want it to work in a normal browser instead of requiring customers to install a special piece of software, and a heavy overdose of javascript is the only way to get all the stuff done that the CMS has to do.

In fact, it was Ajax that actually convinced me that javascript wasn't really all that bad. I used to hate it, because too many websites used javascript mostly for frivolous junk, messing with my browser, and replacing perfectly good html functionality with something that doesn't work in half of the browsers. So I'd like to propose two ground rules for the use of Ajax. (And they go for regular javascript too.)
1. Do not use frivolously.
2. Only use it when nothing else will do.
3. Absolutely never ever use it because it's "hip" and "cool".
Re:as in all new directions... by Plaid+Phantom · 2005-12-07 10:45 · Score: 1

Um, dude, I'm reasonably certain he was talking in general.

--
All comments are properties and trademarks of the voices in my head. Not like I'm gonna claim them.
Re:as in all new directions... by diverman · 2005-12-07 10:47 · Score: 1

HTTP is not a stateful protocol -- sort of, if all you know is RFC 2616. But if you're using any kind of language to create dynamic content on the server, the first thing that happens is almost always to set a session cookie for purposes of maintaining state.

Not to burst your bubble or pick nits here, but once you're talking about maintaining sessions in the application, that by definition is not part of the underlying "protocol" of HTTP. That is a layer above. The HTTP request object (environment, whatever it's called in what you use) is NOT part of the HTTP protocol; it simply uses HTTP, but adds additional abilities.

Of course, I'm not supporting the previous post... just pointing out a flaw. :)
Re:as in all new directions... by Anonymous Coward · 2005-12-07 10:47 · Score: 1, Informative

Yeah, HTTP can be used for p2p. Off the top of my head Gnutella uses it at least for messages, possibly other things, and the Grapevine anonymous p2p project
(http://grapevine.sourceforge.net/) is entirely over HTTP.
Re:as in all new directions... by diverman · 2005-12-07 11:07 · Score: 2, Insightful

I don't know. After 12+ years websites that have learned to use technology effectively have become MUCH better. I don't deny there is a lot of cruft and crap out there as well. But because there are idiots in the world doesn't mean the genius (not necessarily claiming this for myself) that has emerged don't exist.

It seems that almost everyone that argues against me on this keep bringing up simple, static, content pages as their support. But if you people bother reading my postwith the context of THAT POST (as opposed to the bucket your charged up brain has placed it into), you'd see that I am focusing on Web Applications. These are not pages that generally need to be bookmarked. These are not pages that NEED a back button.

I mean, bitch about the limitations of Banking websites all you want. The dynamic content is what allows you to HAVE a banking website. The limitations have little to do with the JavaScript or AJAX. The limitation that you can't go BACK on those pages has to do with general state and flow management. And the "Back button" issue that you mention has nothing to do with the "Back button" issue the article's author mentioned. Your back button issue has existing since the beginning of dynamic web pages/web applications. It is specifically THESE limitations that have driven technologies like AJAX. I mean, if you process a transaction for a transfer, and then try to hit "back", bringing you back to a processing page and the interface just lets you... you're more likely to make a mistake of retransferring money (duplication). The choice your bank made is to not let you go back. Others handle it by just not processing a resubmit on a transaction, but let you back button all you want. Another option would be to use AJAX within the scope of a transfer transaction "application". Hitting the back button would take you to the page you were at before the transfer request. This would actually be idea, since loading into the middle of a completed transaction's form is simply "invalid use".

Hmmm... I think your issue with your bank's "back" button restrictions is actually an argument FOR something like AJAX!

So, once again... your arguments are not with AJAX or similar technologies. Your argument seems to be against poorly implemented applications. The back button issue you descrobe, not allowing simultaneous windows, etc... these are not issues with AJAX or similar technologies. These are issues with the back-end session and transaction management of the application. But since much of that level of backend development isn't inherant to existing frameworks, it becomes a lot more development (and QA/testing) to support. AJAX could actually help alleviate your specific issues, by reducing the client behavior that causes banks like yours to be so restrictive.

-Alex
Re:as in all new directions... by Anonymous Coward · 2005-12-07 11:21 · Score: 0

You're confusing HTTP with things that use HTTP. The protocol itself (i.e, RFC2068) is completely stateless, although it provides a mechanism (cookies) by which applications using the protocol may store state. But things like sessions are 100% the responsibility of the clients that use HTTP.
Re:as in all new directions... by DavidTC · 2005-12-07 11:36 · Score: 1

Exactly. Anyone who says 'I don't like AJAX.' is welcome to explain how Google Maps should work. (I guess, in theory, it could be done without using XML as a transport, and hence would not technically be 'AJAX', but that's a bit nitpicky.)
The problem is, like any new technology, people are using it in stupid places, and thus there is a backlash against it. Eventually, most new tech either finds a useful place, and workarounds for problems, like frames did, or won't, like Flash, which continues to be used by people with too much knowledge and not enough intelligence.
Actually, speaking of new technology finding a niche, I'll argue that Javascript really didn't have one until now. Sure, there was form validation, but you had to do form validation again server side, and the menus just pissed 15% of people off. It didn't really take off until DHTML, which was really just the precursor to AJAX, although without server communication it was limited to fancy menus.
Now, with AJAX, there is actually a functional reason to write sites that rely on Javascript, because now there are things that are actually impossible to do without it, and these things are very useful. 95% of these are 'applications', where you've got a bunch of stuff straight from a database and want to let the user manipulate it.

--
If corporations are people, aren't stockholders guilty of slavery?
Re:as in all new directions... by Midnight+Thunder · 2005-12-07 11:39 · Score: 2, Insightful

The truth is what makes a technology bad is using it in the wrong way. When it comes to the web we see much more of this happening. Take Flash as one example, where IMHO it is used badly most of the time, yet there are some things which can benefit from Flash, such as an embeded game. AJAX is the same, there are a few valid uses for the technology. For example one good use of the technology is Google Maps.

--
Jumpstart the tartan drive.
Re:as in all new directions... by Aewyn · 2005-12-07 11:43 · Score: 1

First of all, there's no need to make "special pages" when the presentational fluff can be separated in CSS so that the pure HTML still makes sense.
Depends on your definition of a "page". I'm not saying you duplicate backend content. You are making a distinction between implementations, when I'm pointing out specifically presentation. To me, the same content presented with two significantly different layouts are "different pages". You still have to do the work to support/review/debug/test the different formats.

Given your "MOST page content" statement, I was thinking about your average HTML page here, not "web app" type stuff.

What I meant was that if presentation (layout) is kept to CSS, small-screen browsers can still show the pure HTML, so designers don't need to make an extra version in order to give these users access to the content.

They may of course choose to make a media="handheld" stylesheet to improve the looks, but this would be more of a once-per-site thing, not per page.

How well does the usability of slashdot discussion threads work on my blackberry? Kinda sucks.

Sure, it's not going to be optimal when a designer hasn't spent extra effort thinking about small screens, but the actual text is still readable, I hope? You just lose the horizontal margins that depend on threading level?

How about Yahoo (oh wait, they have a special UI for mobiles).

I'm assuming you mean mobile.yahoo.com. But www.yahoo.com is readable on modern handheld browsers, too. If they didn't use so many tables for layout, maybe they wouldn't need two separate URLs...

Mobile devices are actually becoming quite decent as long as there's not excessive amounts of Javascript (though Flash-only sites are even worse).
Oh, right... you mean where the more featureful and easy to use sites are headed? Dynamic content exists and is growing. Mobiles haven't kept up. They are getting better than they were... so why not support CURRENT (if you can call a technology that is YEARS old "current") technologies like AJAX?

I guess "featureful and easy to use" refers to Javascript and not Flash here, since I have yet to see a Flash-only site that is not worse in terms of usability compared to HTML.

I think it may be getting there soon in terms of AJAX, but obviously mobile browser will not be able to fully keep up, considering their limits on processing power when compared to desktop PCs.

As I see it, though, most sites don't need AJAX. I guess we agree on that point. I was mainly reacting to the part about mobile browsers support supposedly requiring lots of extra effort...
Re:as in all new directions... by Anonymous Coward · 2005-12-07 11:47 · Score: 0

I think the major point of the article is that AJAX is currently being used (like a lot of upstart web technologies) in many places were it just confuses things more than needed.

As are computers, and applications that run on them.

Yep, Ajax sucks most of the time. Web pages suck most of the time. Applications suck most of the time. (Can you think of a category this broad that *doesn't* suck most of the time?)

We've just instantiated Sturgeon's Law. Yay!
Re:as in all new directions... by DavidTC · 2005-12-07 12:02 · Score: 2, Informative

Technically you are correct.
But only if you ignore the fact that protocols rarely maintain any state.
For example, FTP. A stateful protocol, right? You move around in directories and whatnot.
Except the server remembers where 'you' are, your directory, but that isn't part of the 'procotol' by any means. Your client hopefully is trying to keep track of where you are, and the server is keeping track of where you are, but these do not have to be the same places, and technically the FTP server could leap you randomly to a different directory, on its end, every two seconds.
The only difference is, with FTP, it knows who 'you' are based on your TCP/IP socket, whereas in HTTP it uses cookies. There are advantages and disadvantages to each method. FTP is more secure in that it's near impossible to hijack other people's TCP/IP connections (Ignoring the whole 'plaintext password' issue specifically with FTP.), but HTTP rocks in that you can stay 'logged in'.
Anyway, the difference between 'stateful' and 'stateless' is not the absolute people seem to think.
At one end, a 'most stateful' protocol would never even let you log out. You are who you are, period, and the server knows that forever, even between shutdowns and reboots. Imagine a serial terminal hooked to a server. You can't ever stop being that terminal.
At the other end, a 'most stateless' protocol would send a single packet in response to a packet, and then forget about you. DNS actually is this.
Most end-user things have some sort of middle ground, where 'state' exists as long as needed, and then is discarded on the command of either end. This state may or may not be tied directly to a TCP/IP socket. Sometimes a protocol is designed as tied to a socket, and then 'upgraded' to allow disconnect/reconnect, like HTTP cookies, or 'screen' which lets you keep remote state while logged out, or FTP resumes, which let you restore a very limited state, specifically where in the file you are.

--
If corporations are people, aren't stockholders guilty of slavery?
Re:as in all new directions... by DavidTC · 2005-12-07 12:11 · Score: 1

What the fuck are you talking about?
You do realize that AJAX can be done in PHP, right?
AJAX is just a web page that use asynchronous javascript to communicate with the server via XML.
The client side is always Javascript. The server side can be any language that speaks XML, which is basically every one of them. (And generating XML output from a language that doesn't support it is hardly rocket science.)

--
If corporations are people, aren't stockholders guilty of slavery?
Re:as in all new directions... by vadim_t · 2005-12-07 13:07 · Score: 1, Insightful

Er, since when there's any need for AJAX for banking? Mine could certainly work just fine without it. Should be perfectly doable with web forms and cookies.

Hint #1: I don't like web applications. Gmail is all nice and cool, but I don't give a damn about it, I'm very happy with my IMAP server.

Hint #2: *I* will decide what I want to bookmark and what not, thank you very much.

Hint #3: *I* will decide when I want to use the back button, instructions not to use it will never cease to annoy me.

And yeah, I know about the back button being a way to re-submit a transaction. But any bank should be sane enough not to process it again, which is exactly what I want: To go back to the previous page, without harmful consequences.

The particular problem with my bank comes in even before attempting a transfer. I have two accounts, numbered something like #2342342343 and #2342342532. The balance screen lets me see my balance. The transfer screen lets me make a transfer. However, since it's dumb enough to show me just account numbers, sometimes I want to go back to the previous screen (balance) to find out which is which. At this point the site complains that I shouldn't use the button, and forces me to start the process from the beginning, of course losing any data I had already entered in the form. All of this is before trying to confirm the transfer.

I fail to see why couldn't there be "balance.cgi", "transfer.cgi", and "rechage_cell_phone.cgi", and a complete lack of all this weird magic.

If the bank for whatever reason wants to offer a richer interface they can do it perfectly well with say, a Java application which won't have any of the problems all this AJAX mess has.
Re:as in all new directions... by diverman · 2005-12-07 13:19 · Score: 1

Given your "MOST page content" statement, I was thinking about your average HTML page here, not "web app" type stuff.

My points about most pages wasn't in relation to use of AJAX, nor web applications. But even most largely static content websites are not designed for viewing on small screens. Most use tables or DIV tags, and on mobile devices these generally come across as a confusing and unusable page. Of course, this is with sites that don't think about mobile devices when designing. And this is MOST websites. They just don't think about it. So, the "most page content" was not as an argument for AJAX, but rather explaining why I don't consider the mobile market of browsers to matter all that much. The article says 11% are mobile users. But to me, that 11% has very little weight, and I truly believe that MOST web developers/designers feel the same. The whole reason for attacking the "old/non-ajax browsers" and mobile devices, was to put the statistics provided into perspective. To me, if you add "weights" to those markets, they become closer to 2% of what I care about, thus not a significant reason to be worried about some of the negatives raised as "shock-statistics" in the article. That's all that point was trying to bring out.

As I see it, though, most sites don't need AJAX. I guess we agree on that point. I was mainly reacting to the part about mobile browsers support supposedly requiring lots of extra effort...

Yes, I think we do agree on that. And that is what is bugging me about so many responses I see here, and with what the article seems to imply as justification for saying "AJAX Sucks". For serving up more "content" oriented pages... I agree that it is not the best choice/option. But neither the author nor many arguing against AJAX here, are providing an intellegent qualification for their statements, but rather blurt out a blanket comment that simply has too many exceptions.

AJAX is an amazing step towards good things with web applications. It has it's design considerations, sure. But so does any technology. I disagree with the extreme "hype" as well. Far too many people are hyping AJAX to a point that people are being stupid about using it where it doesn't belong. And I think an article/presentation to raise the concern is a good idea. I just think an extreme opposition to AJAX to a point of almost saying it should never be used is just as stupid and irresponsible as the hype. I think the benefits should be hailed as a wonderful thing, within its context... and I think extra attention should be raised to the exceptions and cautions. But they should also be within proper context.

These extreme sides just reminds me of the stupidity of politics these days... two extremes making stupid and irresponsible statements as a "counter balance" to the other... but neither actually does any justice to those who are affected most!
Re:as in all new directions... by mabinogi · 2005-12-07 13:21 · Score: 1

> As for the back button breaking, I think most people expect the back button to be broken. It's pretty broken period. Additionally, it makes little or no sense in the context of a web app - which is where Ajax fits in.

No, absolutely not.
There is no valid reason for ever breaking the back button, and it makes plenty of sense in a web application.

There is too little obvious difference for the user between a static web page, a page with a little dynamic content and a "web application" for fundamental concepts like the back button to behave differently.

--
Advanced users are users too!
Re:as in all new directions... by diverman · 2005-12-07 13:44 · Score: 2, Insightful

Er, since when there's any need for AJAX for banking? Mine could certainly work just fine without it. Should be perfectly doable with web forms and cookies.
I said it was a possible solution to the "issues" you stated regarding your banks interface. Your issues have little to do with AJAX, JavaScript, or any other scripting. They are issues inherant to a web application not designed to handle specific cases as gracefully as you would like (but they could, if designed to).

Hint #1: I don't like web applications. Gmail is all nice and cool, but I don't give a damn about it, I'm very happy with my IMAP server.

Hint #2: *I* will decide what I want to bookmark and what not, thank you very much.

Hint #3: *I* will decide when I want to use the back button, instructions not to use it will never cease to annoy me.

And yeah, I know about the back button being a way to re-submit a transaction. But any bank should be sane enough not to process it again, which is exactly what I want: To go back to the previous page, without harmful consequences.
Um... your bank interface is a web application. Search engines are web applications. Pretty much anything that does logical user interaction is a web application! So, you don't care for most websites these days? Oh yeah, slashdot is a web application!

Interesting. Can you bookmark results on POST submits? No AJAX, but certainly can't be reflected in a URL. But then again, form submissions/results are a web application, but I forgot... you don't like using them.

Not if the site is designed to not give you the page. Considering that the website is likely more responsibile for effects of misuse, are the ones that DESIGN and GIVE you an interface and workflow to use, I think it's well within their right to control workflow on THEIR website. If you don't like it, don't use it. Now, a properly designed site will make these choices either seemless or unobtrusive to their users. So, again, you aren't complaining about AJAX, JavaScript, or other scripting, but rather a poor implementation. But place blame with it belongs, not on the first thing you notice to be related to the issue.

If the bank for whatever reason wants to offer a richer interface they can do it perfectly well with say, a Java application which won't have any of the problems all this AJAX mess has.
What crack are you smoking? Do you KNOW what AJAX is? AJAX is not something that is going to send up a warning because you hit your back button. That's JavaScript, yes... and probably what I'd call annoying as well. But AJAX is a way for a single web page to make requests behind the scenes without stepping from page to page. If AJAX were used for specific transactions, hitting your back button would present NO risk as it sounds like there currently IS with your bank. There would be a "transfer" page, and the steps of the transaction would not load a new page, but just be handled on that one page with requests done in the background. You could then hit back and forward all you want with little risk to transaction or your account. It would give you the freedom to use your back button without stepping into pages that are invalid or "dangerous", but still go to pages that ARE stable landing points.

And as for using Java as a solution to your issues? Why would this be? Java is just another programming language for the backend, unless you're talking about a servlet. It is prone to the exact same problems as PHP, Perl, C#, ASP, or even C (God forbid) would have in a stateless protocol. If something that uses Java on the backend IS behaving better, it's only because the implementation of the site has chosen to handle flow control better. But this could be the same regardless of the underlying language.

AJAX, as I said could be ONE solution to help with the problems you mentioned. Personally, I think it would also make the overall "steps" easier
Re:as in all new directions... by vadim_t · 2005-12-07 14:22 · Score: 1

Who said anything about POST? There's GET, which works just fine, is perfectly bookmarkable, and when using SSL, is sent encrypted.

By "web application" I mean specifically anything trying to act as an application, that is, trying to make the web fully stateful, beyond what's offered by GET/POST and cookies. Things like gmail, for instance. I have no problem with slashdot and google itself, where every page is perfectly bookmarkable, and pages don't suddenly change on their own.

And it seems you didn't get my comment about Java. I was talking about a *desktop* application, not about a backend. Say, like Azureus for instance. If the bank wants to provide a rich interface, what could be better than an actual application instead of something that tries to be one but can't manage due to the limitations of the web?

And why it makes little sense? I'm not talking about one or the other, but both. If you want to give easy access to anybody from anywhere, you do a website. If you want a full interface with no limitations, the web still gets nowhere near a decent desktop app.

It's nothing very strange, really. If I wanted to always have access to my email in all possible conditions, I'd install something like squirrelmail on my server. On the other hand, IMHO, no web interface beats a decent mail client (kmail, eudora, mutt, etc)
Re:as in all new directions... by IntlHarvester · 2005-12-07 14:56 · Score: 1

> Can you bookmark results on POST submits? No

Right, you can't, so that's why you don't. Redirect the user's browser to make a GET request that shows the results of a successful submit. Solved problem in 1996.

--
Business. Numbers. Money. People. Computer World.
Re:as in all new directions... by Anonymous Coward · 2005-12-07 15:05 · Score: 0

Thank you Alex for hitting the nail on the head. A more accurate title for the article would be "Jacob Neilson sucks most of the time", as he demonstrates an abject failure to conceive of the web as a delivery medium for interactive applications. In this regard, AJAX has the potential to revolutionise the user experience, but only at the hands of skillful developers, who understand users at a cognitive processing level.
Re:as in all new directions... by KilobyteKnight · 2005-12-07 15:40 · Score: 1

There is too little obvious difference for the user between a static web page, a page with a little dynamic content and a "web application" for fundamental concepts like the back button to behave differently.

OK, so what should the back button do for an online spreadsheet or word processor?

What's a good obvious use for a back button on a patient claim history information lookup app at a doctor's office?

Ever tried hitting the back button after posting a comment here on Slashdot? Does it do what you'd like it to do?

--
When will Windows be ready for the desktop?
Re:as in all new directions... by HR · 2005-12-07 15:49 · Score: 1

It seems to me that you are still confusing application behavior and protocol.

The concept of a working directory, and the maintenance of that state by the Protocol Interpreter is absolutely part of the protocol. Otherwise commands like CWD and PWD have no usable semantics. And yes, it requires you to stay connected, of course. Surely you are not suggesting, by your example of the server bouncing around, that the concept of a working directory has no meaning in FTP and the server can just return random results -- are you?

This is utterly unlike HTTP. You say "The only difference is, with FTP, it knows who 'you' are based on your TCP/IP socket, whereas in HTTP it uses cookies." But you can only get away with this because of your ambiguity in the use of "it". When you say in FTP, "it" knows who you are, it is the Protocol Interpreter that has been informed of such by virtue of the USER command, a defined part of the protocol. In HTTP, the "it" is an application for which the cookie data has semantics. It means nothing at the protocol level.
Re:as in all new directions... by mabinogi · 2005-12-07 16:03 · Score: 1

> OK, so what should the back button do for an online spreadsheet or word processor?
Take you back to the page you were on before you went to it. Additionally, the browser should remember the state so that when you hit forward again it is exactly as you left it.

> What's a good obvious use for a back button on a patient claim history information lookup app at a doctor's office?
Going back to the query page, or whichever part you were in before the part you are in now.

> Ever tried hitting the back button after posting a comment here on Slashdot? Does it do what you'd like it to do?
Yes. Because what I would like it to do is behave like a web browser back button, and it does.

If you put something in a web browser window, expect people to expect it to behave like a web page. The only way you're going to be able to control those expectations is by giving them something that is not in a web browser window.

--
Advanced users are users too!
Re:as in all new directions... by diverman · 2005-12-07 17:00 · Score: 2, Interesting

Okay, I'm going to reply to you, and the other guy who are so ignorant about security as to lightly suggest just switching POST to GET.

SSL solely encrypts the communication over the wire. It does not protect the user from having local files (history, etc) from being captured later. This opens them up to considerable risk if all queries (say with SSN, passwords, etc) are communicated using GET. It also stores all of that information in the web logs on the server. This is often a prime target of hackers to collect information. I can easily go on with several other risks to both the server for getting hacked because of GET parameters, and of the user, but I'll leave it at those two major ones. Read ANY book about good practices on building secure web interfaces, and one of the first thing any of them will say is to NOT use GET.

As for fully stateful attempts... that's the purpose of session cookies... to bring a stateless protocol into the stateful world. Technologies such as AJAX are about improving limitation on UI responsiveness, primarily, and not about making things fully stateful.

As for slashdot being bookmarked... no, it can't. You can't bookmark the page you get after posting, nor several others invovled in mid-process form responses. But you can bookmark the important ones (which is also supportive of my view on a good balance and design for appropriate areas of your site).

Actually, I did get your comment abou Java. It was not 100% clear, so I responded with BOTH contexts. You apparently didn't read my whole post. And in addition to all the complexities I mentioned about implementing a thick client based solution, there are massive security concerns as well. Banks have considered the idea of thick-clients (I know because I've worked with some to analyze critical risks to business logic being placed on the client), and decided they are too big a risk, even for many local branches. To remain secure, they would end up turning a Java client almost into a slightly more advanced web browser. Most are actually looking at AJAX or similar solutions to gain the UI advantages while maintaining the need for security. And by the way, if you were made to install and use a Java application for every service that had need for more advanced and interactive services, you'd be bitching about how they need to come up with a more central standard for their applications (ie. the web browser). Applets (or similar technologies) are a decent step in that direction, but are also prone to the same security concerns.

So, it doesn't make sense. It's not practical. People would have to install apps left and right, including those who are not technically savy, but can use a web browser. It doesn't make sense from a perspective of being successful while taking into account the reality of the user base, and what would happen if every other company people needed to deal with required their own special application installed. It's just not reasonable. That is what the advantages of the web browser was about. A common, central platform to build client-server interfaces (yes, applications).

You're right that web browser apps don't compete with desktop apps in terms of flexibility in UI. But we're not talking about things like calculators, Photoshop, or Word. We're talking specifically client-server oriented applications, where the communication is one of the primary things to deal with (behind the scenes, that is). Desktop apps have other limitations that are more crippling when we're talking about secure client-server applications. Oh yeah... you know all those bugs in IE and other clients for interacting with servers... just imagine EVERY one of those apps people need to use having those vulnerabilities without the financial backing to respond/fix immediately because of a non-centralized pooling of resources (like the IE development team that can have so much resources because of the popularity of the app). And I won't even go down the business/cost advantages beyond what I did i
Re:as in all new directions... by diverman · 2005-12-07 17:14 · Score: 1

I won't fully reply to you. Go read the reply to the person that responded before you. The utter terror your lack of understanding of the implications of just using GET instead of POST in more complex and important web applications takes me aback. I certainly hope that if you're a web developer as a profession that you learn more about the impact of your choices.
Re:as in all new directions... by diverman · 2005-12-07 17:18 · Score: 1

Thanks. You ought to read some of the responses I got from others I can only say seem "lacking in sufficient experience", particularly where I need to go off about the unbelievable inconsideration for security concerns about what they were saying. It's an amusing read.

It's a fine line between sounding arrogant, and just knowing you know "more". Very different than the arrogance I had when I was the inexperienced developer about a decade ago or so. :)

-Alex
Re:as in all new directions... by diverman · 2005-12-07 17:32 · Score: 1

Oh, and one more thing... I don't know if you've ever done a view source, but the amount of back end JavaScript being run on slashdot is pretty high too, not to mention having dependencies on external services (one of which was causing issues with pulling up pages earlier). They even use Google Analytics (interesting service). And I believe Google Analytics has some back end AJAX going on. So, in a way, slashdot is running AJAX code! heh.

-Alex
Re:as in all new directions... by maxcray · 2005-12-07 20:02 · Score: 1

> The basic issue is simple - HTTP isn't a client - server protocol. And thus the solution is obvious: make a protocol designed to run applications on the internet.
Re:as in all new directions... by Sheriff+of+Rockridge · 2005-12-07 21:11 · Score: 1

Yes, the article is broad and vague, but he has many valid points. Since AJAX is more a combination of old technologies peiced together in new ways, than a new technology, of course it should be experimented with and used in many cases.

I think the author is focusing on entire applications written in AJAX. Such as Google's new office suite. It is my understanding that the main appeal of AJAX is that since it runs in a browser, it is run remotely, completely cross-platform and requires no installation on the client side. It is hard to ignore the obvious advantages. However, there must be a better medium than a web browser. It's like building a car out of scrap metal.
Re:as in all new directions... by Sheriff+of+Rockridge · 2005-12-07 21:18 · Score: 1

The problem is that although the web has evolved to include "web applications" and other form of content, the fundamental unit of the web is still the "page". The back, forward, and stop buttons work off of "pages", not executed Javascript functions or server-side script. So until the web fundamentally changes, AJAX will be a very awkward use of the Web.
Re:as in all new directions... by KilobyteKnight · 2005-12-08 02:25 · Score: 1

If you put something in a web browser window, expect people to expect it to behave like a web page.

I think people have been used to the concept of a browser behaving differently depending on context ever since ie4. There are probably people who don't even realize file system browsers didn't always look like a web browser.

The only way you're going to be able to control those expectations is by giving them something that is not in a web browser window.

If someone is using an application, I expect them to be using the application. People don't expect a spreadsheet to have a back button. "File/Close" would probably be the most common logical expectation of the function of a back button for an online app; but depending on the app, that won't always make sense.

An application is not a web page. Saying everything that uses a browser for a front end should act like a web page is naive. Different principles apply to applications. The application should be geared towards productivity, not expectations which may be outdated or inappropriate within context.

The Web has never limited itself to Tim Berner-Lee's original concept, nor do I think it should.

--
When will Windows be ready for the desktop?
Re:as in all new directions... by IntlHarvester · 2005-12-08 02:57 · Score: 1

No, the terrible thing is your reading comprehension skills. The point is simple -- send a 302 after the POST and the browser history mechanism doesn't break.

--
Business. Numbers. Money. People. Computer World.
Re:as in all new directions... by diverman · 2005-12-08 03:39 · Score: 1

Alright, admittedly misread your post. Still flawed, and my post about the security issues with putting POST variables into a GET string is JUST as wrong and risky.

-Alex
Re:as in all new directions... by diverman · 2005-12-08 03:41 · Score: 1

Grr... Need coffee.
Alright, admittedly misread your post. Still flawed, and my post about putting POST variables into a GET string as being JUST as wrong and risky, still applies.
Re:as in all new directions... by DavidTC · 2005-12-08 03:49 · Score: 1

First of all, 'directories' in FTP are not required to be directories at all. The RFC specifically says they can be 'datasets'. The RFC operates mostly on the assumption they are directories, but they do not have to be.
And, yes, it is 100% legal to randomly change CWD out from under the client, as there is nothing in the RFC banning anyone from doing so. But more to the point, there is nothing requiring where the client thinks it is to match up to where the server thinks the client is. This is actually a specific problem as recognized in the RFC.
As for 'it', I was rather obviously talking about the server, and not talking about logins at all, but associating state data with the people it belongs to. Logins do not keep track of state, logins are state data, and stored just like whether or not you want binary or ascii transfers.
The FTP server's state is tied to the TCP/IP connection, and holds who you logged in as. This is rather obvious...if you login twice, what you do in one session does not affect the other, except in the obvious case of file system alterations. Because you have two TCP/IP connections.
Whereas the HTTP server's state is tied to the HTTP cookie, and holds whatever people choose to put into it. Web pages can put into the state anything the web server knows about the end user, including data they sent by forms, which obviously can include 'login' data. It is much more manual, but much more flexible, allowing, for examle, multiple states to be associated with one user, a web page pulling up whatever one they want.
And the claim that 'HTTP' doesn't understand cookies is, basically, a complete and utter lie. Cookies are defined quite well in RFC 2965, using a header to extent the HTTP protocol, as laid out in RFC 2616. Pretending it's not 'real' because it's in a different RFC is a bit absurd. By that logic SMTP doesn't have authentication.

--
If corporations are people, aren't stockholders guilty of slavery?
Re:as in all new directions... by diverman · 2005-12-08 03:57 · Score: 1

Although, after thinking about it more, I will concede that using a 302 to redirect to a URL with different parameters than the POST (say a unique index to the output resulting of the POST) would satisfy most security concerns related to POST on that submit.
Re:as in all new directions... by diverman · 2005-12-08 05:25 · Score: 1

Hmmm... interesting. I was under the impression that in the last 12+ years, the web HAS changed. Pages have been able to include applications (Flash, DHTML, Applets, ActiveX [God forbid], etc). This is nothing new... it's been around for a LONG time. AJAX is just another technology that actually ties together many of the older method into newer and easier to deploy ones.

As for the fundamental unit of the web being the "page", that is one way to look at it. You could also see it at an even more fundamental level, and say it is requests and responses. Back, Forward, Stop, etc. all work in handling responses. And if you actually look at the source code of a browser, I'd be willing to bet that this is the way they actually see the web. That's how web servers see and handle it.

So, even IF the fundamental unit is "the page", what's wrong with an application ON a page? Oh, that's right... they have been. However, what I see, is that AJAX takes an application and removes the need to make ONE application MANY pages. It enabled the OPTION to put an application (or segment of one) onto one single page. The "applications page", shall we say.

Does this really sound like a bad thing? It sounds like it makes things simpler in most respects. Stop fearing the natural evolution of technology, look to how it can become a good thing and help steer that direction! You're sounding like all the telnet/gopher buffs I worked with back in '92 that said the web was a waste of time, added fluff, was slow, less compatible, harder to navigate (due to poor/lacking UI standards) and would never amount to anything. Sounds similar to the arguments being used against AJAX.

-Alex
Re:as in all new directions... by diverman · 2005-12-08 07:19 · Score: 1

And the claim that 'HTTP' doesn't understand cookies is, basically, a complete and utter lie. Cookies are defined quite well in RFC 2965, using a header to extent the HTTP protocol, as laid out in RFC 2616. Pretending it's not 'real' because it's in a different RFC is a bit absurd. By that logic SMTP doesn't have authentication.

Ummm... again, NOT part of the HTTP protocol. While cookies are communicated through headers defined by HTTP, the handling and "interpretation" of the cookie header values is also at a higher layer that the PROTOCOL. And even if cookies might be viewed as part of the protocol, they still don't define "state". They are merely a mechanism with which APPLICATIONS can use to maintain state. This HTTP would STILL be stateless (by strict definition of course).

The previous poster was generally right in that you were continuing to confuse the protocol and application layers. You cited maintaining state of "location" in the directory path as being what makes the lower level protocol "stateful". As was stated, it is the persisted connection defined by the FTP protocol that allows a server to make assumptions on a connection. Several transactions and requests are processed through the one connection. This is not the case with HTTP. HTTP is one request/one response. A more complex transaction requires several connections using HTTP.

Get off your high horse, and at least recognize that you have confused application layer with protocol several times now. Or do you need yet another person to come into the thread to point you out as wrong.... regardless of the specific RFC la-dee-da you are spewing. Knowing all your RFC's still doesn't make you right regarding the specific mistakes we've identified about your statements.
Re:as in all new directions... by DavidTC · 2005-12-08 08:57 · Score: 1

No. I'm sorry, but what you're saying is craziness.
I am not, at all, confusing application and protocol layer. (Whatever the 'protocol' layer is.)
However, quite a few people seem to be confusing the transport layer and the session layer. The fact the transport layer might disconnect and reconnect does not make the session layer not exist. And there is a reason the session layer is higher than the transport layer, because a specific session might have more than one connection. (As FTP does, in fact.)
And I'm merely pointing out that while HTTP Cookies are a convention to store random state, so are directory paths in FTP. PWD and CWD are exactly identical to Cookie and SetCookie2. One end says to the other some random stuff, and the other is ready to hand that back out, but the actual content is not defined anywhere. It might be a directory path, it might be a session key, it might be a lot of things. But is not really important, I was just pointing out that protocols often have less state than people think.
What is important is that all state is maintained inside applications with TCP/IP. There is no TCP/IP/HTTP that specifies special packets for HTTP. It's normal TCP/IP, handed off to an application, and the application figures out what state it should have. Sometimes that's via what TCP/IP connection it is, sometimes it's not. (Even with FTP, it's sometimes not, as FTP requires extra connections besides the data channel.)
There is certainly a confusion of the layers going on here, but it's by people who've decided that 'real' state==a single TCP/IP connection, when that makes no sense, and is explicitedly denied by the ISO model of layers. (Hey, don't look at me, I didn't bring up 'layers', as they almost always confuse any conversation they are in.)
And the first person to claim that the 'session layer' is part of TCP/IP, and thus not part of any protocols that use TCP/IP, gets a kick in the head. Unless you have no network experience, you know that parts of layers repeat, and that while TCP/IP goes up to session layer, protocols on top of TCP/IP tend to rewind back to transport layer to redefine how to talk to each other, for example, what commands and response codes should be. Some, like p2p apps, even go back down to the network layer and route data.

--
If corporations are people, aren't stockholders guilty of slavery?
Re:as in all new directions... by HR · 2005-12-08 17:48 · Score: 1

Ok, look... I'm sorry but there is no delicate way to put this. You are talking complete batshit nonsense. The working directory (or dataset) cannot be randomly varied by the server maintaining state in the FTP protocol or the protocol would be utterly broken. Just take 5 seconds and read what RMD does. One could argue, as you are apparently doing, that this command can remove a random directory if the argument is a relative path. You could argue that; everyone else, of course, would just ignore you from that point on as you have stopped making sense. How about that network experience again?

And this business about the FTP server's state being tied to the connection should be stated as: the FTP protocol is a connection-oriented protocol. It requires the connection, of course, but the state maintained by the protocol is above that layer. The specifically FTP state consists of things like the arguments to the USER and CWD commands, or the response to the PASV command, etc.

If FTP were stateless, it would not matter at all that the connection is maintained. The commands to the Protocol Interpreter would have no relation to prior commands received. Period. (just like HTTP).
Re:as in all new directions... by DavidTC · 2005-12-09 02:51 · Score: 1

The FTP ISN'T FUCKING IMPORTANT. I was just making a point that sometimes what people think of as 'protocol state' is just 'two ends storing random information', and not part of the protocol. And what I described is completely legal for FTP to do. No server would, because that would be extremely stupid. It is, however, legal, because 'current directory' isn't specified as part of the protocol. Commands to set it and change it? Yes. Any requirements about this 'current directory or dataset' beyond accepting those commands? Nope.
The way to prove it wouldn't be legal is trivial: Quote the part of the RFC that says it isn't. But I've read the RFC and it is completely silent on what passed 'directories' mean, so much that it even recognizes they might not be directories. It has some ideas on what they could mean, but refuses to even promote them to the level of SHOULD.
And you almost grasp the idea of HTTP having state, by realize that FTP is connection-oriented. That is how it associates state with a specific entity.
Then you utterly fail to realize that there are other ways of keeping track of state besides the TCP/IP connection. This is rather obvious when you think about UDP protocols, like instant messaging ones, but somehow it keeps eluding you. State is merely the ability to tie incoming data to a specific entity the server has talked to before. Nothing more, nothing less. Some protocols require this, some protocols merely allow it, and some protocols have never heard of it, like DNS. (Technically, all protocols that use TCP require it on the TCP level for the duration of the connection, but that is provided by TCP and hence is not specificed in the protocol.)
And, incidentally, FTP is a rather hilarious example of tying state to the TCP/IP connection, considering FTP requires, duh, extra connections that also have that state. And which can persist after the control channel is logged out.

--
If corporations are people, aren't stockholders guilty of slavery?

Misleading by FortKnox · 2005-12-07 05:04 · Score: 4, Insightful

The article is about using AJAX on a webpage, but the biggest use of AJAX is on a web application.

Sure, putting ajax on the companies webpage may not be the best idea, but how often are you using bookmarks on gmail (a web application)? And if you want to print from gmail, it shouldn't be a print of the screen, but a specially built printable html page.

I think the article writer was focusing mostly on webpages where AJAX is clearly geared towards the web application developer.

--
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!

Re:Misleading by garcia · 2005-12-07 05:11 · Score: 4, Insightful

The article is about using AJAX on a webpage, but the biggest use of AJAX is on a web application.

Sure, putting ajax on the companies webpage may not be the best idea, but how often are you using bookmarks on gmail (a web application)? And if you want to print from gmail, it shouldn't be a print of the screen, but a specially built printable html page.

I think that pointing these things out NOW is a great idea being that AJAX is now one of the biggest buzzwords in the industry. With marketing and management raving about AJAX and demanding AJAX applications be put everywhere including locations they shouldn't be, I think it's about time someone put an article out there that describes the negative effect that AJAX applications could have on the web.

Hopefully more media outlets will start picking this up and not just touting the successes of AJAX. Remember, buzzwords = $$$ in the eyes of those that are clueless.
Re:Misleading by Anonymous Coward · 2005-12-07 05:16 · Score: 0

In the world I live in, web applications are server side code that generate web pages. Ajax (actually javascript) is useless for creating accessible web pages, that's hardly news.
Re:Misleading by Anonymous Coward · 2005-12-07 05:18 · Score: 0

I really think that's the point that Jakob misses. For some of the clients I deal with the web is an application deployment platform, not an information publication/retrieval system. If you're deploying applications the information publication/retrieval metaphor doesn't fit all use cases.

IMO the application platform aspect of the web browser and AJAX can really boost usability for the majority. Unfortunately the support for the browser as an application platform is really poor for the disabled, as Jakob points out.
Re:Misleading by Kelson · 2005-12-07 05:20 · Score: 1

Ironically, in the world I live in, web applications that can also take advantage of client-side logic when available are much easier to use than those that can't.
Re:Misleading by Anonymous Coward · 2005-12-07 05:36 · Score: 0

This "article" is a spoof on an earlier anti-frames article. You missed the point of the spoof, essentially recycling an older rant for a newer technology. The "article writer" wasn't focusing "mostly on webpages" but rather on keeping the text and style of the article as true to the original as possible.

It's funny, laugh.

I believe you are correct in your assertion that AJAX is much more appropriate for web apps vs. web pages.
Re:Misleading by owlstead · 2005-12-07 05:43 · Score: 4, Informative

"And if you want to print from gmail, it shouldn't be a print of the screen, but a specially built printable html page."

Funny you should say that, because the W3G specifically designed HTML so that it could be read from screen as well as printed on a printer (and other media like screen readers etc.). Same with CSS really. The whole idea that you should generate a special HTML page goes straight against this policy. I blame the current browsers for not doing a well enough job on printing HTML pages. If they had strictly sticked to HTML standards and recommendations for this, this should not have happened.

As for AJAX: the page *should* be printable as well. Just use the latest DOM and follow CSS guidelines and you should be OK. *IF* both sides implement HTML standards the way they are meant to be. Currently this only works well if you are an inhabitant of Utopia.
Re:Misleading by FortKnox · 2005-12-07 05:44 · Score: 1

Well... umm... I rehashed an old pro-frame spoof argument from the....
Sorry, I would normally try to talk my way outta this, but no way am I gonna say I support frames. ICK!
Yeah, I missed the spoof until after I posted. My bad.

--
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Re:Misleading by FortKnox · 2005-12-07 06:01 · Score: 3, Informative

I'm not suggesting that you can't print a gmail page, but I'm suggeting that if you want to print an email, you'd want to remove extra data that doesn't need to be on the page.
In other words, I want the email header along with the subject and body. No need to have my folder information and how many new messages on the printout.

--
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Re:Misleading by mrtrumbe · 2005-12-07 06:04 · Score: 1

To be fair, the distinction is arbitrary for many uses of "web applications." For instance, an image gallery based on a dynamic content management system would almost certainly be considered a web application by developers. But to the end user of the gallery, they would be browsing the gallery just like they browse static content on the web. And most users of that gallery would expect bookmarks to individual pictures in the gallery to work. If the gallery made heavy use of AJAX and broke bookmarking capabilities, this would clash with the user's (reasonable, IMO) expectations.
Just like any other application, a good web application should be designed to be intuitive to the end user. Breaking commonly used browser features in your web app is probably a really bad idea in terms of usability (or the perception of usability by the end user).
Taft
Re:Misleading by e4g4 · 2005-12-07 06:08 · Score: 1

I couldn't agree more. Ajax has its place - the web application. The problem with this article, as I see it, is that the author makes no mention of the web application - the data driven brother/sister of the website. Take - for example - gmail. Were it not ajax, i wouldn't even bother with it, i'd use my favorite mail program (mac os x mail, in my case) as a POP client. I personally hate most webmail, because it's slow and clunky - gmail does not have this problem only because it's an ajax application. So yes - while that dessert recipe website shouldn't use ajax (since I know you'd love to bookmark that creme brulee recipe), a recipe management website can and should use ajax - since it would allow for functionality that would be either impossible, or prohibitively clunky.

I'm a web developer, and after seeing what ajax could do, and seeing the many ways that people have used it, I started to integrate ajax elements into an education management web app that i've been working on. While, yes, ajax can be buggy, and yes, it can be hard to use, that doesn't mean you shouldn't use it. All it means is that you should develop your ajax applications carefully and revel in the fact that ajax has made a Flash-free stateful web application possible. Heaven forfend that web-application design move out of the hands of designers and back to the people who do software best: developers.

--
The secret to creativity is knowing how to hide your sources. - Albert Einstein
Re:Misleading by MikeFM · 2005-12-07 06:19 · Score: 1

Just to note.. the 'web page' interface has always sucked at things like going back, printing, etc that this article complains about. Ever since layout and form elements started getting mixed into content all this has been a shit fest. Ever tried printing HTML or viewing in with a screen reader (such as used for blind users)? It sucks! Moving towards CSS and XML has helped a lot and could do a lot more if more people would use them properly. In short HTML sucks but did well enough and was easy enough to use that it got the job done at the beginning - it's time to move on though.

I think the thing to keep in mind is that with AJAX you have to be even more careful to maintain an interface that is flexible and degrades cleanly. AJAX should be a transition stage away from the web page idea and a new cleaner system that sepperates content from interface. Load XML data from one resource and the interface from another and put them together to get a powerful tool. Interfaces should be changable more easily because of this. You can have a full blown application, a web app, and normal good old HTML pages all making the same information available in different interfaces.

--
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Re:Misleading by RustyTaco · 2005-12-07 06:22 · Score: 4, Informative

It's called a print stylesheet, they're usually populated with things like #sidebar { display:none; } so that the exact same page looks right when printed.
Re:Misleading by jacksonj04 · 2005-12-07 06:27 · Score: 1

XHTML and CSS is designed to fight back against using HTML as a formatting language - it isn't and was never really designed to be.

CSS3 (And quite a lot of CSS2) has plenty of new options for altering layout based upon the display media, all using a single XHTML page to provide the data to be presented. For example, it allows setting page headers and footers which appear on printed media only.

AJAX pages should present data using standardised CSS which is designed to be interpreted according to spec by the render engine. The fact you are using the A, J and X bits of the acronym should be irrelevant to the content since it *still* follows the CSS spec.

That said, it's the same as all things. Most so called 'web developers' just plug in random code without bothering to validate to spec. Combine this with the fact that a poorly written AJAX application can easily plug nonsensical tags into a page and thus confuse the render engine and you are left with a monument to how standards really should be enforced.

--
How many people can read hex if only you and dead people can read hex?
Re:Misleading by paskie · 2005-12-07 06:28 · Score: 1

So you will set those elements display:none in the CSS for media 'printer'.

--
It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams
Re:Misleading by thezippy · 2005-12-07 06:31 · Score: 1

Totally agree... AJAX's best use isn't just for slapping together a plain old webpage. If you get into development of web-based applications, though, the time and effort that the author whines about can be well worth the quality product you end up with. At least thems my thoughts... Charlie

--
"Crafting the finest in b-movie fare..." ~~ http://bmoviewriters.blogspot.com ~~
Re:Misleading by consonant · 2005-12-07 06:51 · Score: 0

With marketing and management raving about AJAX and demanding AJAX applications be put everywhere including locations they shouldn't be...

Yes! Website navigation using Flash is a Bad Thing (TM)!

The new Napster ad and Crimson Room are about the only decent things ever done with Flash. Oh, and Badger, Badger...

--
[Slashdot Comments We Liked]
Re:Misleading by Lagged2Death · 2005-12-07 07:51 · Score: 1

The article is about using AJAX on a webpage, but the biggest use of AJAX is on a web application ... I think the article writer was focusing mostly on webpages where AJAX is clearly geared towards the web application developer.

The way I read it, the article is making the point that most "web applications," including the newfangled Ajax sort, break the web-page paradigm. Objections along the lines of "but - but - but - it's different for web applications!" is to miss his point entirely. He's saying things damn well shouldn't be different for "web applications." From the article:
The fundamental design of the Web is based on having the page as the atomic unit of information, and the notion of the page permeates all aspects of the Web ... 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.

Don't get me wrong, I loves me my del.icio.us and my Flickr, but I can see that Nielsen's got "Web 2.0" dead to rights on this point anyway.
Re:Misleading by doormat · 2005-12-07 08:39 · Score: 1

Have you ever printed an email from g-mail? You click the print link at the right and you get a new window with just the email - no folder information or stuff like that.

--
The Doormat

If you're not outraged, then you're not paying attention.
Re:Misleading by CagedBear · 2005-12-07 09:21 · Score: 1

AJAX is now one of the biggest buzzwords in the industry

Thank God. I was getting awfully tired of XML being the biggest buzzword in the industry.
Re:Misleading by ihandler · 2005-12-07 10:05 · Score: 1

I agree wholeheartedly. We are putting out applications for parents to sign up their children for health insurance (in the state of Illinois). The ability to deliver this application over the web is a major advance for the state. Use of Ajax makes this much better for the user as well as the developer. Most of the issues that Jakob raises are irrelevant here which shows imho that he is out of touch with the way the use of the web is developing. His domain, usability in web pages, is shrinking as the actual usage of the web is increasing not only in users but in types of applications.

--
Ivan Handler
Re:Misleading by Anonymous Coward · 2005-12-07 11:12 · Score: 0

del.icio.us and Flickr work fine without javascript, they degrade gracefully. You don't get slideshows on Flicker without javascript, they could use a meta refresh but again that would break the back button but the site mostly works. The thing with Ajax and especially with Macromedia Flash, is that they are paradoxical to the intent of the web. I think there's a quote that highlights the other problem with Ajax...
Given a choice between dancing pigs and security, users will pick dancing pigs every time. -- Ed Felten
The popularity of Ajax is worrying because javascript is web security problem #1. Enjoy the pigs!
Re:Misleading by DavidTC · 2005-12-07 12:33 · Score: 1

The article is a spoof, and that's absolutely not true anyway.
Web 'applications' keeps getting used loosely here. An image gallery, unlike what was suggested a few posts back, is not an application.
However, the management interface of that image gallery could be one, where you change the order and add and delete images. There is absolutely no reason to bookmark in that, either, or be able to go 'back'. (Back where? Back to before you deleted that image? Is this a time machine now, where the data in the system depends on where you are in your history?)
If this is still confusing to people: Imagine this 'application' not on the net. Would it be a program where you open things up and manipulate them, like Excel, or a file manager? Is the purpose to manipulate data?
Or is it single use only, like an IM window, where the data shows up and goes away? Or a virus scanner, where you can't logically go to the 'middle' or 'end' of the data, because the data is new each time?
If not any of those, it's not a 'application', and there's no reason in hell to use AJAX.
Or is it more like a help file? Where you can certainly search, and do all sorts of stuff, but in the end, it's just people looking at data. That's not an application. It's 'just' a web site. (I say 'just' because, while it might be less 'cool', the data it provides is useful to more people total than a 'application' is.)
If the manipulation is limited to certain people, like admin, or a few unique circumstances or areas, like a CMS or a complicated preferences page or a chat box in a random site, then, by all means, use AJAX there, but keep the other pages normal.

--
If corporations are people, aren't stockholders guilty of slavery?
Re:Misleading by Lagged2Death · 2005-12-08 05:25 · Score: 1

However, the management interface of that image gallery could be [a web application]... There is absolutely no reason to bookmark in that, either, or be able to go 'back'. (Back where?)

Sure, if you build the app so that all the management happens on one page, that could be OK. If you've got some page reloads in there (and a lot of web applications can't seem to avoid them) then you've got a place to go back to, all right. And if there is page navigation involved, then bookmarking (whether you see a reason for it or not) isn't inherently nonsensical, either.

And in my view, it doesn't matter whether going "back" makes sense; it shouldn't be possible for the user to break the app by pressing the wrong button. You wouldn't accept that kind of nonsense from a desktop app.
Re:Misleading by DavidTC · 2005-12-08 08:22 · Score: 1

Pressing 'Back' in an AJAX app doesn't break anything, and I have no idea how that rumor got started. At worse, it takes you back a page.
What it does not do is undo your last action, which is why AJAX must never be used for page navigation.

--
If corporations are people, aren't stockholders guilty of slavery?
Re:Misleading by Anonymous Coward · 2005-12-09 05:09 · Score: 0

I disagree slightly with print stylesheets. *Sometimes* I want to print just what I see, not what the author wants me to print.

That said, I do find it annoying that IE's broken printing requires many sites to have a "Print" button pointing to a specifically formatted page.

So I suppose my objection isn't to print stylesheets, but to the user agent (browser) that limits what can be printed to the print stylesheet.

Implementation by kevin_conaway · 2005-12-07 05:05 · Score: 5, Insightful

Its not the technology, its the implementation that causes those errors. You can misuse ANY technology to f things up. Why should this be any different?

Re:Implementation by Anonymous Coward · 2005-12-07 05:07 · Score: 5, Funny

You can misuse ANY technology to f things up.

This is the Internet. You can say "fuck" here.
Re:Implementation by helix_r · 2005-12-07 05:34 · Score: 1

Some things are easier to mess up than others.

The more complex something is, the more bugs you get, the more careful developers have to be, the more time they spend struggling with inspid issues, the less productive they are.
Re:Implementation by ThinWhiteDuke · 2005-12-07 05:45 · Score: 4, Funny

This is the Internet. You can say "fuck" here.

Yeah. Especially when responding to an article headlined "AJAX sucks..."

--

It would be nice to be sure of anything the way some people are of everything.
Re:Implementation by toggles · 2005-12-07 05:49 · Score: 2, Funny

This is the Internet. You can say "fuck" here.

I believe the correct terminology on the internet is "fsck".
Re:Implementation by CDPatten · 2005-12-07 05:53 · Score: 1

I agree. I have used ajax and implemented bookmarking and printing for any page/content a user views.

I had to think through the site architecture a bit more, and it took more coding (mostly javascript), but isn't that what ajax is anyways? More coding to give the user a smoother, faster, and pleasant experience... nobody (with any sense) said AJAX implemented right is easy, but that is why there are good programmers and then the majority of programmers. The whole purpose is about the end user experience, not the developers.

It would appear that the author of the article fits into the area of "the majority".
Re:Implementation by Anonymous Coward · 2005-12-07 06:40 · Score: 0

This is the Internet. You can say "fuck" here.

eh, f u bch.
Re:Implementation by HaMMeReD3 · 2005-12-07 06:42 · Score: 0

In the history of the internet, there has been languages that no matter how properly you program it, there will still be cross browser issues, bugs with implementation etc. Javascript and the original asp come to mind, is anyone forgetting that ajax IS javascript and ajax programming is not something for amatuers at all, since it IS javascript, which of all things is an unreliable, hard to program, hard to debug, language that behaves differently between every concievable browser on the market.

That said, I've been working with ajax to create a google maps web application, all things considered, I would not call it stable, or good, as of yet. It works flawlessly, but after some use my browser wants to die. Oh and it doesnt work fully in firefox.

Anyways, point is, ajax is not easy, and 90% of ajax applications will fail because they will not be written by professionals, it's a good approach and elegant when it works, but it's still a hassle and a pain in the ass to do everything in JAVASCRIPT.
Re:Implementation by Arandir · 2005-12-07 07:14 · Score: 3, Funny

You can also say "flbgrtyu", but why would you want to?

--
A Government Is a Body of People, Usually Notably Ungoverned
Re:Implementation by Carthag · 2005-12-07 07:57 · Score: 1

Everybody knows that in that context, "f" means "fuck", so why not just say it? It already popped up in everybody's mind, so it's not like he's sparing us from anything.
Re:Implementation by elemental23 · 2005-12-07 09:32 · Score: 1

On Slashdot, maybe, but Slashdot is not the internet.

Or, I should say, Slashdot != the internet.

--
I like my women like my coffee... pale and bitter.
Re:Implementation by Anonymous Coward · 2005-12-07 11:14 · Score: 0

*shrugs* It doesn't pop into my head anymore, neither does "WTF" have that effect. Ahhh desensitisation
Re:Implementation by Mr2cents · 2005-12-07 11:25 · Score: 1

Everybody knows that in that context, "f" means "fuck", so why not just say it?

Tht mn jst svd me 4B on my mntly dnl quot. He shd be an ex to all of us!

--
"It's too bad that stupidity isn't painful." - Anton LaVey
Re:Implementation by Rimbo · 2005-12-07 12:21 · Score: 1

You can also say "flbgrtyu", but why would you want to?

I don't know... why did you just say, "flbgrtyu?" Why did I just say it? We each must have had a reason.

I wouldn't go that far by reverend_rodger · 2005-12-07 05:05 · Score: 3, Funny

I wouldn't necessarily say AJAX sucks, but I've foudn that Tide does, indeed, do a better job...

Re:I wouldn't go that far by Gumber · 2005-12-07 05:44 · Score: 1

Ajax is a cleanser. Tide is a clothes washing detergent.
Comet, on the other hand is/was an ajax competitor.
Re:I wouldn't go that far by boldtbanan · 2005-12-07 05:44 · Score: 1

On that note, how long until AJAX sues for trademark infringement?
Re:I wouldn't go that far by AJWM · 2005-12-07 07:10 · Score: 1

Ajax is (or was) also a laundry detergent. Remember the "stronger than dirt" ad slogan?

--
-- Alastair

I pull out the marshmallows..... by Anonymous Coward · 2005-12-07 05:05 · Score: 3, Funny

...to cook them via the upcoming flame war.

Re:I pull out the marshmallows..... by CoderBob · 2005-12-07 05:12 · Score: 1

I'll bring the chocolate and graham crackers. Anyone else wanna do the hotdogs?
Re:I pull out the marshmallows..... by GeorgeMcBay · 2005-12-07 05:24 · Score: 1

I pull out the marshmallows to cook them via the upcoming flame war.

Roll the dice to see if I'm getting drunk.
Re:I pull out the marshmallows..... by Kelson · 2005-12-07 05:39 · Score: 1

Where are the Cheetos?

ajax by rayzap · 2005-12-07 05:05 · Score: 5, Insightful

ROTFLMAO AJAX is no different than any other programming set of tools. If used correctly it rocks, otherwise it sucks. We use it a lot in our web application and it has provided us the ability to deliver greatly enhanced interactivity and reporting. It's kinda like the blind date that gets overly hyped. The reality will never match the hype even if she was pretty.

Re:ajax by Anonymous Coward · 2005-12-07 21:27 · Score: 0

ROTFLMAO AJAX is no different than any other programming set of tools. If used correctly it rocks, otherwise it sucks.

This is obviously untrue. "Programming set of tools" can be good or bad. They can be suck even if used correctly, and they can rock even if used incorrectly. They can encourage good coding practice, they can force you do use bad ones. They can facilitate certain designs, they can make it troublesome to use others. They can make simple things hard, and hard things simple.

It's not a binary matter. That's why we have different tools in the first place. That you're "ROTFLYAO" just because someone dares suggest that not all tools are created equal says far more about your understanding of programming practices than it does about AJAX.
Re:ajax by syousef · 2005-12-07 21:37 · Score: 1

ROTFLMAO AJAX is no different than any other programming set of tools. If used correctly it rocks, otherwise it sucks.

All programming languages, paradigms and environments are not created equal.

Make sure you use the right tool for the right job (don't try to use a hacksaw to hammer in a nail), but also make sure the tool's of good quality. Don't try to saw a piece of wood with a blunt rusty hacksaw circa 1960. Of course you're out of luck if that's all that's out there on the market.

I couldn't tell you if AJAX tools are up to snuff, as I haven't had the pleasure yet.

--
These posts express my own personal views, not those of my employer

It's a spoof by Sugarcrook · 2005-12-07 05:05 · Score: 3, Interesting

If you read the bottom of the article, you'll notice that it's a spoof and a simple rewrite about why frame suck most of the time.

Re:It's a spoof by sn0wflake · 2005-12-07 05:13 · Score: 1

If you look close in this thread you'll notice this post is a spoof ;)
Re:It's a spoof by smittyoneeach · 2005-12-07 05:15 · Score: 4, Funny

To paraphrase Karl Marx: History repeats itself, first as tragedy, second as XML.

--
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Re:It's a spoof by ivan256 · 2005-12-07 05:17 · Score: 4, Insightful

For what it's worth, the original was completely correct, and frames (mostly) died a quick death. Almost nobody uses them in new development anymore.
Re:It's a spoof by Kelson · 2005-12-07 05:18 · Score: 2

And, like the best satire, it raises good points. Careless use of AJAX does indeed have many of the problems raised, so careful planning and graceful degradation are -- as always -- the key to producing a usable site.

(At least now I know why I didn't see the headline come through on the mailing list. If I had, it woud have been one of the 25% of Jakob Nielsen articles that I actually read.)
Re:It's a spoof by DingerX · 2005-12-07 05:20 · Score: 4, Insightful

aye, and frames do suck most of the time, for the reasons specified. I am continually annoyed by those things. So I assume we're supposed to sit back and chuckle that "them naysayers are just like the luddites who said frames were bad". Frames still stuck, most of the time, even with a decade of workarounds to fix the broken functionality.
Re:It's a spoof by Kelson · 2005-12-07 05:22 · Score: 1

Yep. There's a reason that the use of frames has dropped dramatically on the web over the past 5 years or so.
Re:It's a spoof by raddan · 2005-12-07 05:23 · Score: 1

And like the original article, it points out some real problems.
Re:It's a spoof by shawn(at)fsu · 2005-12-07 05:25 · Score: 1

This is the ulitmate did you even RTFA story. Looks like the editor and the submitter fell for it too.

This is great.

--
500 dollar reward for tip(s) leading to the arrest of the person(s) who stole my sig.
Re:It's a spoof by Anonymous Coward · 2005-12-07 05:36 · Score: 1, Informative

tell that to Advanced Access. They still have several "new websites" (I use the term VERY loosely) that they develop that use frames.
Re:It's a spoof by Anonymous Coward · 2005-12-07 05:40 · Score: 0

AIM? Is that you?
Re:It's a spoof by BarryNorton · 2005-12-07 05:45 · Score: 1

This is the ulitmate did you even RTFA story. Looks like the editor and the submitter fell for it too.
This is the real point - the article may be interesting, but the Slashdot 'process' doesn't even understand how or why.
One mindless ignorant summary, with no editorial standards applied, after another. And those of us with our own small areas of insight to share just give up, after our carefully written stories are repeatedly turned down in favour of 'zOMG, New Minor Version of Firefox Released' and 'Microsoft Have Patent On Breathing'
Re:It's a spoof by drinkypoo · 2005-12-07 06:22 · Score: 2, Insightful

Yeah, we got CSS allowing us to use absolute positioning, and iframes allowing us to have floating frames. Consequently, there are few times when you would want to use frames any more...

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Re:It's a spoof by Anonymous Coward · 2005-12-07 17:27 · Score: 0

CSS and iframes didn't fix the "static menu changing pages" problem you ignorant slut
Re:It's a spoof by CyricZ · 2005-12-08 15:23 · Score: 1

I've said for a while now that you should start your own Slashdot-style site, Barry. You're a man of academia, and you know your material. Your writing style has flair, and people would visit such a site on a daily basis.

Go for it, Barry!

--
Cyric Zndovzny at your service.
Re:It's a spoof by Anonymous Coward · 2005-12-09 05:23 · Score: 0

Frames are annoying from the user perspective. I think that's the main reason.

Plain users don't even know what AJAX is. But they like nice crafted and usable sites. If AJAX allows that then it's good.

Plain users don't navigate with a reference book on web standards on their laps.

Microsoft? by takkaria · 2005-12-07 05:06 · Score: 4, Interesting

"... offers a critical view at the new Microsoft technology ..."

It doesn't appear to be new, and it doesn't appear to be Microsoft's anymore, either.

Re:Microsoft? by Anonymous Coward · 2005-12-07 05:17 · Score: 0

Well, it was MSs in the same way that all relational DBs are nothing more than a filesystem.
Re:Microsoft? by Anonymous Coward · 2005-12-07 05:26 · Score: 0

Only the actual buzz word "AJAX" is new. The parts of AJAX have been in place long ago. But because there's finally a buzz word for the technology, it's all of a sudden the latest craze. The exact same thing can be said about "blogs" - online journals have been around forever; "podcasts" - online radio has been around forever; "ipods" - mp3 players have been around forever, but only now do you see everybody (non-tech savvy people I mean) with them (and most of the time it is actually an iPod).

And it most certainly is NOT and NEVER WAS a Microsoft technology. Microsoft has nothing to do with the new widespread adoption of AJAX. This comment in the article really really bothers me. Microsoft deserves absolutely no credit for things they had nothing to do with. Everyone knows it was Jesse James Garrett from Adaptive Path who coined the term AJAX. And it's quite clear that Google (maps and mail) is the main reason for the widespread adoption.
Re:Microsoft? by loconet · 2005-12-07 05:34 · Score: 1

The article talks about how much this technology "sucks" and why it's not good to use it. Ofcourse we have to associate ajax with Microsoft this time.

You must be new here.

--
[alk]
Re:Microsoft? by generic-man · 2005-12-07 05:36 · Score: 1

Microsoft invented "AJAX" when they created Internet Explorer 5. It's only been a buzzword since Firefox and Google started supporting it.

--
For more information, click here.
Re:Microsoft? by amliebsch · 2005-12-07 05:40 · Score: 5, Informative

And it most certainly is NOT and NEVER WAS a Microsoft technology. Microsoft has nothing to do with the new widespread adoption of AJAX. This comment in the article really really bothers me. Microsoft deserves absolutely no credit for things they had nothing to do with.
Correct me if I'm wrong, but didn't Microsoft invent XMLHttpRequest? In which case, most AJAX, which uses XMLHttpRequest, is in fact built on Microsoft technology, and they deserve credit for having a played key role.

--
If you don't know where you are going, you will wind up somewhere else.
Re:Microsoft? by clear_thought_05 · 2005-12-07 05:48 · Score: 5, Informative

You are correct. It was first Microsoft's idea.

Microsoft first implemented the XMLHttpRequest object in Internet Explorer 5 for Windows as an ActiveX object. Engineers on the Mozilla project implemented a compatible native version for Mozilla 1.0 (and Netscape 7). Apple has done the same starting with Safari 1.2.

http://developer.apple.com/internet/webcontent/xml httpreq.html
Re:Microsoft? by croddy · 2005-12-07 08:40 · Score: 1

There is a difference between Microsoft playing a key role in the development of a technology, and something being a "Microsoft technology". An example of a "Microsoft technology" would be ActiveX or COM -- something created entirely by Redmond developers that relies on Microsoft products for effective development and use.
No Microsoft products are involved in most AJAX development, and they're certainly not a prerequisite.
Re:Microsoft? by hutteman · 2005-12-07 08:55 · Score: 1

Of course it's Microsoft Technology - who else should the slashdot community blame for technology that sucks? surely not the previous owner of everything Ajax - they're not evil.
Re:Microsoft? by drew · 2005-12-07 09:14 · Score: 1

Most current AJAX applications use XmlHttpRequest, but XmlHttpRequest is not required to develop AJAX applications, and AJAX (minus the name) was around long before XmlHttpRequest.

--
If I don't put anything here, will anyone recognize me anymore?
Re:Microsoft? by SimonInOz · 2005-12-07 10:42 · Score: 1

I wrote AJAX-style web aps long before xmlhttp existed. (I did it by maintaining a constantly open connection in a frame, with periodic refereshes. Doesn't scale well, but brilliant for intranet apps - you even get dynamic updating for free. Bit annoying bevcause you get an hourglass all the time - but it worked well. Changing to use xmlhttp took an hour or so. Wonderful).

Microsoft DID invent xmlhttp - and it was great idea (not all Microsoft's idea - and this actually WAS one, as opposed to a copy - are bad). It was copied by Mozilla and Opera. That's great too!

"AJAX sucks." A complete lift of "Frames Suck", as anybody who read TFA would know (hint, you have to read right to the end before commenting). This is Jakob Nielson, remember, espouser of a completely static web - no page should ever go away, dynamically generated pages are evil, no web page should need scrolling, etc. Have you READ his stuff?

AJAX is brilliant for web apps. It's hard to write, but very neat. It makes the web site feel like an application. Users like that. Used as an impemtation framework, it reduces the client side install to - enter the URL. And that's it, no updates, no installs, no concern with compatability (not much, anyway - cerainly any modern browser will do the trick nicely - IE, Firefox, Opera, Linux, Windows, Mac, who cares? Wonderful).

It's not good for stuff that needs to be searched - no it's not, but do you really want people searching your - say - bank transactions? That's sily. Horses for course (or as my wife says, sauces for courses).

Enough. I have to get back to writing my evil AJAX systems. (No sign of Microsoft there).

--
"Cats like plain crisps"
Re:Microsoft? by HelpfulPete · 2005-12-07 10:50 · Score: 1

I was doing stuff like this before XMLHttpRequest, and I'm sure many others were too.

BY IMAGE SWAPPING - use javascript to dynamically construct a URL and assign that as the source for an existing 1x1 px blank gif, passing information to a cgi in the process (cgi returns same blank gif)

document.images['spy'].src = "http://site.com/trade_data_for_gif.cgi?name=" + document.forms['daform'].elements['name'].value;

This is very interesting to run every second or two on a large text field; later you can watch a "movie" of people typing, erasing, spellchecking, etc. Very interesting to see the stuff they decided to erase rather than sending :-p

Of course, the image swap method isn't much good for getting data back from the server (though there are some kludgy ways), so -

Use frames (see? they're good for something!) - where one frame is hidden (zero height or width) and is full of scripts that monitor the main page and talk to the server.

For output to the user, I used textareas or (shudder) Netscape 4's layers, and had much of the same functionality that "AJAX" "invented".

--
"Society is like a stew. If you don't keep it stirred up, you get a lot of scum on top. " - Edward Abbey
Re:Microsoft? by GBWorld · 2005-12-08 01:49 · Score: 1

Ajax is not a Microsoft technology. Microsoft is currently creating an implementation for .NET, code named "Atlas", but it is not a Microsoft technology. But, this is SlashDot and a screed against Microsoft is the norm, even if they are not guilty as charged (even when the linked site has no mention of the evil empire). :-)

Ajax is also not horrible. Would you say "hammers suck" because you needed to cut a hole in a door frame? Ajax's largest flaw comes from its environment and is out of its control (aka, it works in a browser). When you work with a stateless environment in a program you have very little control over, the developers of the product (browser) have to envision a lot. Their psychic skills, in this instance, suck horribly. Ajax is ahead of the browsers right now. Will they catch up? Who knows.

The problem with most Ajax samples/applications is an incorrect use of the technology. Developers stuck on "kewl" mentally masturbate out horrible architecture.

"Hey, we can use ajax as our data transport".
"Yo man, that would be so kewl!"
"Yudda man!"

Blah! Blah! Blah!

Ajax is great for certain types of usability features. We currently use it on an application that allows a user to put in a city. Unfortunately, we cannot key this to zip code, due to the users being set in their ways, so we provide them a list as they type (google type). Yeah, it is a major kludge, but it stops the users (most of the time) from putting in Nshville for Nashville. It also reduces data clensing. Now, it would certainly be better to design the application correctly, but we have no choice due to previous dev manager's and business analysts choice to create kewl rather than fight the users on their shortsidedness (wanted to say stupidity, but I decided to be nice).

Is Ajax guilty of the things mentioned? Heck yeah! Many of the problems are mitigated when used correctly, however. And, others may or may not be an issue in your application.

Ajax will either take off or die. I am seeing a lot of it lately (mostly bad implementation), so I assume it will take off.

RTFA by LordBodak · 2005-12-07 05:06 · Score: 2, Informative

Right at the bottom:

This is a spoof article. Please compare it with the original and you will see how little it has been changed.

--
LordBodak's journal.

Not a MS Technology by blaster151 · 2005-12-07 05:06 · Score: 2, Informative

AJAX is not a Microsoft-specific technology. My understanding is that Microsoft has an AJAX implementation called Atlas, but that AJAX itself is a set of conceptual ways of blending existing technologies to provide more interactivity to users of web apps.

Re:Not a MS Technology by WindBourne · 2005-12-07 05:21 · Score: 1

Next you will tell us that MS did not develop the Internet!

--
I prefer the "u" in honour as it seems to be missing these days.
Re:Not a MS Technology by CaymanIslandCarpedie · 2005-12-07 05:28 · Score: 1

No its not Microsoft specific, but I think they were refering to MS as creator of it. MS began using AJAX in the early 90s I think (of course without the cool new buzz-word) and was made possible by thier extenion "HttpRequest" (don't quote me on that as I'm not a web developer but I'm pretty sure thats the command) to the existing commands. This new HttpRequest was created to support Outlook Web Access (which I believe was the first "AJAX" application). Now I'm sure others can give a better history of this, but thats why its sometimes refered to as MS technology.

BTW, HttpRequest (AJAX) was just another example of that EVIL "embrace and extend" of MS ;-)

--
"reality has a well-known liberal bias" - Steven Colbert
Re:Not a MS Technology by slackmaster2000 · 2005-12-07 05:37 · Score: 2, Informative

True enough. According to the wiki:

"Like DHTML, LAMP, or SPA, Ajax is not a technology in itself, but a term that refers to the use of a group of technologies together. In fact, derivative/composite technologies based substantially upon Ajax, such as AFLAX, are already appearing."
Re:Not a MS Technology by Anonymous Coward · 2005-12-07 05:46 · Score: 0

More specifically.. Microsoft first came up with XMLHttp. This was then adopted into other browsers such as Mozilla. Check it out the wiki here. http://en.wikipedia.org/wiki/XMLHttpRequest. The snazzier combination of XMLHttp, DHTML, and Javascript which had been popularized recently by companies like google give rise to the term AJAX.

Jokes often become "common knowledge" by RugRat · 2005-12-07 05:07 · Score: 1

offers a critical view at the new Microsoft technology

You know, a lot of people will read this and not understand that it's a joke. If five years from now, the general population thinks that it is a MS technology, we'll know where it started!

Re:Jokes often become "common knowledge" by killercoder · 2005-12-07 05:20 · Score: 5, Informative

Ummmmm, I hate to do this - god I hate to do this, but I'm actually going to support MS on this one.

The paradigm of Ajax: "The transfer of XML to a web page in the background so that javascript can load data/initiate actions without loading a new page" was in fact a Microsoft innovation. They shipped it with Internet Explorer 4 and the first packaged MSXML controls.

I was writing applications of this type over 7 years ago targeted at Internet Explorer 4. The latest incarnation of AJAX still uses the MSXML parser on IE Browsers, but extends the support to FireFox and Netscape variants.

Please note, Microsoft did not coin the term AJAX, but they did do it first.

I know I'm going to hell for this.
Re:Jokes often become "common knowledge" by christoofar · 2005-12-07 05:52 · Score: 1

I am going to counter that a bit... some.

Launching the MSXML parser in COM with the tag and/or using jscript/vbscript on the page was the equivalent of doing the same thing as playing with an APPLET with Javascript.

And yes, you could back in the IE4 days get into the data within the applet using javascript (applet was coded to hit a service on the web server), update the data and use it as a "hole" in the page to get back to the server without refreshing _BEFORE_ MSXML made it easier. I did use both techniques, since applets didn't have XML DOM parsing in the foundation classes, using string split() and touching the applet's methods was a bummer.
Re:Jokes often become "common knowledge" by ergo98 · 2005-12-07 06:41 · Score: 1

Launching the MSXML parser in COM with the tag and/or using jscript/vbscript on the page was the equivalent of doing the same thing as playing with an APPLET with Javascript.

You could also use an IFRAME or remote scripting in IE to do this. Remote scripting was a Microsoft thing, and I believe Microsoft unilaterally "invented" IFRAMEs as well (a variation of a Netscape Layer). Nonetheless, what people call AJAX today is nothing more than a cross-platform clone of XMLHttp. Thus it is entirely true that Microsoft "invented" it.
Re:Jokes often become "common knowledge" by Mistshadow2k4 · 2005-12-07 09:14 · Score: 1

I know I'm going to hell for this.

Give Bill Gates a kiss for all of us /.ers when you meet him down there.

J/K... sorta. But it is (sigh) true that they did do that first.

--
I dream of a better world... one in which chickens can cross roads without their motives being questioned.
Re:Jokes often become "common knowledge" by Bogtha · 2005-12-07 09:33 · Score: 1

The paradigm of Ajax: "The transfer of XML to a web page in the background so that javascript can load data/initiate actions without loading a new page" was in fact a Microsoft innovation. They shipped it with Internet Explorer 4 and the first packaged MSXML controls.

I was writing applications of this type over 7 years ago targeted at Internet Explorer 4.

While an early version of MSXML was included in Internet Explorer 4, it didn't include XMLHttpRequest or XML data islands. That came later, with Internet Explorer 5.

--
Bogtha Bogtha Bogtha
Re:Jokes often become "common knowledge" by mrsbrisby · 2005-12-07 10:12 · Score: 1

Ummmmm, I hate to do this - god I hate to do this, but I'm actually going to support MS on this one.

Ummmm, why?

I wrote Netscape 3 applications that performed asynchronous javascript very well- far better still even than Microsoft's broken MSXML control. There's no reason that they couldn't have been made to work with Netscape 2 (although not quite as transparently).

Five minutes of looking elsewhere in the comments of this news and you'll find others who have done it as well.

I mean, you weren't there, so what the fuck do you think gives you the right to write history about it?

Huh? by Anonymous Coward · 2005-12-07 05:07 · Score: 0

at the new Microsoft technology

I seem to recall AJaX existing long before MS decided to jump on the bandwagon. How is it suddenly a Microsoft technology? I suppose next you'll be saying MS invented the Internet (rather than trying to wipe it out) and invented multimedia (rather than trying to wipe out the first truly multimedia machine, the Amiga).

Re:Huh? by amliebsch · 2005-12-07 05:13 · Score: 2, Informative

How is it suddenly a Microsoft technology?
IIRC, Microsoft did in fact invent the async XML transport functions that underlie much of the "magic" of AJAX, way back in the late 90's.

--
If you don't know where you are going, you will wind up somewhere else.
Re:Huh? by Anonymous Coward · 2005-12-07 05:18 · Score: 0

MS created that bandwagon. MS did not invent AJAX, but they were pushing its concept way before it was a fad. Funny thing is, when MS was pushing it, everyone said its a typical stupid MS idea.
Re:Huh? by PepeGSay · 2005-12-07 05:18 · Score: 1

How is it suddenly a Microsoft technology?

Duh! This article is talking about the bad points of Ajax, therefore they call it a Microsoft technology.
Re:Huh? by AlphaSys · 2005-12-07 05:22 · Score: 1

How is it suddenly a Microsoft technology
Since there was something negative to say about it.

--
Can I bum a sig? I left mine at the office.
Re:Huh? by duffbeer703 · 2005-12-07 05:42 · Score: 1

Microsoft cooked up XMLHttpRequest for OWA a long time ago... once Firefox started supporting it, people started using it, and some dopes trying to sell books started calling it AJAX.

--
Conformity is the jailer of freedom and enemy of growth. -JFK
Re:Huh? by DavidTC · 2005-12-07 12:53 · Score: 1

How they did it was stupid. They had an ActiveX object, and did weird-ass things like connect datasources to controls without any Javascript, neither of which is a very good idea. It was a typical MS lock-in attempt.
It's just, coders at other browsers said 'Hey, you know, that 'get and send XML data asychronously in and out of javascript' is kinda cool idea, let's add a way to do that too'. And they did, and it was made part of the standard, and webpages actually started using it.
It is a pretty nice, and incredibly useful extension to Javascript, and MS deserves credit for it, even if their first implimentation was somewhat crummy (Their whole 'activex' thing is somewhat crummy.) and it was their typical emprace-and-extend stuff. (I mean, iframes were the same thing, and those are nice too.)
Of course, it wouldn't exist at all without client-side scripting, which is a Netscape invention. ;)

--
If corporations are people, aren't stockholders guilty of slavery?

Right tool for the job by squoozer · 2005-12-07 05:07 · Score: 1

The problem with AJAX is not with the technology it is, as is often the case, with the people using it. It's the current big new "thing" and some people will insist on using it everywhere they can. Look how many sites appeared that were pure flash when flash was the big new thing. There aren't as many now and those that are almost always offer a html version.

I am sure that there are some really nice things that can be done with AJAX. We just need to find out what it's good at and what it isn't so good at.

Personally, I won't be using AJAX for a long while yet. As a lone developer I feel that client side scripting is too expensive to develop in terms of time. It's much easier to just use plain old (X)HTML and CSS on the client side even if that means a slight increase in complexity server side. Well that's my 0.02 anyway.

--
I used to have a better sig but it broke.

Re:Right tool for the job by Qzukk · 2005-12-07 05:27 · Score: 1

Really, the problem with AJAX is that many of the developers and their users are trying to mix an "application" design paradigm with a connectionless browser design paradigm. AJAX breaks "back"? Of course it does. Applications don't have a "back" button, they have an "undo" button, and it performs a completely different operation from what the browser does when you hit back. If AJAX application developers want to not confuse their users, they force everything into a new window with no control bar, and provide undo buttons of its own. Of course it breaks bookmarking as well. Do you have a "bookmark" for the paragraph formatting dialog in Word? I thought not. Why should we care if Google can index it? Does google crawl World of Warcraft interfaces? I didn't think so either.

The author has clear gripes with the misuse of AJAX, but his claim that it should be banished to "Web2.0" companies and kept in permanent beta, never to be fed after midnight is a bit harsh for a technology that does one thing and does it well.

--
If I have been able to see further than others, it is because I bought a pair of binoculars.
Re:Right tool for the job by Woldry · 2005-12-07 05:46 · Score: 1

Do you have a "bookmark" for the paragraph formatting dialog in Word?

One could only wish ...

--
How can a post be modded "overrated" or "underrated" when it hasn't been rated yet?

OSS software is superior in all ways by Anonymous Coward · 2005-12-07 05:07 · Score: 0

Look at all the eyes looking over the source code!!!!
Look att the eyeessss!

Every AJAX downloader is a potential AJAX developer!!!

How can M$$$ HOPE to compete!!!?!?!?!

Improving web accessibility? by saskboy · 2005-12-07 05:08 · Score: 2, Insightful

"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."

Wouldn't it be nice if Frontpage or Mozilla Composer would allow a plain HTML page to be saved and linked along side one with javascript, flash, and other advanced web designs?

It really annoying too how Tab-clicking at javascript link ends up producing a blank tab in Firefox. That AJAX breaks the Back button is nothing new too. All sorts of sites tell you that you'll be re-submitting data if you press Back on a screen you've just sent information from. That's essentially a broken Back button. And printing a webpage? Good luck if it isn't plain HTML.

--
Saskboy's blog is good. 9 out of 10 dentists agree.

Re:Improving web accessibility? by Kelson · 2005-12-07 05:36 · Score: 1

Wouldn't it be nice if Frontpage or Mozilla Composer would allow a plain HTML page to be saved and linked along side one with javascript, flash, and other advanced web designs?

The problem there is that the editor has no way to know what your fallbacks are going to be. Let's simplify it by looking at images. Images are supposed to contain an ALT attribute with text to display if the image cannot be displayed (broken link, text-only browser, images disabled, whatever). But the editor can't reliably come up with useful text to put there. It could make a guess based on the filename, but IMG0437.JPG isn't particularly informative.

Same problem with frames, Flash, JavaScript, etc. The editor doesn't know what to substitute unless you tell it. "This page requires Frames" or "Please download Flash" are about all that can be determined programmatically.

Plus it's better in the long run if you can pack your alternative content into the same HTML document. That way there's only one location to worry about -- and one file to keep current -- and you don't need extra logic to redirect visitors based on the featureset of each browser at the moment you last checked them.

Nielsen? Never mind. by Anonymous Coward · 2005-12-07 05:08 · Score: 1, Insightful

I was interested in reading the article until I found out it was by Jakob Nielsen. If it were up to that guy the web would be stuck in 1995.

I am a strong proponent of usability and user interface issues, but this guy doesn't even like using different colours for links.

What does interest me is he makes a lot of money by going around telling people this. I want to get in on that action.

Re:Nielsen? Never mind. by netean · 2005-12-07 05:13 · Score: 2, Interesting

Hear hear... have you seen his website... designed by blind donkey. http://www.useit.com/http://www.useit.com Hardly a good model for usable, effective web design.. But a shining example of the "usability" of the internet circa 1996

Easily solved by dmoore · 2005-12-07 05:08 · Score: 2, Informative

The AJAX problems with bookmarking and the "back" button are easily solved with some careful scripting.

Here's an LGPL'ed solution: http://www.unfocus.com/Projects/HistoryKeeper/

Re:Easily solved by aug24 · 2005-12-07 07:31 · Score: 1

Absolutely. In fact, the back button can be used programatically if you are clever enough. See google maps for an example of an Ajax app which still works perfectly woth the browser back button.

Justin.

--
You're only jealous cos the little penguins are talking to me.

Ajax is a Microsoft Tech? by squison · 2005-12-07 05:09 · Score: 0, Redundant

"The article at Usability Views offers a critical view at the new Microsoft technology" Really? Didn't know Microsoft made Ajax...

Re:Ajax is a Microsoft Tech? by Fred_A · 2005-12-07 05:26 · Score: 1

Well, they recently bought Procter & Gamble apparently.

--

May contain traces of nut.
Made from the freshest electrons.

Bugs, In a new language? No! Really? by Anonymous Coward · 2005-12-07 05:09 · Score: 0

I've worked in enough languages over the past 25 years that this is no surprise to me. It breaks, you work around it. Eventually they get the bugs worked out and someone looks through your old code and wonders why you did all these things some arcane hard way.

I'm sure CSS worked perfect initially. ;)

Suck is such a strong word but, they do and Ajax will be playing at Highbury later today.

Or are we talking about Ajax bub-bub-bub, the foaming cleanser?

Not always that bad. by MartinG · 2005-12-07 05:09 · Score: 5, Insightful

The web is used (rightly or wrongly) to deliver two distinct things.

1) Content.

2) Applications.

For (1) ajax _does_ suck most of the time for all the reasons stated, but for (2) is makes sense because it makes the app behave more like a desktop app. "back" and "bookmarks" stop making sense anyway. You wouldn't expect to have those features in your desktop apps, so why in an app delivered over the web.

The great shame is that these two opposing requirements have not forked into the data-web and the application-web. Things went wrong IMO the day someone thought of putting forms in html.

--
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz .@adgimnoprstu

Re:Not always that bad. by electroniceric · 2005-12-07 05:41 · Score: 4, Interesting

I'd mod you up, but I prefer to reply instead. This is very insightful statement, and I believe it's the basis of Jakob Nielsen's complaint. Web-as-content really is distinct from web-as-application. The web browser works beautifully for web-as-content, but is rather limited for web-as-application.

Now it happens that a web browser also has two excellent characteristics as a application deployment platform. One is that it is pre-installed nearly everywhere, so as long as you can get a coherent set of standards for what it provides and how it works, it's an outstanding application deployer. It basically enforces separation of UI from logic. The second is that the web was built on an asynchronous protocol, which builds in excellent network resilience. Applications that go over a public network like the Internet must fundamentally assume that the network is of variable and unknown quality, and work gracefully in those scenarios.

AJAX is basically a hack to get the content-oriented browser to work like a proper GUI toolkit. Why should a developer work with the document (note content orientation) object model, when every sane GUI toolkit builds on windows, widgets and event listeners? AJAX is necessary largely because of MS' squashing of Java as a viable network application platform, and because the Java-makers (i.e. Sun) have never prioritized geting a really performant, usable UI toolkit for Java into widespread use. In short, what you really want to build internet apps is a sandboxed deployment environment you know will be on every machine, and that defaults to asynchronous communication for network use. AJAX basically gets you there, but it ain't pretty. My hope is that once people get used to using Internet apps there will be momentum for getting that kind deployment environment on every machine.

PS: I know Javaheads are going to flame me for that one, but compare the comfort of using your average Java app to anything written in QT/KDE,GTK, MFC,.NET, etc. Why the hell is Swing only starting to work at the level that an app like Eclipse does, when QT widgets have worked smoothly and quickly?
Re:Not always that bad. by tpjunkie · 2005-12-07 05:42 · Score: 2, Funny

The web is used (rightly or wrongly) to deliver two distinct things.

1) Porn

2) Spam
Re:Not always that bad. by brauwerman · 2005-12-07 07:24 · Score: 2, Interesting

Back (aka Undo) is definitely needed in desktop apps and one of the main annoyances of webpages like google mail and google maps.

Bookmarks are equally important for content navigators (of which maps and mail are examples), and for this functionality google has gone to the effort to provide bookmarks (for maps) and stars (for mail).
Re:Not always that bad. by HumanTorch · 2005-12-07 07:24 · Score: 1

Unfortunately, it took me a lot of flame wars on alt.html before I realized this. Now, I pay more attention to GUI development guidelines than HTML development guidelines.
Re:Not always that bad. by Vo0k · 2005-12-07 08:06 · Score: 1

"back" and "bookmarks" stop making sense anyway.

"Undo" and "Save Project".
Click "undo" and have the state from before the last operation.
Click "save project" and the next time you load it, you have your workbench in the same state as the moment you saved it.

Both strongly lacking and helluva hard to implement in AJAX.

--
Anagram("United States of America") == "Dine out, taste a Mac, fries"
Re:Not always that bad. by owlstead · 2005-12-07 08:48 · Score: 1

"PS: I know Javaheads are going to flame me for that one, but compare the comfort of using your average Java app to anything written in QT/KDE,GTK, MFC,.NET, etc. Why the hell is Swing only starting to work at the level that an app like Eclipse does, when QT widgets have worked smoothly and quickly?"

Why would Javaheads like me flame you for that? Swing is not very widely accepted, even by Javaheads as you call them. Java applications -used to be- horendously slow. Now that's mostly over, but they still cannot provide the user with a consistent UI (since it is not consistent (and never will be) with the operating system settings. SWT, as used by Eclipse (and the Azureus bittorrent client), is not as clean as swing, but it understood at witch level it should interface with the host operating system. Considering the number of downloads of Eclipse, expect to hear more from SWT as time goes on.

I've long thought about a highly graphical XML interface description language bundled with Java bytecode for the logic. Together with a cache for storing commonly used parts, and running in a sandbox, it could really make for an excelent user experience. And anger Microsoft to no end of course.
Re:Not always that bad. by DavidTC · 2005-12-07 12:57 · Score: 1

In what universe would those be hard to impliment in AJAX?

--
If corporations are people, aren't stockholders guilty of slavery?
Re:Not always that bad. by dkf · 2005-12-07 23:57 · Score: 1

Why the hell is Swing only starting to work at the level that an app like Eclipse does, when QT widgets have worked smoothly and quickly?
Because Swing (and AWT and SWT) are slow and sucky. I like Java for server-side apps (there are some really nice libraries there) but Java GUIs all gobble memory for no good reason. The reason they're appearing to not suck so much now has got to be that you're only now getting enough memory that you machine doesn't start paging like fury when you do anything with a Java GUI...

--
"Little does he know, but there is no 'I' in 'Idiot'!"

I've been breaking the back button for years... by Wisgary · 2005-12-07 05:09 · Score: 1

...using stuff that has POSTDATA. Oh no! Come on, AJAX has no more or no less problems than any other set of tools. You just need to learn when to use which set. Sometimes AJAX is convenient, sometimes it's not, you use the one that's appropriate for the task. Stop the hate.

Re:I've been breaking the back button for years... by Anonymous Coward · 2005-12-07 05:20 · Score: 0

Use a redirect after post. That will fix your application.
Re:I've been breaking the back button for years... by Wisgary · 2005-12-07 06:39 · Score: 1

Googled that, thank you.

Microsoft technology? by Anonymous Coward · 2005-12-07 05:09 · Score: 0

I didn't know this was MS only technology... (it's not)

I talked about this last month by AutopsyReport · 2005-12-07 05:10 · Score: 0

I talked about these problems back in November in another AJAX thread here. There was a good followup, too. I think what I said still stands today.

"Until AJAX can be implemented with a tried-and-true method with absolutely no breakage in the traditional flow of movement between pages (being able to recycle data and regular page transitions using Back and Forward), there is no possible way that AJAX will become another requirement of web applications. As it stands, its a very popular trend, but it really isn't holding much weight despite what the average web developer may think."

--

For he today that sheds his blood with me shall be my brother.

Re:I talked about this last month by TrappedByMyself · 2005-12-07 05:15 · Score: 1

I talked about these problems back in November in another AJAX thread here [slashdot.org]. There was a good followup [slashdot.org], too. I think what I said still stands today.

You do realize that as of, ummm.... a week ago, it was still November. I know the technology changes fast, but jeez ;)

--

Help me take back Slashdot. When did 'News for Nerds' become 'FUD and Conspiracy Theories for Extremist Nutjobs'?
Re:I talked about this last month by RingDev · 2005-12-07 05:15 · Score: 1

AJAX is not ment to replace a well designed HTML site. It is designed to be a tool for web applications. If you replace the tried and true web navigation system with AJAX, yes, you will break the "tried and true" method. But if you use AJAX to keep on page data constantly updated (say like a stock ticker, statistics, logging, etc) where you only have one page, it will be a great tool.

Like everyone else say, if you use the wrong tool for the job, your going to wind up with crap.

-Rick

--
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs

Please not again! by PromptZero · 2005-12-07 05:10 · Score: 1, Interesting

AJAX may be the acronym du jour, but these techniques have been around for YEARS, ever since IE5. AJAX is just a simplified way of doing it, just like every programmer in the world creates their own little libraries of routines for handling db connections and the like. AJAX doesn't do anything new, it just repackages it for those who never heard of it.

When I first learned about XmlHttpRequest in the IE5 days, I thought it was going to revolutionize the web. All the problems of session state maintenance would disappear and web pages would become little client-server apps. MS had this capability first with the ActiveX control. They could have hyped this capability and taken the lead with it back in 1999. ASP.Net would have been another great opportunity to showcase this feature and create standards. Instead the ASP.Net philosophy seemed to be to make as many trips to the server as possible. For a while MS virtually abandoned the idea of out-of-band requests. So now, years after introducing this feature, somebody at Microsoft finally realizes what they had going and decides to jump on the bandwagon. Good job guys, but a little late.

Re:Please not again! by ryanelm · 2005-12-07 05:18 · Score: 1

as i observed it AJAX caught on when firefox, safari et al began supporting an equivalent system of http geting. i think really it was that noone wanted to write badass sites that would only work in IE then write another version for the rest of the world, belive me i figured out a way to do it back in the day with iforms but it was just too much of a hassle to figure out the best way to do it for all browsers. the method became popular when it became possible to sift out workable ways to do it on many browsers, and it'll get more popular when people figure out the best way to integrate it with the existing web gui paradigm.
Re:Please not again! by serutan · 2005-12-07 06:07 · Score: 3, Interesting

I agree 100% with the above post, because PromptZero cut and pasted most of it from one of my recent posts on this subject. I guess imitation is flattery.

The article makes some valid points about the Back button and Bookmarks, but these are problems that can be solved pretty easily. Microsoft no doubt would have solved them several years ago, had they seen the potential of the off-channel request technique and acted on it. But as one MS manager told me shortly before IE was released, with Netscape pretty much dead by that time they saw no point in developing IE any further. See how market dominance encourages innovation? I think Firefox now has native support for off-channel httprequests, whereas IE is still using an ActiveX control.
Re:Please not again! by SuiteSisterMary · 2005-12-07 06:42 · Score: 1

Instead the ASP.Net philosophy seemed to be to make as many trips to the server as possible. For a while MS virtually abandoned the idea of out-of-band requests.

Microsoft needed to be able to say "Look, ASP.NET isn't tied to the browser!".

--
Vintage computer games and RPG books available. Email me if you're interested.

oh wow by ryanelm · 2005-12-07 05:11 · Score: 1

Someone came up with one more hack to extend the functionality of HTML/JS and *GASP* developers arent using best practices. no way. Its almost like this whole web thing is one hack on top of another on top of a basic system not designed for the purpose it has been put to. The web is literally evolving and the genome representing 'AJAX best practices' just hasent been selected out yet. Its like the whole table vs div+style thing.

heh by BierGuzzl · 2005-12-07 05:11 · Score: 1

yhbt

Re:heh by Vo0k · 2005-12-07 07:59 · Score: 1

Actually IHBT.
Should have read the WHOLE article before clicking "submit". :)
Still, spoof or not, makes valid points :)

--
Anagram("United States of America") == "Dine out, taste a Mac, fries"

Same problems as with Flash by kill-1 · 2005-12-07 05:11 · Score: 1

These are exactly the same problems as with Flash movies. Basically it boils down to the fact that you can't address different "pages" of a website with their own URL. This fundamentally breaks the concept of the world wide web.

But like the poster above me said: For web applications AJAX is a viable solution. For web sites it should be used carefully.

And when it doesn't suck... by digitaldc · 2005-12-07 05:11 · Score: 2, Funny

...it totally blows.

--
He who knows best knows how little he knows. - Thomas Jefferson

Microsoft? by Tuffnutz · 2005-12-07 05:11 · Score: 1

What does AJAX have to do with Microsoft? The word 'microsoft' doesn't even appear in the article, as far as I can tell...

--

_ The bureaucracy is expanding to meet the needs of an expanding bureaucracy.

It's a spoof by lilo_booter · 2005-12-07 05:11 · Score: 1

Says so in the linked article (right at the bottom along with the original)

User's don't care by Billosaur · 2005-12-07 05:12 · Score: 1

I'm a user. All I want is the web page to load and to contain the information I'm looking for. Simple really. Does it matter what is used to generate the page? No. AJAX, XML, HTML, CGI... they're just tools for developers to use. AJAX has its place and if it's not the best tool, then either people will stop using it, figure out how to use it better, or it will be enhanced to work better. Why all the fuss?

--
GetOuttaMySpace - The Anti-Social Network

How did this get posted on Slashdot? by gasmonso · 2005-12-07 05:12 · Score: 1

I read the article and I am not impressed. The complaints are mostly trivial or nonexistent with proper coding and design. I especially like the bit about bookmarks...OH NO!!!! That's a deal killer for me. Obviously, AJAX is not the best tool for every situation, but when used correctly, the results are spectacular as seen in Google Maps, Yahoo Mail Beta, etc.

gasmonso http://religiousfreaks.com/

Get over it by WolfFang · 2005-12-07 05:12 · Score: 1

Can you bookmark in appliations? Hit the back button?

As a developer of internal corporate web applications, I've been using javascript and xml for years to create rich environments. My only complaint is that the browser does not go far enough in creating a powerful application layer. I would prefer to be able to completely disable the history on pages without using javascript hacks so that back took you completely out of the application and back to the previous web site. I'd like editable dropdown lists and other common widgets without using javascript hacks.

The browsers page based model is outdated, and the increase in support for ajax and other new frameworks is only a good thing for the web. Hopefully new browsers, or even a whole new class of browsers will overcome the limitations of the current generation. Only then will the browser begin to replace local applications in mass.

"Ajax".replace("Ajax","Flash") by TheGuapo · 2005-12-07 05:12 · Score: 1

"breaking bookmarking, making the 'back' button useless, problems with printing, accessiblity and more"

Remind anyone of Flash?

Re:"Ajax".replace("Ajax","Flash") by Kelson · 2005-12-07 05:25 · Score: 1

Funny you should say that, since the article basically took a real Jakob Nielson article and replaced the word "frames" with "AJAX."
Re:"Ajax".replace("Ajax","Flash") by Anonymous Coward · 2005-12-07 05:35 · Score: 0

That's the first thing I come back with when people bring up the history / bookmark thing. Pure Flash sites (as annoying as they are) seem to have caught on just fine with even worse issues than this (in that they typically destroy ANY sort of traditional web navigation patterns).

Still, a smart programmer can write a well designed AJAX app that makes appropriate use of the browser's history and bookmarking capabilities.
Re:"Ajax".replace("Ajax","Flash") by Anonymous Coward · 2005-12-07 06:03 · Score: 0

Pure flash sites are a joke -- its insanely obvious that the designers only have one hammer and intend to use it everywhere, back button be damned!

There are some good uses of flash, for example if a large retailer or gym had stores across the country they could present you with a map and you could scroll around in it. Course this can all be done with AJAX now ala google maps.

Flash by nmg196 · 2005-12-07 05:14 · Score: 5, Insightful

Nearly all of the problems cited in the article are present to a FAR WORSE extent with fewer workarounds if you write your website so it makes heavy use of Macromedia Flash. That includes problems with bookmarking, back button not working, no printing etc. Yet Flash is used on millions of major websites. As other posters mention, the problem is not with the technology but misuse of the technology.

Some flash developers get what I call "flash happy" and write the entire website in flash. This is lunacy. For a start, (and this is possibly a problem with AJAX heavy sites too) your site cannot be indexed by any search engines if it's navigation is entirely flash based. No search engine in the world is going to evaluate your flash files or run your AJAX scripts in order to attempt to crawl the site. If AJAX is used sparingly where necessary, then I'm pretty sure it won't cause any major problems. It's not like Flash seems to have suffered...

Re:Flash by pharwell · 2005-12-07 05:51 · Score: 1

your site cannot be indexed by any search engines if it's navigation is entirely flash based. No search engine in the world is going to evaluate your flash files or run your AJAX scripts in order to attempt to crawl the site.

Some folks like it that way.

--
I quote others only in order the better to express myself. -- Michel de Montaigne
Re:Flash by dFaust · 2005-12-07 05:53 · Score: 2, Interesting

When using Flash in the way that AJAX is meant to be used (typically for applications), Flash is actually far more mature. Problems with printing, bookmarking, etc. are all problems that both Macromedia and the Flash community have worked on for some time to rectify. As far as indexing, not something you really need or even want for an application. So, put blunty your "FAR WORSE extent with fewer workarounds" is bullshit.
Now, on non-application sites that are 100% Flash, it's a more valid concern. But again I call bullshit because in my experience the problems only seem to present themselves more often because I see more Flash sites, not because a larger percentage of Flash exhibit these problems compared to AJAX sites. But moreover, problems with the back button, bookmarking, and printing, at least, CAN be dealt with. Most of it without using a "workaround" or hack of any sort, but by using the capabilities of Flash that Macromedia has provided specifically to address these issues.

Now, that's not to say that page authors implement these capabilities. But that's their fault, not Flash's. You can create a steaming pile of poo with any technology, but I think it's a matter of exposure that leads many people to think Flash sucks. People see more pieces of crap written in Flash, so they assume Flash itself is crap.

So to sum up, before talking about how capable a platform is of dealing with a problem, it might help to know anything about the platform. Flash is, at present, far more mature when it comes to addressing many of these issues.

Note: this is not meant to be a pro-Flash rant, so don't take it as such. I'm merely correcting some statements made by the o.p. that I feel aren't entirely accurate.
Re:Flash by brassmoknets · 2005-12-07 06:13 · Score: 4, Insightful

No search engine in the world is going to evaluate your flash files
http://www.google.com/search?hl=en&lr=&safe=off&q= filetype%3Aswf+contrary+evidence
Except perhaps...er... what was the name of that search engine...you know...er...
Re:Flash by nmg196 · 2005-12-07 07:41 · Score: 2, Informative

Read my post again!

Yes, of course google can index PDFs, Flash, Images etc, but in the context of navigation it's pretty useless. Google does NOT know how to click buttons in flash files. Therefore if your navigation is done entirely in Flash, Google will not crawl your site. The reason I know this is because I do a lot of work in Search Engine Optimisation. Clients come to us and say "why I can't I find my products by using google". Usually it's because a flash-happy designer has made all the fancy navigation drop down menus in Flash and google hasn't been able to follow links from within the flash to the other flash content or even static pages.

It's one thing to be able to rip text out of a raw SWF file, but its another thing entirely to for Google to actually understand what the point of the flash file is, understand any embedded heirarchy and follow links within the file. I expect Google will never do this unless Macromedia specifically make it easier for them to do so.
Re:Flash by nmg196 · 2005-12-07 07:53 · Score: 1

> Problems with printing, bookmarking, etc. are all problems
> that both Macromedia and the Flash community have worked on for some time to rectify.

I work with Flash quite a lot and I've seen no solutions that let you bookmark flash files properly without lots of workarounds (or "appauling hacks" as we call them in our software house). I would be greatful if you could show me an example of how you can bookmark a 100% flash site without using lots of time consuming hacks.

If it really WAS easy to deal with issues such as bookmarking and printing, then why does nobody seem have done it at all? Please post a link to any major site where bookmarking and printing work properly.

I'm not so incredibly rude as to "call bullshit" as you say but I also doubt your statements as you have not included even one example as proof.

> So to sum up, before talking about how capable a platform is of dealing with a problem,
> it might help to know anything about the platform. Flash is, at present, far more mature
> when it comes to addressing many of these issues.

Explain how then... I presume you don't know or you would have given at least one example.

The example code I've seen always entails HORRIBLE hacks such as reloading the page to modify the URL or specifically trying to detect a crawler using the user agent string and then behaving differently. Some articles on Macromedia's site even involve installing 3rd party products and URL rewriters whcih I would hardly call a mature solution - just more hacks.

The only solution would be for flash to be natively bookmarkable in the same way that HTML is with no extra work by the developer required. It would have to have some kind of internal notion of "pages" or "points in time" in the case of a movie/presentation which somehow makes it back to the URL without a reload.
Re:Flash by Anonymous Coward · 2005-12-07 12:56 · Score: 0

If it really WAS easy to deal with issues such as bookmarking and printing, then why does nobody seem have done it at all? Please post a link to any major site where bookmarking and printing work properly.

OK, here's an example of how to do it, along with full source code:

http://www.klynch.com/apps/flashlinking/index.html #id=1
Re:Flash by nmg196 · 2005-12-09 01:11 · Score: 1

I normally never bother replying to Anonymous Cowards as they will probably never see my reply, but for the benefit of others;

That's a perfect example of an "appalling hack" that I was talking about. If bookmarking even vaguely worked properly, you shouldn't need ANY sourcecode.

That source code shows an extremely trivial example and yet still requires lots of code to make it work. Hardly a usable solution in a large website.

Remember the frames debate? by stm2 · 2005-12-07 05:14 · Score: 1

I didn't RTFA yet, but I think this is the same complain as HTML frames (no back button, no printing, no bookmark correctly...). (there is even a no frames campaign, looks as a 1997 web page!) I think that if you are looking a web page as just a "page", yes, the author is right, AJAX suck. But if you see it as a web app, you should evaluate it as an app, not as a web page. In a typical app, you use provided buttons, print with provided menu (like Gmail) and so on.

--
DNA in your Linux: DNALinux

Re:Remember the frames debate? by mooingyak · 2005-12-07 05:50 · Score: 1

Good guess. The article is actually a spoof on the frames debate of 97. He offers a link to a very similarly worded article from that debate that he used as his template and mostly swapped out "frames" for AJAX.

--
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.

Javascript overused by Foofoobar · 2005-12-07 05:15 · Score: 1

I've told people time and again that client side programming is only useful for display. Any scripting that can be turned off and make your applications useless or insecure is potentially a danger.

Sure, checking data before it is sent is nice but validating data is incorrect since that data can be changed without the script and sent to the server.

AJAX is just the latest craze like FLASH was and it has the same problems that FLASH does and as a result, is just a nice display layer that can be turned off.

Before people get all taken with AJAX they need to ask themselves 'what would happen if the client had javascript turned off or decided to bypass my javascript entirely?'.

--
This is my sig. There are many like it but this one is mine.

Re:Javascript overused by Caspian · 2005-12-07 05:59 · Score: 2, Informative

"Flash" is not an acronym.

Christ, I'm so fucking sick of people thinking any one-syllable technical term, or any technical term of five or fewer letters, is necessarily an acronym. "MAC" (by which people usually mean "Macintosh", not the networking term), "LINUX", etc.

Am I really the only one left who cares about getting these things right?

--
With spending like this, exactly what are "conservatives" conserving?
Re:Javascript overused by Foofoobar · 2005-12-07 06:24 · Score: 1

You think javascript isn't the most integral part of AJAX? Let's see you use AJAX with something else? It's not the CSS or XML that's going to be rendering that page; they are only helpers.

Javascript is the grunt that does most of what AJAX is being raved about for. It's just another way to reinvigorate Javascript.

--
This is my sig. There are many like it but this one is mine.
Re:Javascript overused by SharpFang · 2005-12-07 07:54 · Score: 1

Sure, checking data before it is sent is nice but validating data is incorrect since that data can be changed without the script and sent to the server.

ALWAYS validate on the server side. Independently of any (if any) validation on the client side.
Having the data sent from a script is actually nice: someone is integrating their apps with our services. Seems we should call the dev dept and tell them to hurry up with releasing the public API.

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Re:Javascript overused by Anonymous Coward · 2005-12-07 08:21 · Score: 0

LINUX is a recursive acronym for Linux Inux Nux Ux X
Re:Javascript overused by Foofoobar · 2005-12-07 09:09 · Score: 1

I agree. It is nice but I have gotten into long discussions with developers who want to do validation via Javascript and then want to do it on BOTH ends thus having two areas where you have to update code. And I think the point where I comprimise is for data CHECKING (like making sure they are filling out a form properly and all required fields are entered).

--
This is my sig. There are many like it but this one is mine.
Re:Javascript overused by SharpFang · 2005-12-07 09:35 · Score: 1

The rules are: Always validate on the server side to provide continuous service for -all- users, just by not getting hacked. Without that, you're screwed, simple. Validate on the client side to avoid having the client pissed off with waiting for an error message from the server. If you screw up validation on the client side, no biggie, the server WILL handle it. Just take care so that any screw-ups on the client side are directed to the permissive side, not the restrictive one. Nothing more pissing off than an overzealous javascript validator like "your postal code isn't 6-digit in xxx-xxx form" when all codes in your country are ALWAYS 5-digit in xx-xxx form, and you have already chosen the country on the country list. Or a better one: Name: second, first. Sorry, your second name must be at least 4 characters long.

True, one more point of development/maintenance, but non-essential one, feel free to put in low priority bin if you make disabling it easy.

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Re:Javascript overused by Foofoobar · 2005-12-07 10:55 · Score: 1

That's great if you want to maintain code that does the exact same thing in two different areas. But instead, I suggest as many companies have done and instead do CHECKING (not VALIDATING) on the client side and then do validating on the server side. This allows for simple errors with the form to be caught prior to going to the server but for more complex checking and validating of form submission to be handled via the server.

You are trying to do too much client side. Just check the data to make sure it LOOKS correct and then validate and test data on the server side. Minor user errors are discovered quickly via client side code and potential hacks are found in server side code.

Thus two different code bases with different purposes... not two separate code bases with the same purpose; that's stupid. That's like building the CSS for your page and then including the HTML for fonts and colors and table padding anyway. Build code smarter not dumber.

--
This is my sig. There are many like it but this one is mine.
Re:Javascript overused by Anonymous Coward · 2005-12-07 19:30 · Score: 0

The client side should do as many validations as possible as a courtesy to the user. (Of course, the server should validate strictly.) This does not mean you have to maintain twice as much code unless your implementation is stupid. Many web frameworks let you write your validations declaratively and have those validations automatically apply on both the client side and the server side without the programmer having to write any JavaScript. Every web application programmer worth his salt uses one of those frameworks (e.g. WebWork, Struts, JSF with Shale, Tapestry, etc.) Even ASP.NET has such a feature, though it is guaranteed to work only on IE 4 or later.

Perhaps you should learn how to "build code smarter not dumber."
Re:Javascript overused by Foofoobar · 2005-12-08 02:45 · Score: 1

If they validate client side, it is with a client side language. And just because SOME people wish to maintain to sets of code that do the same thing doesn't make it smart. It makes it bad coding. I had this discussion with someone at Classmates.com and they said they stopped doing that for the reasons I discussed. And frameworks do not handle client side validation; you have to add that retarded stuff in yourself and duplicate your work on the client and server side.

And good luck building those cross browser compliant applications in ASP.NET. I always like to build websites where 25% of users can't view them. Even retards know better than to do web dev in Visual Basic.

--
This is my sig. There are many like it but this one is mine.
Re:Javascript overused by Anonymous Coward · 2005-12-08 02:58 · Score: 0

Wrong. I've used these frameworks to get client side validation without writing a single line of JavaScript. The client side validations are automatically generated from the validation declarations, and the server side validations are done from the same set of declarations.
Re:Javascript overused by Foofoobar · 2005-12-08 05:08 · Score: 1

Yes... in a non-web standard that doesn't work in 25% of all browsers. Sounds like a real win. Duplicating your code AND having it fail for 25% of users. What a genius you are to be so innovatively useless. let me guess? Microsoft employee?

--
This is my sig. There are many like it but this one is mine.
Re:Javascript overused by Anonymous Coward · 2005-12-08 17:04 · Score: 0

Wrong again. The frameworks I listed generate client-side validations that work in all browsers that use JavaScript. Even if you use ASP.NET (which I don't), at worst you don't get free client-side validation, which is just as good as what you have right now. 75% of users, however, would get free client-side validation, which is much better than what you can do.

One of the problems with /. is that mountebanks like you spout nonsense, and that same nonsense gets absorbed by n00bs who become the quacks for the next generation of /.ers. It's a vicious cycle.
Re:Javascript overused by Foofoobar · 2005-12-08 17:12 · Score: 1

First you say it isn;'t javascript and now you say it is javascript. Javascript which can be turned off. Javascript which can be bypassed.

And you claim that these MVC frameworks automatically duplicate your validation for you? Well I happen to know that Struts does NOT. I also happen to know that validation is specific to the application and perhaps even the database that the data is referenced to.

Hence, any validation you want to have in javascript on the client side would have to be custom built. CHECKING however is not... and CHECKING is what they do... NOT VALIDATION!

Get a clue and then learn the difference. One makes sure the data matches the data type that is required and the other makes sure that you aren't trying to do cross site scripting, sql insertion and OTHER stuff.

God, who is teaching you newbies that this shit is ok? Why not go ahead and do you SSL with javascript too while you are at it.

--
This is my sig. There are many like it but this one is mine.
Re:Javascript overused by Anonymous Coward · 2005-12-08 17:46 · Score: 0

1. I never claimed that the user of the framework writes any JavaScript. I've always said that the JavaScript validations are generated by the framework from the same validation declarations that the framework does its server-side validations based on. Those server-side validations can't be bypassed. Learn to read.

2. You happen to be wrong again. Struts does generate client-side validation from the same i18n-capable XML file it uses to do server-side validation. It has been able to do this since version 1.1, which was released several years ago. See http://struts.apache.org/struts-action/userGuide/b uilding_view.html#validator
Note how it does not have to be custom built. Note how it is not merely checking that fields are filled in.

3. You should learn to read and see how many frameworks already let you declaratively validate against regular expressions, number ranges, boolean expressions, etc. and have those declarative validations be applied on both the client and the server.

4. You look dumber every time you post. Take a minute to read up on what it is you're arguing about before you try again.
Re:Javascript overused by Foofoobar · 2005-12-09 03:33 · Score: 1

You are confusing validation and checking and since this is like the 9th post by an anonymous user who cannot get a clue, I;ll assume you are merely trolling. Good luck validating code client side and server side. I wish you the same redundancy in all your work.

--
This is my sig. There are many like it but this one is mine.
Re:Javascript overused by Anonymous Coward · 2005-12-09 05:17 · Score: 0

There is no redundancy. Learn to read.
Re:Javascript overused by Foofoobar · 2005-12-18 04:42 · Score: 1

There is redundancy. Learn to program. You probably just don't understand what the word means.

--
This is my sig. There are many like it but this one is mine.

Umm... Its a SPOOF by dsginter · 2005-12-07 05:15 · Score: 5, Informative

Read the bottom of the page. The article is a spoof.

--
More

Re:Umm... Its a SPOOF by Anonymous Coward · 2005-12-07 05:58 · Score: 0

OK, so..."AJAX sucks as bad as frames (most of the time)"

That does it for me.
Re:Umm... Its a SPOOF by xenocide2 · 2005-12-07 07:49 · Score: 1

It's a spoof, but what's the meaning behind it? If it's a parody of the "new technology is bad" idea (of which"frames are bad" is a member), then the article implies that browsers and usage evolve over time, and we should expect frames to see widespread use. Instead most websites have abandoned the usage of frames, and instead rely on well thought out tables and div sections. In fact, the only webpage I can recall that I've used that had frames in the last year is the Java API javadocs. And that one at least has a NOFRAMES option that's nearly as useful. So that meaning can't be it. Is it spoofing the entire meaningless debate of AJAX or not? I can't tell =(

Ultimately, if we accept that browsers and markup languages evolve together over time, then I think its safe to say that an idealized version of web page languages of the future will look like LISP, perhaps with less parens and more angle brackets.

--
I Browse at +4 Flamebait
Open Source Sysadmin
Re:Umm... Its a SPOOF by WWWWolf · 2005-12-07 08:35 · Score: 1

You noticed "This is a spoof article" part, but not the "Please compare it with the original and you will see how little it has been changed" part.

It's a spoof, but it's not intended to be ignored completely. Nielsen just says, basically, "AJAX is like Frames were a few years back".

The article thus has a very good point. People went all crazy about frames, which broke a lot of stuff. Now, it's understood why and when frames are broken, and smart designers only use them in the places they make sense and work. And nowadays, people throw AJAX at everything and it just bloody well doesn't work right - but give it a few years, and AJAX has been pushed right where it belongs: places where asynchronous processing makes sense, without breaking the Javascript-less stuff. AJAX makes sense in Google Suggest, but not in every entyeerprice application.
Re:Umm... Its a SPOOF by WWWWolf · 2005-12-07 08:39 · Score: 1

...and eek, not Nielsen at all, either, just someone who copied the entire useit layout. *blinks* Should read things far more carefully.

I still think the author has a great point though.

Nielsen? Bah. by abscondment · 2005-12-07 05:15 · Score: 1

Jakob Nielsen looks at usability in terms of "what is the worst possible thing a developer could do with this technology?", rather than "what are the benefits, and how can we avoid the pitfalls?".

His main issue with Ajax is the breaking of the navigation model - well, I've got news for him: the model he describes isn't an end-all-be-all, perfect one. It's all fine and good to complain that people could use Ajax to break the back button, to create pages based on sequence of actions, et cetera - but that's not the real power of Ajax.

The model is obviously shifting. People are no longer confined to the static "page". It's more like a house that we explore than a book that we read. Sometimes, you want a window on the static wall so that you can see in real time things that are going on. But you never, and I mean never, want to distrupt the flow from room to room.

Ajax is not a navigation tool, but Nielsen is treating it that way. I mean, sure: GMail uses ajax for some navigation, and I do have certain issues with that. But within the context of a conversation - that's a perfectly fine "window" into what has happened and what is happening. GMail's dynamic view of messages is more usable than a "forward/back/refresh" paradigm, even if people have to learn something new to use it.

But like I was saying: Ajax's power is not in navigation. It would be ludicrous to suggest that. It's really powerful when it comes to providing dynamic interaction in the context of a static location. It's perfect for dashboards, maps, stock tickers, weather sites: anything that provides constantly changing data at a fixed location.

So, I'd say to Dr. Nielsen that he needs to consider Ajax outside of the navigation-misuse paradigm, because that isn't what attracts most developers to it.

Re:Nielsen? Bah. by swimmar132 · 2005-12-07 09:34 · Score: 1

Dude. Nielsen did not write the article. The article was a spoof on an article he did in 1997 on HTML frames.
Re:Nielsen? Bah. by Anonymous Coward · 2005-12-07 11:16 · Score: 0

Dude, I realize that now.

page as the atomic unit of information by xxxJonBoyxxx · 2005-12-07 05:16 · Score: 1

The fundamental design of the Web is based on having the page as the atomic unit of information...

Stop right there, grandpa. That statement ceased to be true as soon as "IMG" tags were allowed.

Re:page as the atomic unit of information by Viol8 · 2005-12-07 05:18 · Score: 1

Huh? Since when? An IMG tag simply embeds an image on the page,
it doesn't create something above and beyond the page itself.
The page can still be manipulated in full by the standard
browser systems including the images.
Re:page as the atomic unit of information by narcc · 2005-12-07 05:24 · Score: 1

The parent was making a joke about pornography.

--
Required reading for internet skeptics
Re:page as the atomic unit of information by xxxJonBoyxxx · 2005-12-07 05:24 · Score: 1

"Atomic" implies that all the information is there in one package. IMG tags and other embedded/included references require the reader to make additional requests, so they break the concept of a page as an "atomic" construct. (Conversely, "inline javascript" wouldn't break an "atomic" page.)
Re:page as the atomic unit of information by KilobyteKnight · 2005-12-07 05:26 · Score: 1

Perhaps he meant animated GIFs.

--
When will Windows be ready for the desktop?
Re:page as the atomic unit of information by Kelson · 2005-12-07 06:07 · Score: 1

There's a difference between the way the page is constructed and the way it's used. From a navigational perspective, it's atomic. Your browser may have retrieved 12 files from 3 different servers, but from the user's perspective it's one page until they start breaking things down with "View image" etc.
Re:page as the atomic unit of information by xxxJonBoyxxx · 2005-12-07 06:17 · Score: 1

...from the user's perspective it's one page until they start breaking things down with "View image" etc.
Or they attempt to save the page, in which case only the base HTML page is saved (rare, these days) or the base HTML page is modified to point to local resources and all the local resources referenced on the page are also downloaded. Either way, what you end up with on your hard drive isn't a complete, identical snapshot of what you were looking at on the web. (Even in the case where just the base HTML page is saved, a referenced image could be changed...)
My overall point is you don't have to go very far to run into cases where the assertion that "it must all be atomic" is unreasonable - a simple page with one IMG tag breaks the atomic model.
Re:page as the atomic unit of information by SharpFang · 2005-12-07 07:48 · Score: 1

Can be avoided using the data: URL scheme for embedding content :)

BTW, how to convert a WHOLE page (including linked images) to a data: URL? (automatically, js preferred)
Can you access the raw image data from inside javascript?

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Re:page as the atomic unit of information by Anonymous Coward · 2005-12-07 08:05 · Score: 0

I think it's more the point that the URI is the atomic unit - no matter how the page is constructed once you get to it. The page you see could be formed by adding in any number of images or other objects from outside that page's own HTML but it's still uniquely described by that address.

It's not that the page itself is supposed to be atomic, but that the identifier used to refer to it is. There is a distinction between the two.
Re:page as the atomic unit of information by lahi · 2005-12-07 08:36 · Score: 1

And if HTTP could use MIME multipart-mixed to deliver the page, the HTML together with all the media components could easily be delivered in one response. (I almost said APDU.)

-Lasse

This is a spoof by mogur · 2005-12-07 05:17 · Score: 0

This article is a spoof of a previous article about frames. If only someone would read the whole article before posting.... http://www.useit.com/alertbox/9612.html

--
-Mogur

Re:Nielsen? Never mind.- spoof by netean · 2005-12-07 05:17 · Score: 1

oh hang on a minutes

"This is a spoof article. Please compare it with the original and you will see how little it has been changed.

Constructed by Chris McEvoy with apologies to Jakob Nielsen. "

Where's the Humor Icon? by Anonymous Coward · 2005-12-07 05:19 · Score: 0

If the disclaimer at the bottom claiming the "article" is a spoof wasn't enough. How about the examples given where using AJAX is acceptable?

geotag-based apps via flash
tag-based instant messaging via Ruby on Rails
community podcasts via api mashups

Which were taken straight from the Web 2.0 company generator script: http://andrewwooldridge.com/myapps/webtwopointoh.h tml

AJAX is MS technology...? by Brad_sk · 2005-12-07 05:19 · Score: 1, Funny

AJAX is MS technology...Oh, my God. I need to start hating this now. I better hide behind this article and bash Microsoft. Don't waste a second!

When is a spoof not a spoof? by DragonHawk · 2005-12-07 05:20 · Score: 3, Insightful

"If you read the bottom of the article, you'll notice that it's a spoof and a simple rewrite about why frame suck most of the time."

It's interesting to note that while the article is apparently a spoof, many of the objections still apply. (Sure, this is way over-generallzing, but work with me here for a minute.) Also, note how frames went through a period where everybody used them, then use gradually taper off. I think people realized that much of the time, frames just got in the way and the "old ways" worked just as well, if not better.

It does seem like the computer world loves to make the same mistakes over and over and over and over again. We keep doing it. (ObRef to The Mythical Man-Month by Fred Brooks.) What's that about not learning history?

--

dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.

Re:When is a spoof not a spoof? by Woldry · 2005-12-07 05:43 · Score: 1

It does seem like the computer world loves to make the same mistakes over and over and over and over again.

For "the computer world" read "the entire human race."

What's that about not learning history?

I can't remember. Could someone repeat it for us ... ?

--
How can a post be modded "overrated" or "underrated" when it hasn't been rated yet?
Re:When is a spoof not a spoof? by morgan_greywolf · 2005-12-07 05:45 · Score: 1

The difference between frames and AJAX, though, is that frames were used for lots of ordinary Web pages. Where AJAX (and frames, for that matter), shine is in the use of Web applications -- applications that were traditionally run on the desktop that can now be run in a Web browser. Think gmail, Google Maps, Writely, etc. You don't need or necessarily even want a back button or bookmarkable URLs for these types of applications.

--
My blog
Re:When is a spoof not a spoof? by Kelson · 2005-12-07 05:48 · Score: 1

What's that about not learning history?

I can't remember. Could someone repeat it for us ... ?

Hey, some of us passed it the first time!
Re:When is a spoof not a spoof? by Kelson · 2005-12-07 05:51 · Score: 1

I don't know, bookmarking a particular map view is incredibly useful.

But Gmail? Nah. And who needs to bookmark a "thank you for rating your Amazon purchase, now go back to the actual listing" response?

The trick is to figure out whether use of AJAX would improve or degrade a particular aspect of the site or app. If it'll improve it, then by all means, use it. If it'll degrade it, don't bother writing up the code, no matter how cool it sounds.
Re:When is a spoof not a spoof? by Anonymous Coward · 2005-12-07 05:55 · Score: 0

And who needs to bookmark a "thank you for rating your Amazon purchase, now go back to the actual listing" response?

Someone who wants to comment or critique the page? Or someone who wants to point something out to tech support about how their page is broken on a particular browser?
Re:When is a spoof not a spoof? by Anonymous Coward · 2005-12-07 09:48 · Score: 0

Human beings make the same mistakes over and over and over again. It has nothing to do with technology. Whatsoever.

or: "Jakob Nielsen like it static." by plams · 2005-12-07 05:25 · Score: 1

From TFA

the BACK button in the browser simply didn't work with ajax sites.
If you're using AJAX for all "navigation" for a site you're using it wrong. One of the best uses for AJAX is to update the site according to a user's choice, say, adding a comment to a slashdot article. What do you want to use the BACK button for there? Go back to BEFORE you posted the comment? The BACK button works great for static homepages, but "dynamic" is the keyword in AJAX.

Many browsers cannot print ajax pages appropriately.
That's not really an AJAX problem, but the browser having difficulties capturing the present state of the page. The same problem usually goes for using "save as" on the page, btw.

Ajax is currently so hard to learn that many page authors write buggy code.
Okay, then call that section "Page authors sucks most of the time". Also, Ruby on Rails does a great job of making AJAX available to the n00b.

Search engines have trouble with ajax
Again, AJAX should be used for dynamic changes to a page. A search engine isn't meant to post comments and such.

IMO, AJAX used for page navigation is bad. Using it for dynamic updates is neat.

An odd complaint here.... by mblase · 2005-12-07 05:28 · Score: 1

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.

I hate to state the obvious, but URLs have never really constituted a complete specification of the information shown. The big problem is that, unlike books, the Web is digital and dynamic -- what you read at a given URL today can be moved, edited, deleted, or p0wned by the time you get there tomorrow.

Ask any experienced high school literature or history teacher why they discourage students from using the Internet as an source for research papers, and this will be the big reason why.

I understand the core of his point, but I think it's time he acknowledges the reality that nothing on the World Wide Web is static these days--if it ever was.

Re:An odd complaint here.... by Kelson · 2005-12-07 06:02 · Score: 2, Insightful

The big problem is that, unlike books, the Web is digital and dynamic -- what you read at a given URL today can be moved, edited, deleted, or p0wned by the time you get there tomorrow.

Sure, it can be moved -- but that doesn't mean it should be. Keeping a page at a particular location makes it much easier for people to find it, whether via search engines, their own bookmarks, links on other sites, etc.

This doesn't mean it can't change. Linking to, say, a product page on Amazon is extremely useful. You can expect the price, reviews, recommendations, etc. to change over time, but you should expect the same product to be there the following year as long as they still sell it.

Now presenting the Dee Da Dee Awards by AcidTag · 2005-12-07 05:29 · Score: 0

...and the Award goes to Slashdot flamers who read the first paragraph of an article before getting diarrhea of the mouth.

"This is a spoof article. Please compare it with the original and you will see how little it has been changed"
"Constructed by Chris McEvoy with apologies to Jakob Nielsen."

DWR? by walders · 2005-12-07 05:31 · Score: 1

Is dwr any better?

78 percent? by ChrisGilliard · 2005-12-07 05:33 · Score: 1

Ajax Compatible Browsers: 78%

No way.....85% use IE alone and IE is Ajax compatible. That's not even counting Firefox, Mozilla, and others.

--
No Sigs!

Re:78 percent? by GigsVT · 2005-12-07 05:49 · Score: 1

How many use IE3 or 4 though?

How many turned off all scripting like they were warned to do after the latest IE scripting exploit?

It wouldn't surprise me that AJAX is broken on 22% of browsers.

Results 1 - 10 of about 564,000 for IE vulnerability disable scripting.

Yeah, that speaks for itself.

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Re:78 percent? by heinousjay · 2005-12-07 06:31 · Score: 1

It speaks for itself, but it doesn't say anything coherent...

--
Slashdot - where whining about luck is the new way to make the world you want.
Re:78 percent? by ChrisGilliard · 2005-12-07 17:27 · Score: 1

How many use IE3 or 4 though?

Not many. I think it's about 1% of the hits generated by IE users that are back on IE 4. How many turned off all scripting like they were warned to do after the latest IE scripting exploit?

Again, not many. Last time I looked it was less than 1% of hits that have javascript disabled.

Basically anyone who doesn't have AJAX enabled is either wearing a tin foil hat (security freak) or hasn't updated their browser in ages (like 5 years or so).

--
No Sigs!

Flash by smallguy78 · 2005-12-07 05:33 · Score: 2, Insightful

Flash can't be bookmarked either, probably the most annoying feature behind pure flash websites that puts me off.

The main problem is people want to be able to serve miniature applications via the web, whilst even with new standards it's still about providing glorified word documents with a smarter navigation.

--
Nothing costs nothing

SPOOF, but were frames a good idea? by winkydink · 2005-12-07 05:33 · Score: 1

The article is spoof, doing an s/frame/ajax/ on an earlier posting as to why frames suck. While it is a spoof, it still has a point.

--

"I'd rather be a lightning rod than a seismometer." -Ken Kesey

Re:SPOOF, but were frames a good idea? by IAmTheDave · 2005-12-07 05:52 · Score: 1

Perhaps that point should simply be that in excess, anything is bad. Done.

--
Excuse my speling.
Making The Bar Project
Re:SPOOF, but were frames a good idea? by mellon · 2005-12-07 06:19 · Score: 1

More precisely, done badly, anything is bad. And perhaps it's easy to do it badly. However, the counterargument to that is that sometimes a thing done badly is better than a thing not done at all. And also, best is the enemy of good enough.

Hm, can I think of any more slogans to throw in here?

Nevermind.
Re:SPOOF, but were frames a good idea? by DavidTC · 2005-12-07 12:07 · Score: 1

Everything in moderation...
...including moderation.

--
If corporations are people, aren't stockholders guilty of slavery?

Huh? by TheRealMindChild · 2005-12-07 05:36 · Score: 2, Insightful

Isnt this the EXACT same reason we are told not to use frames? I think the problem isn't AJAX and FRAMES, but that we all need to evolve past the "You are looking at a flat page" ideology. Maybe look at it from the point of view of 'bookmarks', 'back button', 'Printing', and 'Accessibility', were all there with the 1.0 browsers 12+ years ago. HTTP has evolved. HTML has evolved. The whole idea of what the web is has evolved. Why do we insist on keeping the webpage paradigm the same? It simply doesn't make sense.

--

"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson

Let's get a few things straight by ArwynH · 2005-12-07 05:37 · Score: 2, Insightful

Asynchronous JavaScript and XML (AJAX) is not a technology in itself, but is a term that describes a "new" approach to using a number of existing technologies together, including: HTML or XHTML, Cascading Style Sheets, JavaScript, The Document Object Model, XML, XSLT, and the XMLHttpRequest object. When these technologies are combined in the AJAX model, web applications are able to make quick, incremental updates to the user interface without reloading the entire browser page. This makes the application faster and more responsive to user actions.

-- quoted from http://developer.mozilla.org/en/docs/AJAX

In otherwords the technology is not new and isn't a Microsoft Technology. Although to give them due credit they did invent the XMLHttpRequest object which makes AJAX possible.

Personaly I think the article is nothing more a than an annoying rant. Every technology has it's weeknesses and it's strengths. And just as you should do with any technology you must weigh up the pros and the cons of using it for your specific goal before you do. Saying something is trash and that it should not be used at all for anything is down right stupid.

Hype sucks. by marcosdumay · 2005-12-07 05:37 · Score: 1

All hype sucks must of the time. We have just to wait until the hype goes away and the bad projects die. So, we'll have only lots of useful stuf.

--
Rethinking email

dojo toolkit by ChrisGilliard · 2005-12-07 05:37 · Score: 1

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 the purpose for the Dojo toolkit. The degredation is built-in. http://www.dojotoolkit.org/

--
No Sigs!

spoof error by ezzzD55J · 2005-12-07 05:37 · Score: 1

In the long term, we will need a richer model for hypertext nodes on the Web than can be supported by frames.

Just give it up and give us terminals! by mikeee · 2005-12-07 05:38 · Score: 1

OK, I'm just an ignorant caveman sysadmin, unfamiliar with all your modern XML wizardry, but maybe if the idea is remote display of graphical applications, we should have, I dunno, Graphical Terminal Emulators, rather than attempting to implement one in a web browser.

Why am I apparently the only person who thinks this? Am I missing something, or are you all insane?

Re:Just give it up and give us terminals! by Woldry · 2005-12-07 06:00 · Score: 1

Am I missing something, or are you all insane?

The two are hardly mutually exclusive, nor exhaustive, possibilities.

--
How can a post be modded "overrated" or "underrated" when it hasn't been rated yet?
Re:Just give it up and give us terminals! by SharpFang · 2005-12-07 07:38 · Score: 1

Yes, missing something.
Serving a billion HTTP requests a day and performing maybe 1000 cycles of real CPU work on processing the data received besides all than TCP, HTTP, PHP etc overhead is nothing compared to running a billion apps locally and serving their gfx output over the net. Both in bandwidth and CPU usage meaning. Thick clients plus reducing throughtput to necessary minimum is way cheaper on the server side. No meaning if both client and server boxes (and net) are under common ownership. Essential if you pay for the server, your customers pay for the clients (and someone else gets the money for bandwidth from both of you).

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Re:Just give it up and give us terminals! by mikeee · 2005-12-07 09:14 · Score: 1

See, I don't think that's true.

besdies all than TCP, HTTP, PHP etc overhead

Which is way worse. All the extra TCP connections. The insane bandwidth-and-CPU consuming cookie stunts necessary to simulate a real session that doesn't exist with HTTP. Sure, you compare to thick clients, but how thick a client is a bunch of downloaded javascript?! That's not buying you anything.

Sure, you could replace SSH with an AJAX application, but it would be idiotic, and the same would be true of most web applications if a suitable remote graphical terminal standard were available.
Re:Just give it up and give us terminals! by SharpFang · 2005-12-07 09:41 · Score: 1

Sure, you compare to thick clients, but how thick a client is a bunch of downloaded javascript?! That's not buying you anything.

Depends on the amount of Javascript. What is the thick client written in is an arbitrary decision. More "talking" than telnet/ssh (but these are text-only, thus unfashionable) but still way less than, say, VNC or X forwarding.

And don't underestimate Javascript. 1) Download sources of Firefox. Some 60% is written in JS. 2) Windows Explorer (not really MSIE), options, customize current directory - you suddenly find Notepad filled with a javascript app that does displaying the directory content. A serious part of Windows GUI is Javascript. It's WAY more than making pictures on webpages blink.

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2

frames suk.. frames (mostly) died a quick death .. by RedLaggedTeut · 2005-12-07 05:40 · Score: 1

That is why we use in our company, they are much better

--
I'm still trying to figure out what people mean by 'social skills' here.

you have got to be kidding, to be saying.... by 3seas · 2005-12-07 05:43 · Score: 1

there is not enough of us that have enough experience in dealing with marketing hype to not know, via second nature, that you never never believe marketing hype, but only believe what experience proves.
Especially comming from Microsoft, where even experience is questionable.

Yeah, NOBODY! by brunes69 · 2005-12-07 05:44 · Score: 2, Informative

Yeah, NOBODY uses frames in development anymore. Thats old news!

What's that? GMail uses hidden iframes? Google Maps uses hidden frames? Yahoo maps? AdSense? Slashdot? Nah, those guys are all small potatoes!

</sarcasm>

Get a clue. Just because you can't see frames, does not mean they are not there. Frames are used all over the freaking place. Nearly every web page you visit has an ad in an iframe in it.

This is the reason that this article, and also the one it spoofed, are both wrong. Not every state of a web page has to be, or should be, bookmarkable. The back button was never meant to be an 'undo' and should not be treated as such. etc etc...

Both frames and Ajax are very useful and powerful in web applications.

Re:Yeah, NOBODY! by Anonymous Coward · 2005-12-07 06:03 · Score: 0

Iframes are not the same as frames. If you can't differentiate between them, then I suggest you hush. As for webapps, AJAX's problems don't disappear for webapps. You simply learn to deal with the flaws of the development model and the minor torment it means for users. Who would almost certainly prefer to just use a thick client.
Re:Yeah, NOBODY! by Anonymous Coward · 2005-12-07 06:27 · Score: 0

. You simply learn to deal with the flaws of the development model and the minor torment it means for users.

Sounds like Windows developers will have an advantage getting started with Ajax...
Re:Yeah, NOBODY! by brunes69 · 2005-12-07 06:28 · Score: 1

Anyone who designs a webapp around the idea of frugal use of the back button or bookmarks should be shot, plain and simple. Such a thing could never be more complicated than a bulliten board system, and would not be clasified as a "web application".
Re:Yeah, NOBODY! by guet · 2005-12-07 06:47 · Score: 4, Interesting

Get a clue. Just because you can't see frames, does not mean they are not there. Frames are used all over the freaking place. Nearly every web page you visit has an ad in an iframe in it.
This is the reason that this article, and also the one it spoofed, are both wrong. Not every state of a web page has to be, or should be, bookmarkable. The back button was never meant to be an 'undo' and should not be treated as such. etc etc...
Both frames and Ajax are very useful and powerful in web applications.

1> There's no need to be so obnoxious - an iframe is not a frame, and the original article was talking about frames, which did break the web and were a Bad Thing.
2> The back button should be usable to navigate from resource to resource. Each URL should identify a resource, and each unique resource (message,post,whatever) should have an URL.

Sometimes web apps break this rule, and when they do, it can be bad. Obviously state shouldn't be bookmarkable, but resources should be. Ever tried to give someone a link to a product on the Apple store? Applications which misuse AJAX can have this problem if they use it exclusively and don't change the url, or worse put some garbage to do with THEIR session info in the url which is shown to the user. Gmail gets away with it because you mail is private and you don't need to send links, with google maps it's kind of annoying because you have to click the 'link to this page 'kludge to send the map to someone else, and you can't click back through various locations easily.

Not that I'd agree that AJAX sucks most of the time, it doesn't at all, can't work out why everyone is getting so worked up about a small part of the toolset.
Re:Yeah, NOBODY! by MikeBabcock · 2005-12-07 07:55 · Score: 1

When possible, state should be bookmarkable too.

I've on occasion looked up a part and added it to my shopping cart online, then wanted to pass it along to purchasing to have them order the parts, but cannot.

They have to start over and create their own shopping cart on the same site and punch in the product codes I used.

Why can't I just bookmark the cart and send it to them? Because the URI doesn't store the info about what's in my cart. And why not? There are very few cases where this is even remotely a security problem. We're not talking about who I am stored in the URI, we're talking about what I want to buy.

--
- Michael T. Babcock (Yes, I blog)
Re:Yeah, NOBODY! by Ken+D · 2005-12-07 09:02 · Score: 1

It's called an 'Amazon Wishlist' :^)
Re:Yeah, NOBODY! by Pong3A · 2005-12-07 09:29 · Score: 1

Funny thing is that, in my opinion flash designed sites break many many of this rules and much more, but they haven't died yet... Like most of the people here I think that correctly used (WebApps) Ajax is good but when used to evil (:P) it is bad. Same thing about flash :\ I think that flash should never be used to make sites... but we can't all have what we wan't.

--
"Fantômas." "What did you say?" "I said: Fantômas." "And what does that mean?" "Nothing....Everything!" "But

Poor Jakob Nielsen by Anonymous Coward · 2005-12-07 05:45 · Score: 1

I've been reading Jakob's blog for years. He's one of those 50-50 guys. Half of what he says is dead on, and the other half is complete crap. I got a real chuckle at the end of this article when I saw:

Next month: Micropayments will take off in 2006.

Poor ole Jakob started predicting the widespread adoption of micropayments on the same day Al Gore invented the internet. He was wrong then and is still wrong, but he'll keep beating that drum until the day he dies.

Sentence Structure Sucks Most of the Time by davebrot · 2005-12-07 05:46 · Score: 1

...and that's a universal usability problem: "If you are working in a Web2.0 company that needs to provide evidence of their technical expertise in order to gain new clients. However, you must remember to keep your offering in beta and make sure that it in the same family as these examples:"

Not a spoof... by swein515 · 2005-12-07 05:47 · Score: 1

"Spoof" or not, this article is completely in line with his point of view on web standards, and ergo it is valid to criticize. I believe he is calling it a spoof merely to point out that what's wrong with frames is wrong with AJAX.

AJAX ?? by olddotter · 2005-12-07 05:47 · Score: 1

A freind of mine keeps telling me that most of Google's web applications (gmail) are AJAX based.

But to me it seems like AJAX makes it hard for a site to be referenced and indexed. So what is the common ground between wanting slick technology for your website, but also wanting it be indexable by search engines?

I ask because I am thinking of creating a web service, but architechture wise for it to be useful it needs to be googleable! :-)

--
Think Deeply. ...

Re:AJAX ?? by SharpFang · 2005-12-07 07:29 · Score: 1

Creating alternatives. Tags like NOSCRIPT, NOFRAMES come in mind. "Traditional" gmail interface that works in Lynx. Make AJAX provide all the handy, slick functionality but provide old-fashioned CGI-based alternatives.

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2

wrong by circletimessquare · 2005-12-07 05:48 · Score: 0, Troll

breaking bookmarking, making the 'back' button useless, problems with printing

ok, try any of those things with any standard non browser-based application: same problem. the point is, everyone raves about ajax because it makes the browser work like a standard application. but we are suppposed to be critical of ajax because, wait for it... it makes the browser work like a standard application. huh?

wrong. howabout you accept that what people are doing with ajax is SUPPOSED to do these things, and apply criticism of ajax ONLY from that point of view. that is, the point of view of how well ajax does what it is SUPPOSED to do. but criticizing ajax for making websites act not like a browser, when ajax is SUPPOSED to make websites not act like browser, is just silly

if you don't understand what ajax is supposed to do, don't criticize it, because you don't understand it. the difference is: some people know what ajax is supposed to do, and think it is good for SOME situations... and some people don't know what ajax is supposed to do, and think that everyone who wants to use it thinks it is the cure for every problem in the world, and therefore criticizing it like this way is useful. it isn't

--
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it

Re:wrong by SharpFang · 2005-12-07 07:26 · Score: 1

we are suppposed to be critical of ajax because, wait for it... it makes the browser work like a standard application. huh?
We are supposed to be critical of ajax because it makes browser stop working like a browser. If the application sucks, it sucks, we are critical of it, fine. Ajax or not. But we have certain expectations towards applications that -are- webpages. That is, that they behave -somewhat- like webpages. When they don't (and with Ajax, they usually don't), we start being critical of them...
Ajax sucks MOST of the time. Not always.

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2

AJAX is a baby step by ThinkFr33ly · 2005-12-07 05:49 · Score: 2, Interesting

AJAX is a baby step on the march back to rich clients.

Web apps are great because of their ease of deployment. There is no "upgrade cycle" for users. They just refresh the page and they get the latest and greatest.

Rich client apps are great because of the ability to have a rich UI and far more control over the presentation of your application. Speed is almost always better. You can just do more.

AJAX is an attempt to merge the two. Sometimes it works very well, sometimes not. But it's just a stop-gap solution that tries to use existing web technology to mimic the experience users know and love from rich client apps.

The real solution to this problem is to allow for rich client apps to have the ease of deployment of web apps. There are a few possibilities in this area.

One solution is Microsoft click-once deployment paradigm in .NET 2.0, although it has its limitations as well. (Windows-only being a big one.) It looks as though Windows Vista is going to try and blur the line between Windows and the Web as much as possible, making rich client applications created with WPF (Avalon) fully hostable inside the web browser. (With code access security restrictions, of course.)

Of course, this has the same problems as most .NET solutions at this point... it's Windows only. One of the great thing about web apps is that they run pretty much anywhere. I suspect that many companies will say that 90% market coverage is good enough for the benefit of web-deployed rich client apps.

Does anybody know of similar projects coming down the pipe that will offer this to more than Windows clients? Something other than people implementing WPF and the .NET Framework on other platforms? I know about WPF/E (Windows Presentation Foundation Everywhere), which is a subset of WPF that Microsoft is trying to make cross-platform, but what about non-Microsoft solutions?

Re:AJAX is a baby step by handslikesnakes · 2005-12-07 06:21 · Score: 1

XUL.
Re:AJAX is a baby step by ThinkFr33ly · 2005-12-07 06:45 · Score: 1

Ah yes, I remember reading about XUL and how it compares to XAML.

There have also be news stories about it.

Some would by Stunning+Tard · 2005-12-07 05:50 · Score: 1

I figure the author must be from Toronto. That's that city outside the Town of Ajax.

The wiki is wrong - history lesson by brunes69 · 2005-12-07 05:50 · Score: 5, Informative

AJAX relies on the XMLHttpRequest object to do anything. Without it, there is no AJAX (you could say it puts the A in AJAX). Microsoft invented this object, it has shipped with the MSXML COM object for a long time. They first used it in Outlook Web Access in the late 90s.

AJAX only started to get popular in the media after Adaptive Path coined a stupid buzzword for it, but IE-specific developers had been using it for years. Adaptive Path just stumbled upon it being more sueful because Firefox started also shipping an XMLHttpRequest object.

But Microsoft *did* create it, so it is totally accurate to call it a "Microsoft Technology". Just like SMB networking is a "Microsoft technology", even though there is Samba, and .Net is a "Microsoft Technology", even though there is Mono.

Re:The wiki is wrong - history lesson by aphorian · 2005-12-07 06:23 · Score: 1

Not true. You could call XMLHttpRequest an 'invention' of MS, but that's not a technology, it's a method. AJAX is an approach-- a combination of CSS, DTHML, XMLHttpRequest, and Server side technologies. Yes, it relies on the XMLHttpRequest as a major component, but that's all it is, a component. By your logic, all web apps are Netscape technology since they invented the browser. No wait, AJAX is MOSAIC technology. Yea, that's it!
Re:The wiki is wrong - history lesson by Anonymous Coward · 2005-12-07 06:29 · Score: 0

SMB was not invented by Microsoft, it has been existing about two years before. Using SMB for CIFS wasn't new either. Using SMB for a LDAP clone, well, that was new and is still incompatible with the rest. .NET is merely a bad Java clone and only had very own innovations in recent times.

And, don't forget, XmlHTTPRequest is a COM/ActiveX control, inaccessible to any standard of JavaScript, not to talk about the ECMAScript subset. In fact, even most people at Microsoft are too dumb for implementing ActiveX in the correct way, means that is totally wrong and not W3C-conformant, whereas is fully W3C-compliant and works as well. Not to say that you won't be able to script it, because no sane webbrowser would allow that, especially not without calling a PrivilegeManager.enablePrivilege('browserspecific name for that policy') first.
Re:The wiki is wrong - history lesson by ergo98 · 2005-12-07 06:37 · Score: 1

Not true. You could call XMLHttpRequest an 'invention' of MS, but that's not a technology, it's a method. AJAX is an approach-- a combination of CSS, DTHML, XMLHttpRequest, and Server side technologies. Yes, it relies on the XMLHttpRequest as a major component, but that's all it is, a component. By your logic, all web apps are Netscape technology since they invented the browser. No wait, AJAX is MOSAIC technology. Yea, that's it!

So you're the keeper of the AJAX definition these days? Good to know, because it seems that every halfwit is declaring it whatever they feel that it should be today.

The "method" of AJAX - what made it a revolution - was the idea of progammatic data storage and capture without page loads. That alone defines why it was such a big revolution. XMLHttp(Request) is what enabled this functionality, and thus what allowed for the dramatic change in how web apps are delivered, so yes - Microsoft invented and implemented AJAX. Microsoft was pushing these sort of advanced web application many years ago.

The funny thing, though, is that developers using Microsoft technologies have been doing this for about 6 years now, wondering what all the fuss is about.
Re:The wiki is wrong - history lesson by Anonymous Coward · 2005-12-07 06:40 · Score: 0

AJAX relies on the XMLHttpRequest object to do anything
Sorry, but I can't let this one go by. Ajax does not require an XMLHttpRequest object. I was doing what is now called AJAX years ago to populate combo boxes without page refreshes. I never used XMLHttpRequest. The XMLHttpRequest is admittedly an easier technique, but in no way required (I was using the old Netscape browser).
Re:The wiki is wrong - history lesson by rk · 2005-12-07 06:43 · Score: 1

Microsoft invented XMLHttpRequest, but you can do AJAX without it. I did some simple AJAX-like things about 5 years ago, using a hidden frame and flat text. Not nearly as slick to work with, but it did the "asynchronous" thing fairly well, only asking for data from the server when I needed it. It was ugly, but it worked.
Re:The wiki is wrong - history lesson by fzammett · 2005-12-07 06:45 · Score: 1

Point of fact, AJAX is a technique, a mindset, an approach, rather than a specific technology implementation.

As an example, I built an application nearly six years ago, LONG before I had even heard of the XMLHttpRequest object... this application used a hidden frame where all form submissions were targetted to, and some relatively (at the time at least) fancy Javascript to populate pre-existing s in the main content frame... you see, *all* the pages of the application were loaded at startup, and what the server returned from then on out was nothing but data that was inserted into the appropriate elements, and then the appropriate was shown.

This is equivalent to what we know as AJAX today, but without XML, and without the specialized component to make the requests. AJAX is a misnomer because it doesn't require usage of XMLHttpRequest, nor does it even require XML. But, the underlying concept, that every request to the server DOES NOT need to result in a new page, is what is key.

FYI, it doesn't even have to result in something new being displayed... unknown to many is the fact that the server can return a chunk of Javascript to be executed. Have a look here:

http://javawebparts.sourceforge.net/

Download the bin package and drop it in your favorite container, then navigate to the taglib sample page and check out the AjaxTags example that returns and executes Javascript on-the-fly. Think of what's possible there! AJAX IS NOT simply inserting new content into a , the other popular misconception!

--
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
Re:The wiki is wrong - history lesson by brunes69 · 2005-12-07 06:46 · Score: 1

IFrame refresh hacks are not "asynchronous" because the user can see them happening, just by watching the browser load icon.

They also break the back button even worse than Ajax. With Ajax at least the back button takes you back a page, if you are doing iframe nonsense and do not know what you are doing (ie, using location = instead of location.replace) it frequently just moves the iframe back a page, resulting in it doing nothing, or worse, sending/retrieving duplicate data.
Re:The wiki is wrong - history lesson by brunes69 · 2005-12-07 06:53 · Score: 2, Insightful

Copying another response...

IFrame refresh hacks are not "asynchronous" because the user can see them happening, just by watching the browser load icon.

They also break the back button even worse than Ajax. With Ajax at least the back button takes you back a page, if you are doing iframe nonsense and do not know what you are doing (ie, using location = instead of location.replace) it frequently just moves the iframe back a page, resulting in it doing nothing, or worse, sending/retrieving duplicate data.
Re:The wiki is wrong - history lesson by wfberg · 2005-12-07 06:58 · Score: 2, Insightful

IFrame refresh hacks are not "asynchronous" because the user can see them happening, just by watching the browser load icon.

That's not quite what being asynchronous means. Asynchronous means not sitting idly by waiting for a (remote procedure/http) call to finish. For example; while you're loading one thing, you might be sorting a table of data (even if the javascript isn't even on the page, check out the handy sort table bookmarklet).

It's OK for the user to know things are going on in the background; for example, when you press the Print button in Microsoft Word, it doesn't make you wait for the print job to finish, it continues in the background. You won't get your hardcopies any sooner (so you might still have to wait for that job to finish to do the next thing you have to do), but the program isn't stuck waiting for the call to finish.

The Gmail interface is actually not such a good example of asynchronisity. It makes you wait while it's sending mail, for example..

An (I)frame refresh hack might be slightly more visible, but if you can still use the application (i.e. its javascript functionality), it's still asynchronous.

--
SCO employee? Check out the bounty
Re:The wiki is wrong - history lesson by rk · 2005-12-07 07:08 · Score: 1

I don't think the definition of "asynchronous" has anything to do with user visibility, because then nothing is asynchronous because I still see "Transferring data from..." messages on the status bar all the time when using AJAX web apps.

But you're right, it was a hack that XMLHttpRequest made unnecessary. Unfortunately, five years ago it wasn't widely deployed in browsers I had to support.
Re:The wiki is wrong - history lesson by Anonymous Coward · 2005-12-07 07:23 · Score: 0

Just like SMB networking is a "Microsoft technology"
Nah, SMB is an old IBM technology.
Re:The wiki is wrong - history lesson by electroniceric · 2005-12-07 07:23 · Score: 1

What kind of "history" is this? If Microsoft "invented" XML over HTTP, what the hell is SOAP, and how come it didn't originate with Microsoft? And did Microsoft invent remote function invocation as well?

Look, XMLHttpRequest may be the most elegant implementation of that concept to date, but that's not the same as inventing the idea of web pages with subcomponents that load data using Javascript, nor of using XML as a data transfer mechanism. That's what AJAX is.

As far as I can tell, the only new things about AJAX are:
a) the buzzword
b) the fact that a quorum of people are willing to go to the effort to make apps full of widgets load data without a page refresh

You might want to add a little more required reading to that history lesson.
Re:The wiki is wrong - history lesson by fzammett · 2005-12-07 07:55 · Score: 1

I didn't say IFrames... I said "frames". Back then I'm not sure I even knew about IFrames :)

As others have mentioned, processing asynchronously doesn't have anything to do with user awareness of activity, it has to do with whether other operations are blocked until the another operation completes (meaning those two events are synchronous). In terms of AJAX, the asychronous part comes into play because relative to the "normal" flow of HTTP requests (i.e., clicking a link, hitting back, etc), an AJAX request happens independent of those types of things.

--
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
Re:The wiki is wrong - history lesson by Fujisawa+Sensei · 2005-12-07 09:00 · Score: 1

SOAP was at least partially invented by Microsoft

http://en.wikipedia.org/wiki/SOAP/

SOAP originally was an acronym for Simple Object Access Protocol, but the acronym was dropped in Version 1.2 of the SOAP specification. Originally designed by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein in 1998 with backing from Microsoft (where Atkinson and Al-Ghosein worked at the time),

You can tell its Microsoft becaust the first part of the acronym is Simple, which SOAP is not.

--
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
Re:The wiki is wrong - history lesson by Anonymous Coward · 2005-12-07 09:49 · Score: 0

But Microsoft *did* create it, so it is totally accurate to call it a "Microsoft Technology". Just like SMB networking is a "Microsoft technology", even though there is Samba, and .Net is a "Microsoft Technology", even though there is Mono.

This may be accurate for AJAX and .Net, but as far as I know SMB was first started by IBM and later developed further by Microsoft. So it's not really a good example of this case.
Re:The wiki is wrong - history lesson by IntlHarvester · 2005-12-07 15:26 · Score: 1

That's not quite what being asynchronous means. Asynchronous means not sitting idly by waiting for a (remote procedure/http) call to finish.

And that's exactly why frames aren't asynchronous -- a frame can only load one URL at a time, so the "hidden frame" sites tend to break if you start pushing buttons too fast. A correctly written XMLHTTP site doesn't have this problem.

(Except for that evil hack I've seen where iframes are dynamically added to a page.)

--
Business. Numbers. Money. People. Computer World.

I bet that not everyone thinks those are drawbacks by Anonymous Coward · 2005-12-07 05:51 · Score: 0

Is it just me, or does a list of problems that includes "breaking the back button" and "printing problems" among other things sound like a command and control web designer's wet dream? I'm sure you've all run into those pages that use Javascript to break right click, and CSS output settings to break printing, and so on. All those terrible people who jumped all over Flash go without saying, of course.

+1 Funny -- and RTFA! by Stavr0 · 2005-12-07 05:51 · Score: 1

s/frames/Ajax/g

Not MS by thpdg · 2005-12-07 05:54 · Score: 0

AJAX is NOT a Microsoft technology. The required Javascript commands were originally introduced as part of Mozilla/Gecko/Firefox. Similiar ideas have existed in ActiveX, but were not termed AJAX until only recently.

--

-Patrick

"They never stop thinking about new ways to harm our country and our people, and neither do we."

No, Ajax does not sucks by xtracto · 2005-12-07 05:54 · Score: 1

VAX sucks

--
Ubuntu is an African word meaning 'I can't configure Debian'

Re:No, Ajax does not sucks by darkjedi521 · 2005-12-07 06:08 · Score: 1

I think the real thing moves more air. A lot more air.

Not hard by DoctorMO · 2005-12-07 05:54 · Score: 1

I did somthing similar to Ajax, using frames and javascript to enable upload/download progress bars that work with any browser (unlike the ActiveX or Java versions which are clunky), it's rather neat. the nice part is the way it looks like it was apart of the page, no horrible refreshing or popup window just pulling the width of a div with some repeating image (like the nice mac progress bar image) and some stats and timer estimations.

I made that in perl using the apache request modules, nothing hard/horrible or microsofty about it.

I've only heard of Ajax today.

Disconnected Ajax by castoridae · 2005-12-07 05:55 · Score: 1

I tried Google maps disconnected, seemed to work just fine (no reason it shouldn't) until I scrolled outside of the pre-loaded map images.

Anyone tried using Ajax techniques to build a disconnected store-and-forward capability into a form? Intercept the form submit, store the variables into a cookie, send cookie data when the connection is back... Any gotchas here that I'm not thinking of?

Would be valuable for embedding "standalone" capabilities into browsers that have spotty network links (yeah, Verizon!). Too bad that a lot of mobile device browsers wouldn't have an XMLHttpRequest object built in (or even JS...).

Re:Disconnected Ajax by SharpFang · 2005-12-07 07:19 · Score: 1

store the variables into a cookie...Any gotchas here that I'm not thinking of?
Cookie size.
Instead, just create a hidden frame and store this all in RAM as javascript objects. Cookies are good just for surviving client crashes ;)

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2

AJAX is far behind what Microsoft created by davegust · 2005-12-07 06:01 · Score: 4, Interesting

Correct me if I'm wrong, but didn't Microsoft invent XMLHttpRequest? In which case, most AJAX, which uses XMLHttpRequest, is in fact built on Microsoft technology, and they deserve credit for having a played key role.

You are absolutely correct. In fact, Microsoft 5 years ago went far beyond what AJAX is today. The XMLHttpRequest object can act as a data source for binding directly to the IE DOM controls - without scripting to parse the data. I created an statewide budgeting app based on this technology 5 years ago for the Idaho Division of Financial Management. It allows a collaboration app like experience with reduced deployment effort. An ideal IT solution.

Re:AJAX is far behind what Microsoft created by Anonymous Coward · 2005-12-07 07:13 · Score: 0

An ideal IT solution.

Apart from the lock-in

All of this can be solved by alphorn · 2005-12-07 06:02 · Score: 5, Insightful

The problems mentioned can all be avoided.

The back button can be made to work. We went to great lengths to make sure the back button takes you to the previous view in http://map.search.ch/ . Try clicking it for a zoom, then hit the back button.
The fact that URLs don't auto-update doesn't mean that permalinks are impossible. We create a permalink every time you do a search or enter the "email this page" screen. See http://map.search.ch/zurich
Even auto-updating URLs when navigating inside an AJAX app are possible, we have plans to implement that in the future.
And of course, our map works just fine without javascript. http://map.search.ch/?s=1

And yes, we've had all of this from day one - months before google maps. Admitted, many AJAX apps still dont bother to do any of this - I'd say let's adress that instead of abandoning AJAX.

Re:All of this can be solved by Calamity+Jane · 2005-12-07 11:10 · Score: 1

I'm interested in your plan for auto-updating URLs -- how do you intend to implement that? Won't you lose application state etc on the new page load?
Re:All of this can be solved by Anonymous Coward · 2005-12-09 04:48 · Score: 0

Great site. I commend you on the implementation.

You should seriously branch out and market those skills. Seriously, I will hire you in a second. Want a new job?

Incorrect... by Phil+John · 2005-12-07 06:05 · Score: 1

...XMLHTTPRequest (what AJAX is a buzzword for) was first introduced by Microsoft in IE 5.5. Gecko based browsers then implemented XMLHTTPRequest a little later (changing the methods slightly).

Originally it was an ActiveX based control that got loaded by IE to perform this function, that's not the case as of IE 6.

--
I am NaN

Re:Incorrect... by thpdg · 2005-12-07 06:34 · Score: 1

Not exactly. The MSXML has supported an object with similiar functionality, and has been well used in the web based version of Microsoft Outlook.
Every book and web based resource on the topic of AJAX acknowledges Microsoft's contribution, but credits Mozilla with the creation of the XMLHTTPRequest javascript command that most people associate with AJAX programming. The top of every AJAX program usually contains a browser check that requires use of the ActiveX object on IE, or the XMLHTTPRequest on Mozilla, Firefox and Safari. Opera has only just recently added support for the command in their newest browsers.

--
-Patrick

"They never stop thinking about new ways to harm our country and our people, and neither do we."

If this is a spoof, what's the point? by daviddennis · 2005-12-07 06:07 · Score: 1

Seems like his objections are still completely accurate, unfortunately.

So is he simply saying that things never change and people still recycle the same bad ideas as in the past?

D

Um, Ajax is not an MS Technology by Anonymous Coward · 2005-12-07 06:10 · Score: 0

Ajax is a methodology.

No, IFRAMEs are useless (primarily abused for a .. by Anonymous Coward · 2005-12-07 06:17 · Score: 0

99% of IFRAMEs on the web are used for ad banners.
The other 1% are used to exploit IE vulnerabilities.

I thank the LORD that Netscape Communicator does not support IFRAMEs. It's one of the main reasons why I still use it (although I do use other browsers too.) Now when will other browsers give me the option to disable IFRAMEs altogether?

But what if... by Shotgun · 2005-12-07 06:17 · Score: 1

What if it is your goal to lock sucker^H^H^H^H^H^H'consumers' into a website?

What if you have dynamic data that you don't want bookmarked or indexed?

What if you're underwear are REALLY dirty?

Sometimes, AJAX is indispensible.

--
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba

This is SO ironic! by Spy+der+Mann · 2005-12-07 06:18 · Score: 2, Interesting

One of the reasons people used frames was to avoid HAVING TO RELOAD the pages on webapps! And this is what AJAX gives us. (Personally i'd be pretty happy when XUL engines become available for all browsers).

Re:This is SO ironic! by trewornan · 2005-12-07 08:00 · Score: 1

Personally i'd be pretty happy when XUL engines become available for all browsers
I hear that should be right after Duke Nukem Forever is released.

Ajax by Anonymous Coward · 2005-12-07 06:19 · Score: 0

All,
Well, I'm with the author. However, I think the back button thing and non working bookmarks are intentional, by design. It sort of fits in with Microsoft's "DRM/Use Once/Content Control" content crippling philosophy. Ajax 4tw! I think it's right on target. It's ok, MS will abandon this like it will .Net and soon it won't be around anymore, replaced by something even more stupid.

It boggles the mind that developers waste time learning MS's throw away technologies. JSP, Servlet, J2EE, Perl open source technologies, learn them and use them for life... 'nuff said. They enable content and information, not cripple it.

-AC

SPOOF by techfilespt · 2005-12-07 06:22 · Score: 1

Read the last line. FTA: This is a spoof article. Please compare it with the original and you will see how little it has been changed. Oh brother. I saw this on DIGG yesterday. Looks like the editors didn't RTFA

Comment removed by account_deleted · 2005-12-07 06:24 · Score: 1

Comment removed based on user account deletion

Right idea, wrong paradigm by bradleyland · 2005-12-07 06:24 · Score: 1

The spoof speaks of AJAX in the paradigm of web pages as content, not as applications. If you're using AJAX to deliver your content, and it breaks as the article describes, well then you've got a problem, but the real strengths of AJAX are not in the ability to deliver content, but to push the web browser beyond content delivery into the application space.

OO Writer has no back button. Why? What is "back" in the context of authoring a document? You could come up with analogous elements, but they have their own name and their own behavior. Usability has universal elements, but it is also context sensitive. Take Google maps for example. How does the back button affect the page when I have moved the map? How should it affect the page? In my opinion, the back button is tied to navigation, and should remain within that scope. If I press the back button, I don't want it tied to actions I've taken within an application I'm using on the page, I want it to take me back to the previous navigable location.

In this way, I think that the author has mistakenly correlated frames and AJAX. Application state and browser state can be separate and usable.

Re:Right idea, wrong paradigm by SharpFang · 2005-12-07 07:14 · Score: 1

OO Writer has no back button. Why? What is "back" in the context of authoring a document?
"undo". It does have it. And it would suck without it.
Unstructured Undo in Gimp is mentioned as one of its most serious weaknesses (as opposed to the one in Photoshop, where you can undo any previous step without affecting the ones that happened later)

Take Google maps for example. How does the back button affect the page when I have moved the map? How should it affect the page?
Take you back in the history of your "map travels", say, one map drag, zoom click or search back. Obvious from user point of view. Helluva hard from programmer's point of view. Thanks to AJAX.

I want it to take me back to the previous navigable location.
Previous seen email in GMail, previous seen location in Google Maps, previous config screen or any other perceivable previous navigation unit. AJAX blurs/removes them. Is the next tab of DeviantArt prefs a new page or not?

Application state and browser state can be separate and usable.
Can be. But more often isn't than is.

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Re:Right idea, wrong paradigm by bradleyland · 2005-12-08 03:44 · Score: 1

"undo". It does have it. And it would suck without it.
Unstructured Undo in Gimp is mentioned as one of its most serious weaknesses (as opposed to the one in Photoshop, where you can undo any previous step without affecting the ones that happened later)
Undo is an entirely different functionality than browsing backward in a series of navigation steps. Using the back button as an undo event sink is a terrible idea IMO. Structured undo (as in Photoshop) is a great idea, but it should be implemented within the application.

Take you back in the history of your "map travels", say, one map drag, zoom click or search back. Obvious from user point of view. Helluva hard from programmer's point of view. Thanks to AJAX.
Again, I'd disagree. If a web page contains an application, I believe they should exist on separate layers. The application should be built within the browser space, but to a certain degree, maintain a layer of separation.

Previous seen email in GMail, previous seen location in Google Maps, previous config screen or any other perceivable previous navigation unit. AJAX blurs/removes them. Is the next tab of DeviantArt prefs a new page or not?
Tabs in the context of web pages already have an expected behavior. Tabs in the context of applicatios already have an expected behavior. Unfortunately, they are in conflict. When you click the back button, does Firefox take you to the previous tab (as in browser tab, not web page tab?
Re:Right idea, wrong paradigm by SharpFang · 2005-12-08 09:40 · Score: 1

Undo is an entirely different functionality than browsing backward in a series of navigation steps.
Not -entirely-. Somewhat different. Undo differs from app to app too. In some it takes back the last keystroke, in some the last paragraph. I know one where it just recovers the project template, discarding all the changes since last save (do I have to say how much it sucks?). In browsing, "back" moves by a single navigation unit, a page. It's the undo in context of plain HTML, not concerned with scripts, embeds, forms, redirects and other entities beyond the scope of normal webpage.

Using the back button as an undo event sink is a terrible idea IMO.
As the lowest-level undo, like unclick a checkbox, reopen previously closed "image properties", yes. But in context of plain navigation, it IS an undo event sink.

Structured undo (as in Photoshop) is a great idea, but it should be implemented within the application.
Sure. Rarely they implement -any- undo though, while breaking the simple pseudo-undo of a back button, so Ajax sucks most of the rest of the time. In browsers, you can skip multiple pages back already, and removing one older navigation step from the stack wouldn't make sense.

Again, I'd disagree. If a web page contains an application, I believe they should exist on separate layers. The application should be built within the browser space, but to a certain degree, maintain a layer of separation.

And here we agree. Webdesigners using Ajax mostly disagree with both of us though. If you make it an app, if you make it clear it's an app, not just a webpage, if you provide all the functionalities one would expect from an app, and preferably break as few functionalities of a webpage as you can, then your AJAX app won't suck. This is rarely the case though. Usually the random blend of an app and a webpage makes it extremely hard to distinguish, where you can use your webpage habits and where they are broken, whenever they are broken, rarely any app-level replacement is to be found, and while AJAX is an interesting tool that -can- make really good and interesting apps, currently wherever applied it usually sucks.

Tabs in the context of web pages already have an expected behavior. Tabs in the context of applicatios already have an expected behavior. Unfortunately, they are in conflict. When you click the back button, does Firefox take you to the previous tab (as in browser tab, not web page tab?
I use the "go back to referrer" bookmarklet for that, and it doesn't switch tabs, but loads the page from which the tab was opened from, as an additional step of "back". I imagine the structure of navigation not as a timeline like in "history" but as a tree of pages being open in separate tabs, closed tabs being ends of the branches, pages open from bookmarks or typed in URLs as roots etc. I'd yet have to see a navigational interface to utilize this point of view.

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2

What about Java Applets? by Anonymous Coward · 2005-12-07 06:25 · Score: 0

No to dig up old debates with tons of flame, but...
What about using Java Applets? Over the last decade, computers and networks have become much faster. The technology does have many good uses and just about every browser supports Java.

Why not give Java Applets a second look?

BTW: I have always (ALWAYS) thought building applications inside a web browser was a bit odd -- in the way of "A hammer can be a tool to fix everything"

Re:What about Java Applets? by SharpFang · 2005-12-07 07:05 · Score: 1

Over the last decade, computers and networks have become much faster.
10 mbit ethernet, Athlon 2400, 1 gig of RAM, loading the ssh applet takes about two minutes.
The computers still need another decade or so to make applets a viable option.

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2

When It's OK to Use Ajax by lux55 · 2005-12-07 06:26 · Score: 1

Hilarious! From the article:

<snip>
If you are working in a Web2.0 company that needs to provide evidence of their technical expertise in order to gain new clients. However, you must remember to keep your offering in beta and make sure that it in the same family as these examples:

* geotag-based apps via flash
* tag-based instant messaging via Ruby on Rails
* community podcasts via api mashups
</snip>

Despite the fact that this is a spoof article, it's still a good opportunity to discuss the accessibility issues (or at least raise the awareness of them and their importance) found in many AJAX-style apps. I'm feeling lazy today though, so instead of discussion I posted the above. Enjoy!

--
putfwd.com - 1GB Free file storage with a twist

Take that digg by Matt+Clare · 2005-12-07 06:26 · Score: 0, Offtopic

AJAX sucks, take that digg.

We hate you.

--
.\.\att Clare

Re:Take that digg by Matt+Clare · 2005-12-07 06:28 · Score: 1

In case no one noticed, I'm implying that was the editorial decision behind posting the article. It's certainly not how I feel as someone who just implemented AJAX on one of my sites and a big digg.com fan.

--
.\.\att Clare

Extending HTTP to the point of ridiculousness... by puppetman · 2005-12-07 06:27 · Score: 1

HTTP and HTML were not designed for stateful sessions, with near-realtime communication between the browser and the server.

In the last 20 years or so, we've gone from stateless pages that display text and images from a remote server, to a technology that uses URL re-writing, cookies, hidden fields, and java-script to add functionality (like sticky sessions, clustering, and near-realtime client-server interaction).

HTML/HTTP are not the technology for doing this heavy-lifting. Technologies that have tried to do the heavy-lifting in the browser (Java Applets, ActiveX, and CURL) have all failed miserably.

Adding another technology to try to get the web browser to do something even more interactive is, IMHO, a waste of time. FTP and email haven't had the (inappropriate) feature creep that web-based technologies have.

We need something new. Something that runs in the browser, securely, that doesn't require a huge installation beyond the browser, that is designed to do what HTTP/HTML was not designed to do, but is doing anyway.

so close... by javaxman · 2005-12-07 06:30 · Score: 2, Insightful

So close to being insightful and yet so far...

My first clue that something was wrong with this was in the article summary... since when is AJAX considered a "Microsoft technology" ? If there's a defining AJAX app, isn't it Google Maps ? Is there some Microsoft AJAX app or developer kit I should be aware of ?

I'm going to have to disagree with something you've said, though :

we all need to evolve past the "You are looking at a flat page" ideology.

Why ? Flat pages are very useful for documents. Hyperlinks are great for linking documents. "Plain old web pages" remain, IMHO, the most useful aspect of this thing we now call "the web"... cool apps like Google Maps are cool and all, but they'd be just as cool ( probably cooler ) outside of a browser. Requiring a high-speed connection and robust ( or even particular ) Javascript implementation on the client side just to view your web page is what doesn't make sense, at least to me.

Then again, maybe I'm just getting old, but back in the day, we just had static web pages and forms, and we liked it!

Re:so close... by Prophet+of+Nixon · 2005-12-07 06:47 · Score: 1

Yea, its called Outlook Web Access, and its been around since at least 2000 (when I first used it).

And there have been plenty of city/school/regional web applications using "AJAX" techniques for years now, especially for GIS data. Google has refined it a lot and made some impressive javascript, but they hardly define it.
Re:so close... by galego · 2005-12-07 07:24 · Score: 1

Then again, maybe I'm just getting old, but back in the day, we just had static web pages and forms, and we liked it!
Yeah ... sounds like the time I asked my Dad to spot me a buck via paypal and he told me how he had to kill a bear with a notebook as he walked home from school (which was uphill both ways) bare foot in the snow. And of course ... he was grateful! ;)

[Paraphrased (and embellished) from something I heard from Bill Cosby]

--
Que Deus te de em dobro o que me desejas
[May God give you double that which you wish for me]
Re:so close... by javaxman · 2005-12-07 07:52 · Score: 1

Yea, its called Outlook Web Access, and its been around since at least 2000 (when I first used it).
Thanks for that. i keep forgetting. Probably on purpose. It sucked then, too ;-)
Humor, people, humor!

Don't try to take issue with slashdot doctrine by I'm+Don+Giovanni · 2005-12-07 06:36 · Score: 1

You do realize that you're going up against the /. groupthink that MSFT never innovates anything. Posting your info is equivalent to talking to a wall. LOL

--
-- "I never gave these stories much credence." - HAL 9000

AJAX & Hotmail Bad-perience by managedcode · 2005-12-07 06:36 · Score: 1

I receive 10 emails of which 9 are junk. I delete them and guess what happens the next time when the page load, those 10 e-mails appear as they are. Now I delete the browser cache and reload, "connecting hotmail" and don't understand where the fuck its trying to connect to.

Kenamea, KnowNow and others... by Anonymous Coward · 2005-12-07 06:38 · Score: 0

Solved a lot of these problems with the async messaging to web browser systems of a few years ago. For various reasons they both pretty much
failed but people should be able to pick through the ashes and build on what they had learned.

*Yawn* by djdole · 2005-12-07 06:38 · Score: 1

This "break back button" "Bookmarks/Can't pass url to friends" etc. is OLD NEWS, and not worth green-lighting.
(And if it's not old news on /. then /. is just slow to post it.)

Besides, the points are moot in that they aren't really reasons Ajax 'sucks',
They're just pitfalls that novice programmers will fall into.
Experienced/thoughtful developers will be mindful of these pitfalls and know how to handle them.

And the point that search engines don't know how to navigate Ajax enabled pages, is asinine.
Ajax isn't anything NEW anyways, it's just a new BRANDING (read naming/use) of OLD technologies (JavaScript & XML), and engines have been capable of handling them for YEARS (or even decades).
Besides, Google can navigate them, and any other respectable engine will be able too, (if not the engine isn't worth using anyways). (Infact, many google pages MAKE USE of Ajax)
And even if SOME engines can't navigate them NOW, doesn't mean we should stagnate progress.
If sites DON'T implement Ajax, engines will have NO REASON to support Ajax navigation. /Wasn't worth my time, but I'm REALLY sick of seeing these pointless Ajax bashing articles/posts.

Re:*Yawn* by Zphbeeblbrox · 2005-12-07 07:37 · Score: 1

Ajax on my CMS admin interface is good. Ajax on my site's homepage is not neccessary. Lets not confuse what Ajax is with how people use it. There is a reason backbuttons don't exist in a lot of desktop applications. It's because there isn't a use for them. The undo button perhaps but not a back button. The same thing goes for web applications. A web application isn't there to to be spidered by search engines, or browsed like wikipedia. The real problem they are talking about is people treating their online information sites like web applications. There is a difference between a site of howto's and an interface to manage those howto's. It would be nice if people would clarify their terms and speak in context on these things but then I guess that would be too sensible.

--
If you see spelling or grammatical errors don't blame me. I tried to preview but IE here at work borked the CSS

Re: trademark infringement by lahvak · 2005-12-07 06:40 · Score: 1

Not until somebody writes a bathroom cleaning web application.

--
AccountKiller

Hi-larious by chhupa_rustam · 2005-12-07 06:41 · Score: 1

Yeah dude, AJAX sucks, which makes sense since it's a Microsoft technology, but huh, who do they think they are, claiming to have 'invented' AJAX with that XmlHttp thing?! Loooooosers!

Wrong, again by brunes69 · 2005-12-07 06:41 · Score: 2, Informative

Do you even know what AJAX stands for?

Asynchronous
Javascript
And
XML

See that first part? Asynchronous? You can't do that without XMLHttpRequest*. AJAX is not a methodology without it.

Basically, AJAX *is* XMLHttpRequest, because you would not use XMLHttpRequest for anything else, and you can't do AJAX without it. The whole acronymn is retarded and useless, and created by a marketing junkie at Adaptive Path to drive up business. It is no more a "methodology" than wiping your ass.

* I am not including iframe refresh hacks here, because they are not really asynchronous (watch your web browser spinning icon!), though they accomplish the same goals.

Re:Wrong, again by deserttrail · 2005-12-07 13:27 · Score: 1

they are not really asynchronous (watch your web browser spinning icon!)

I really don't see what the throbber has to do with anything... It indicates that the browser is communicating with the server, you think the XMLHttpRequest object isn't?

Asynchronous refers to the ability to make the request, then continue processing (i.e. executing more javascript) while you're waiting for the request to be fulfilled. This is perfectly accomplishable with "iframe refresh hacks." So no, the "asynchronous" part does not force the use of XMLHttpRequest. There isn't a single thing you can do with AJAX that you can't do with an iframe. XMLHttpRequest just makes it a lot easier.

--
Be civil to all; sociable to many; familiar with few; friend to one; enemy to none. --Benjamin Franklin

The ramblings of a reminiscing old man... by Nephroth · 2005-12-07 06:42 · Score: 1

I remember the Internet. It was great, it contained tomes of information, right there in plain black and white and anyone with sufficient knowledge and a little money could contribute. It was glorious.

But then corporate interest came into the picture, soon there were people making money advertising on the Internet, soon after that every major company, and most minor ones had an internet presence. Not long after that, their money started to influence the Internet, making it no longer a hub of information, but a hub of money for companies already too rich for their own good.

Those companies did to the internet and especially http, the same thing they did with so many other things, they took it too far, stretched it too much. They expected it to perform in the place of other systems in the interest of saving themselves money on distribution in exchange for functionality and customer satisfaction.

Now days the internet is full of web-based applications that attempt to mimic the functionality of local applications, with very few succeeding.

I think, perhaps, it's time for us to stop trying to make the internet something it's not. Are animated drop-down menus and interactive widgets really that important? What is so wrong with saving application functionality for protocols designed to handle it like SSH and Telnet? Nothing.

--
Our greatest enemy is neither a single man, nor is it a nation, it is, as it has always been, our own greed.

Re:The ramblings of a reminiscing old man... by SharpFang · 2005-12-07 06:57 · Score: 1

What is so wrong with saving application functionality for protocols designed to handle it like SSH and Telnet?

Idiots.
Show one the black window of Telnet and tell to type 'pine' and they will freak out and cry 'i don't want it, I don't need it, I have my Hotmail account." Faced a few in my time, some calling themselves admins too.

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Re:The ramblings of a reminiscing old man... by Anonymous Coward · 2005-12-07 07:14 · Score: 0

What's this 'Pine' nonsense.

telnet 25, like a real man!
Re:The ramblings of a reminiscing old man... by Anonymous Coward · 2005-12-07 08:03 · Score: 0

Just because someone isn't as computer saavy as yourself does not mean that they're an idiot. Realize this and get off your high horse, and perhaps you'll stand a slightly better chance of losing your virginity.
:-)
Re:The ramblings of a reminiscing old man... by grumbel · 2005-12-07 08:35 · Score: 1

### What is so wrong with saving application functionality for protocols designed to handle it like SSH and Telnet?

The complete lack of any graphical abilities of both them aside, they also suffer from *HUGE* latency problems, since each keypress get transmitted instantly and becomes only visible once the server has send it back to you. With simple Webforms or AJAX on the other side most of the input is done on client side and only high-level requests are send to the server, applications are thus far more responsible then your standard programm via ssh/telnet. That said I wouldn't mind some alternative to AJAX, since the webbrowser is really not that great for applications for numerous reasons, but so far its the best we have and any alternative would have a hard time getting as widespread use as browsers have today.
Re:The ramblings of a reminiscing old man... by SharpFang · 2005-12-07 09:02 · Score: 1

As for the first point, trying it out and saying "no, it's too hard for me, I can't handle this" is one thing. Saying what I cited, that is refusing to try it and investigate it and plainly refusing the new(old?) (even if WAY easier and more handy) tech because it means learning two lines of commands is another.

Concerning your second point, already done. The bucket broke while trying to have sex with a high horse, lost my virginity to a pony mare. Really.

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Re:The ramblings of a reminiscing old man... by Nephroth · 2005-12-07 09:55 · Score: 1

Complete lack of graphical abilities doesn't concern me.
SSH is plenty swift, and you don't need low-latency to read your e-mail. The idea that a good interface has to involve a lot of pretty colors is a rather new, and rather ill-conceived. A text-only program can have the exact same functionality as a graphical one and often times more. The learning curve for the software isn't any harder than that of graphical software, people are just daunted by text. People should get over their fear of reading.

--
Our greatest enemy is neither a single man, nor is it a nation, it is, as it has always been, our own greed.
Re:The ramblings of a reminiscing old man... by grumbel · 2005-12-07 10:48 · Score: 1

### you don't need low-latency to read your e-mail.

I for one prefer to be able to scroll precisly through my mail instead of everything happening with a one second delay and thus often opening the wrong mails. Latency is a *big* issue with SSH, its less of an issue if the machine you are connecting to is only a few feet away, but if you connect to a machine at the other end of the world, as you often do with normal webpages, it becomes a huge issue.

### A text-only program can have the exact same functionality as a graphical one and often times more.

It can never have more, since graphical interfaces can do everything that text one do. Its also not about 'pretty colors' its about using a line where you need a line and not a piece of ASCII art constructed out of -, + and |'s. SSH has definitivly its uses and does what it does very well, but its neither a AJAX replacment or very usefull for general purpose webservices.
Re:The ramblings of a reminiscing old man... by Nephroth · 2005-12-08 02:35 · Score: 1

Firstly:
You are not going to experience that degree of latency from a server with a decent amount of bandwidth. And it takes a second or two to open an e-mail on an AJAX client, so the time difference doesn't concern me. "Precise scrolling" is an amusing term to use here; you are not tuning a radio, you're selecting something from a list. A page at a time isn't any harder to use.
Secondly:
Yes, text-only programs CAN provide the same functionality and more. Being pretty is not a function, it's aesthetic and aesthetic is negligible in importance. Text-only can provide more functionality in that while graphically something might require a slew of buttons, check boxes, and input fields, it can be acomplished with a single command that takes a fraction of the time to input. Ease and efficiency of use vastly outweighs visual aesthetic in my mind.
I am not saying that SSH is a replacement for AJAX, I'm saying that web-based services are all broken and I'm remembering back to the "good ol' days" when the internet was mostly just a lot of text. We have spent so much time and effort into trying to make web pages into applications instead of pages and in the process created a lot of half-baked methods to facilitate it. AJAX won't last any longer than any of the other methods, and 90% of the things implemented with it will be poorly done just like 90% of Java for websites is poorly done, and 90% of DHTML is poorly done... I'm simply advocating that we either decide on a very strict standard for web-based applications (and, even then, I fear what people will attempt to do) OR we scrap the whole idea of using HTTP for hosting applications and come up with a new protocol specifically tunde to perform the task.

--
Our greatest enemy is neither a single man, nor is it a nation, it is, as it has always been, our own greed.

Shameless Plug by mattwarden · 2005-12-07 06:42 · Score: 2, Interesting

I know that pimping one's own stuff is severely looked down upon here, but I actually do a pretty good job of pointing out the caveats in my AJAX chapter in Professional LAMP by Wrox/Wiley, just released a few days ago. I also point out the likeness of AJAX misuses to the misuses of Flash.

Basically, there is a lot of hype because that's what gets out first. Books don't really create hype. Articles and articles about articles create hype. These have quick turnaround, so they get out first. Then you get a wave of articles about the other side. It takes more room to talk about both sides, and this usually happens in books, which have a much longer production cycle.

In other words, I think we're definitely over the crest of the hype wave. Now we can get onto actually using AJAX for useful things.

Burn, karma! Burn! (At least I didn't post the amazon link with my associate code, which I've seen many fellow pimps do.)

AJAX isn't web pages by chroot_james · 2005-12-07 06:45 · Score: 1

AJAX isn't for webpages. It's for applications. People will misuse technology until the universe implodes. If you want something that prints nicely, then provide a link that takes you to a page where you can print easily. If you want the webpage to alter shape and work quickly for the user to get things done, then who cares about printing... The person who wrote that article is a luddite and a whiner.

--
Reality is nothing but a collective hunch.

Ajax is also a laundry detergent. by Anonymous Coward · 2005-12-07 06:47 · Score: 0

Ajax is a cleanser. Tide is a clothes washing detergent.
I beg to differ.

Posted AC because this is completely pointless.

Re:PHP isn't difficult to learn. by groovemaneuver · 2005-12-07 06:49 · Score: 1

While PHP certainly makes it easy to write crappy, insecure code, I'm not sure that any language really defends against bad programmers. Like any programming language, PHP is a powerful tool in the hands of a talented developer, but a security breach waiting to happen for those lacking such talent.

The web isn't good enough, and AJAX helps fix it by fzammett · 2005-12-07 06:50 · Score: 1

This points in this article, whether they were meant in jest or not (yes, I saw the comment at the bottom, but I'm not sure that comment ITSELF wasn't the joke) extend from one false assumption: that the web as it is today is good enough.

It isn't.

Another poster put it quite perfectly: the web has evolved into two "tracks", if you will: the data presentation track, and the web application track.

For the data presentation track, what we have is quite good enough, and quite well-suited to that purpose. Hyperlinking of simple documents was a powerful idea when first devised, and it continues to be so today.

But, when you start talk about hosting applications of even modest complexity on the web, it doesn't work as well. What we've been doing the past 10-15 years is really hackery. Successful hackery in many cases, but hackery none the less.

AJAX is a step in the rigth direction. Not the first step (AJAX can be done just as well without the XMLHttpRequest object, and was years ago, and we won't even mention Flash, applets and the other competitors), but a good step.

AJAX has its problems, accessability in my mind being chief among them. And I for one don't have the answer to that problem. But it shouldn't change the fact that if you are on that web application track, it might just be a sacrifice that has to be made. Or a solution needs to be found

--
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa

No Developer Tools by pmike_bauer · 2005-12-07 06:50 · Score: 1

My biggest problem with AJAX is its paucity of tool support.
I want a debugger smart enough to jump from JavaScript code in the browser to Java/.NET running on the server and back.

I can launch an all-Java client interfacing with an all-Java server from inside my IDE and step through every bit of code seamlessly. I can't do that with a JavaScript client.

--
I read /. for the (Score:-1, Conservative) comments.

abuse probable, but that shouldn't stop people by penguin-collective · 2005-12-07 06:53 · Score: 1

AJAX will probably be abused. In particular, lots of desktop developers will see it as the technology that finally enables them to force their lousy desktop apps on web users. That's abusing the technology.

But AJAX does let us do things that were messy or impossible before. Google's use of AJAX has been pretty good: it's being used for live updates of in-page information, for scrolling of large maps (with a "bookmark this" feature), and intuitive customization of the home page.

So, AJAX most sucks, but web sites in general mostly suck: people use HTML, DHTML, Flash, JavaScript and Java inappropriately, too. That shouldn't stop us from making new technologies available and for the people who use them carefully to actually use them.

Mod parent up by Exaton · 2005-12-07 06:54 · Score: 2

So the article is a spoof -- knew I'd read all that already somewhere -- but I say it's illegitimate : comparing AJAX to frames is most insulting in the most unjustifiable way.

Moving on, *NEWSFLASH* : technology can be misused !

AJAX is all about being used properly, respecting and avoiding the navigation problems it can raise. So why's everybody so upset about something they have to be careful with ? It's powerful, mind how you handle it !

Bunch'a unhappy crybabies. Badly used AJAX is just another way to root out incompetent Web developers ; the more such red flags there are, the better. Natural selection, you know ?

Please respect the healthy and non-AC troll, thank you.

Actually Microsoft's AJAX is Atlas by boatboy · 2005-12-07 07:01 · Score: 1

While MS invented XmlHttpRequest, it's worth noting that they have been markedly timid in recommending it's use in client development. I'd contend their relative silence on the issue is due to these usablility concerns as well as security, etc. I haven't installed the preview of their solution, dubbed Atlas, but from what I've read, it does address some of these issues by giving a solid framework for developing controls that support both dynamic and static models depending on the browser caps, etc...

Problems with Ajax the article didn't mention by strlen · 2005-12-07 07:02 · Score: 1

There's also problems with Ajax, that I myself have found that the article fails to mention explicitly -- although definitely hints at them. First is that Ajax violates the principle of separating design (e.g. the presentation layer -- that is the webpage that you see) from business logic(e.g. the domain layer). Some of the MVCs with Ajax support attempt to remedy it (e.g. Ruby on Rails), but overall Ajax does fly against the very idea the MVCs try to implement (that is, they allow for strict separation of the three layers of architecture). Finally, the use of XML by Ajax (the X in Ajax) also brings in the storage aspect (e.g. the persistence layer). Thus you end up with code that is *hard* to maintain: if you, for instance, need to have a mobile version of an Ajax site (or a GUI app, etc..), you will need to re-implement the logic (and possibly the storage) aspects as they're far too mixed up with the design.

Second idea is somewhat hinted of by their discussion of the back button: that is that Ajax violated the atomic ``transaction'' based character of the web. The web functions best when I make a *single* query and receive a *single* response. This is very much a batch system: we can compare CGI get/post requests (sent from specific forms on the site as a *whole*) with punch cards being fed into a card reader and the resulting page as either a new card or a print out on a line printer. Or alternatively, you can compare it with an SQL query (or a transaction with an rDBMS) -- or with a *fixed* amount of queries (and not dynamic queries). In other words, the web isn't meant for real-time interaction.

There are of course good applications for Ajax: anything geographical or spatial is a good application (e.g.: maps) as are tools such as spell-checking for web-forms in real time (ala gmail); but there are places where I wouldn't like to see Ajax (e.g.: on a purchase form of an e-commerce site, on a class registration page for a university) -- namely because I want those sites to have a *clear* and simple architecture and design (and work as intended), be accessible from everywhere and give me a clear result (either I registered for CS 345 or I didn't; either I purchased a book, or I didn't).

Re:Problems with Ajax the article didn't mention by hiero · 2005-12-07 09:48 · Score: 1

Nonsense. There is no reason to assume that the use of Ajax will break the MVC model, unless you implement it badly. The difference is that the page is making the HTTP request instead of the browser, but it is still just a request. Data is being passed to the server, the server processes, and data is passed back to the client. All of the controller and model code still reside on the server, Ajax doesn't make you implement such logic in the page.

Single query and single response? I fail to understand your point. Ajax doesn't support multiple simultaneous queries, nor does it support multiple simultaneous responses. It is still one request, one response. Its just a different type of request than POST/GET.
Re:Problems with Ajax the article didn't mention by bandersnatch · 2005-12-07 12:37 · Score: 1

I'd add one other problem that often gets lost in the technical discussions on Ajax and that is readability for the disabled. For example a page reader for the blind. I haven't run any trials in this area, but I imagine that trying to put any page with Ajax through a page reader would be a near impossible task.

Re:PHP isn't difficult to learn. by Anonymous Coward · 2005-12-07 07:03 · Score: 0

So where do you go to learn how to make PHP secure? I've seen lots of books, lots of sites giving code and tutorials on PHP, but none on how to write *secure* PHP. Sure, lots of them will say things like "validate your input", but no tutorials on that and other elements that are needed to make an application secure.

Re:PHP isn't difficult to learn. by CyricZ · 2005-12-07 07:14 · Score: 1

The Hardened-PHP project is one place to look.

Of course, the best option for serious work is to probably just avoid PHP, and stick with solutions that have proven themselves to be well-designed and far more secure.

--
Cyric Zndovzny at your service.

AJAX for Forums... by PJ+Brunet · 2005-12-07 07:15 · Score: 2, Interesting

One thing I noticed lately, more sites have edit boxes so that when you click "submit" the edit box fades out and your text magically merges with the page... great for forums especially...saves time--there's no page refresh, and it's cool. Busy forums will benefit greatly from AJAX--I'm thinking that you'll be able to watch the threads move down and the post counts change in realtime--you'll have something like a chatroom but much more powerful. If you want to take it to the next level, come up with an AJAX blog monitoring system that takes data from blogs and aggregates it into a threaded forum format, take all the comments and trackbacks and put them all under one thread--and allow the user to collapse by reply/offsite-comment/trackback/offsite-trackback, now your forum is flying--then you would need some filters to keep it under control. If you decide to this, send me a copy please ;)

Buzzwords by DimGeo · 2005-12-07 07:27 · Score: 1

People rave about buzzwords when they haven't done their homework. On a side note: AJAX is a MS tech? WTFrack?!?

Re:Extending HTTP to the point of ridiculousness.. by 10Brett-T · 2005-12-07 07:30 · Score: 1

Adding another technology to try to get the web browser to do something even more interactive is, IMHO, a waste of time. FTP and email haven't had the (inappropriate) feature creep that web-based technologies have.

When's the last time you used FTP? For the most part it's been supplanted by FrontPage Extensions and HTTP PUT for the average user, or scp/rsync for more advanced users. I'd consider using email as a delivery method for eye-candy HTML-formatted messages with images a bit of feature creep.

We need something new. Something that runs in the browser, securely, that doesn't require a huge installation beyond the browser, that is designed to do what HTTP/HTML was not designed to do, but is doing anyway.

I must be misunderstanding your point, because that's pretty much what Ajax is...

--
10Brett-T
Oh, bother.

you contradicted yourself by circletimessquare · 2005-12-07 07:34 · Score: 0, Flamebait

Ajax sucks MOST of the time. Not always.

i agree, when you don't want something to act like a webpage. why is that an impossible concept, making a broswer stop working like a browser? you can't imagine a situation where that wouldn't be ok, even preferable? well you did... with your last statement, so you contradict yourself

--
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it

Re:you contradicted yourself by SharpFang · 2005-12-07 09:19 · Score: 1

Because MOST of the time you expect a browser to act as a browser and display webpages. When AJAX steps in, you don't always know about it or really want it, and then, when browser stops acting as a browser despite what you expect, it sucks all the way. I middle-click on each of the row of new messages in GMail to open them in new tabs, as I'm used to doing whenever I see a list of links I want to open, then it doesn't work. I need to use the sucky "newer/older" navigation, and wait for next message to load from the server (XMLHTTPReauest takes time too!) instead of having it already loaded in a new tab in the background.

When you expect an app to be running in your webbrowser, be that a flash site, a java applet, a javascript piece that obviously -is- an app, then you're prepared for your browser to behave differently. You're in a "different mode" and avoid some browser features because you know they won't work or will work not as normally. But Ajax integrates so seamlessly that it's often invisible, until you try to use your god-given rights to go a page back or open a link with middleclick and find yourself out in the cold. Then it really sucks.

--
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2

This isn't news - it's a whinefest by Anonymous Coward · 2005-12-07 07:35 · Score: 0

So, Ajax isn't the magic bullet, you say? Gasp! Double gasp!!

Before we go hunting dragons in the Ajax camp, let's look at the realities: it's a step in the right direction for a lot of developers that have been starved for this type of functionality that other "real" applications are providing (and that our clients are now demanding).

Are you genuinely critiquing the many, many, many methods that are now under the Ajax umbrella, or do you have beef with people that jump on things that you're calling "all the craze"? If it's the latter, then why don't you just throw some angry comments out about iPod, PSP, and (in some camps) cellphone users? My point: don't throw a BS title onto an article and call it news when you're obvious aim is instead a jab at a collective movement that you find distasteful because you're a rebel/old skool/l33t h4x0R/whatever.

Quit bitching and find a project to work on - and THEN post something (useful).

Now I Know Who Uses Ajax Pages by Nom+du+Keyboard · 2005-12-07 07:35 · Score: 1

Now I know who uses Ajax pages. All those p0rn sites that are impossible short of a reboot to get back out of once you've fallen into one and spawned countless boardless fullscreen windows with non-functioning Back buttons.

--
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."

But by einhverfr · 2005-12-07 07:37 · Score: 1

It raises some valid points. The basic issue is that AJAX gives you interactivity at the expense of a page-based model.

This being said, there is no reason why these are fundamental issues with AJAX and not with sloppy information modelling. For example, if I go to Gmail and I bookmark the site, I always get the same view of my inbox. There is no reason why a site could not be set up to allow for bookmarks to be generated for specific views of data. It is just an issue of app design and being conscious about what your tradeoffs are.

In other words, nothing in the article couldn't be worked around with a little effort.

In general, hype is almost always associated with people forgetting what the problems with the model being hyped is. While I thought it was interesting to compare the article with the artical on frames (Frames pose the exact same challenges), I also think that it is important to understand what those challenges are so that we can workaround them if we need to.

--

LedgerSMB: Open source Accounting/ERP

Re:But by Crayon+Kid · 2005-12-07 08:46 · Score: 1

In other words, nothing in the article couldn't be worked around with a little effort.

Make that a little more effort. Perhaps more than it's worth, but time will tell on that one.

How are you going to make AJAX print well? How are you going to make bookmarks work (ie. an URL with certain components -- GET params and dirs lead to a specific view/state)? How are you going to deal with blind visitors? (more established UI API's have ways to deal with this, but there's barely a peep from the AJAX crowd.) How are you going to make AJAX respect and use the Back/Forward browser buttons?

Bottom line is, AJAX (like frames and so on) is suitable for intranet applications and other dynamic interfaces, where you don't care about bookmarks, strip the browser window of everything except the render area, produce your own print output dynamically, implement your own navigation paradigms, and don't give a rat's ass about disabled people.

--
i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
Re:But by einhverfr · 2005-12-07 09:26 · Score: 1

How are you going to make bookmarks work (ie. an URL with certain components -- GET params and dirs lead to a specific view/state)?

This is the most important one. The printing issue will depend quite a bit on implimentation and will need to be resolved partly on the browser. We solve the frame printing issue in the Browser and the AJAX issue should be a lot easier to solve because almost everything can be inline (you don't have to worry about attempting to merge layout issues from independant documents like you do with frames).

Solving the bookmarking issue is going to depend to a large extent on what you want to make bookmarkable. Then you need to put hooks in your application to generate appropriate default content based on GET variables. Then use Javascript to create the appropriate URL, redirect the browser there, and bookmark the page. As in other apps, it may not always be wise to make everything bookmarkable.

As for disabled people, if you need to provide accessibility, then one needs to have hooks into the speach browsers to allow for one to send content in a structured way to it. Although this could be done with AJAX, it would require that certain hooks be present in the browser. This issue requires some work both in the web app and in the browser to make it really usable.

So I don't see anything inherent, but these are limitations that require work in various ways. In other words, it needs to be improved. It is far less limiting than the frames concept (many of these problems are inherent to frames but only incidental to AJAX), but there is a ways to go.

--

LedgerSMB: Open source Accounting/ERP
Re:But by DavidTC · 2005-12-07 11:39 · Score: 1

AJAX doesn't require a damn thing in the web browser to support blind people. The web browser merely needs to pay attention when part of the page is changed and read it.

--
If corporations are people, aren't stockholders guilty of slavery?
Re:But by einhverfr · 2005-12-08 09:02 · Score: 1

AJAX doesn't require a damn thing in the web browser to support blind people. The web browser merely needs to pay attention when part of the page is changed and read it.

Maybe. And I had thought of this, but then I tried to think about what an actual implimentation would be like and I decided that some additional work would be required. These could be incorporated into HTML attributes or something else. Poorly done, web apps for the blind would provide a horrible user experience, so I guess the default behavior of reading what changes might not be any worse than the current situation but it is hardly ideal. It would be better to be able to give the browser some concept of verbal cues (in the same way we use visual cues) to effectively communicate the changes to the customer.

Hope this makes sense. So I agree with you from the standpoint of minimal support, but from a standpoint of full support, I could not disagree more.

--

LedgerSMB: Open source Accounting/ERP

Re:Flash - You need AFLAX - Quack !!! by dbdweeb · 2005-12-07 07:41 · Score: 2, Funny

It looks like a duck.. It quacks like a duck... It's not that insurance company... it's AFLAX... http://www.aflax.org/

Re:Extending HTTP to the point of ridiculousness.. by puppetman · 2005-12-07 07:41 · Score: 1

As a developer/DBA for a large website, we use FTP to download data feeds from our less technologically advanced partners, and SCP/web-services-SOAP/XML-over-HTTP-POST the rest of the time.

AJAX is not something new - it's embedding JavaScript inside a web page to provide updates to the web page without having to hit a submit or refresh button. It's just another inappropriate add-on to an existing technology that was never designed to do what it's doing. Putting a trailer-hitch on your car doesn't make the car new - it just gives it another feature.

Interesting... by dr_turgeon · 2005-12-07 07:44 · Score: 1

Interesting that the defenders of all things Micro$haft on Slashdot will come out in droves under the banner of "...Sucks Most of the Time"

--
"...objectivity resides in recognizing your preferences, subjecting them to especially harsh scrutiny." -Gould

Maybe it's true but irrelevant? by podperson · 2005-12-07 07:44 · Score: 1

Arguing that an AJAX app sucks because it violates bookmarking is missing the point. An AJAX app (a good one, anyway) isn't a web page that happens to be an app, it's an app that happens to run in/on a web browser. It should support bookmarking -- say -- if and when that happens to make sense, but it shouldn't be a criterion for goodness simply because it's a criterion for goodness in the underlying technology.

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.

Right, and aircraft violate the unified model of human beings by allowing us to fly.

AJAX apps need to be compared to other apps, not other web pages. And yes, AJAX apps may suck for reasons along the lines of "a dog that can walk on its hind legs" but that's a different kind of (and much more valid) criticism.

AJAX apps allow for interactive apps to be implemented cross-platform in a browser; in many cases "bookmarking" would be a BAD thing. (E.g. bookmarking a view of a secure document *shouldn't* work in some sense.) I don't have the ability to bookmark my email in either Outlook or gmail -- I'm guessing that if there were a burning demand for bookmarks in Outlook it would probably get implemented.

Firefox 1.5 is 1st browser with AJAX accessibility by R4modulator · 2005-12-07 07:54 · Score: 4, Interesting

We can't ignore the fact that the exciting part of the web is moving away from documents and into applications.

It's possible to make DHTML/AJAX/Javascript applications act like desktop applications with respect to keyboard navigation (on IE and Firefox) and support for accessibility tools (currently Firefox only). This was part of the accessibility code that IBM contributed to Firefox.

Information and examples here:
http://www.mozilla.org/access/dhtml/

W3C roadmap for the developing standard here:
http://www.w3.org/WAI/PF/roadmap/DHTMLRoadmap11050 5.html

Misleading-Spiting one's career. by Anonymous Coward · 2005-12-07 07:58 · Score: 0

"Remember, buzzwords = $$$ in the eyes of those that are clueless."*

And if they were clueful? You wouldn't be browsing Slashdot from work.

*Anyway if they had the answers (aka a clue) then why do they need you?

Re:Misleading-Spiting one's career. by Anonymous Coward · 2005-12-07 08:23 · Score: 0

*Anyway if they had the answers (aka a clue) then why do they need you?

I'm too smart to work in IT. Thanks for your troll though.

Real users use the back button by SuperKendall · 2005-12-07 08:01 · Score: 1

As noted in the article, the Back button is the second most highly used button in a browser window. People WILL be using that button, and some Ajax things break if you do. The more your Ajax app looks like a web page, the more likley they will be to use that button - but even the most heavily customized page will still have that back button looming up there.

Whatever people do with Ajax I would caution that they must make sure the back button does something semi-resonable, or it will not be widely accepted. I learned this a number of years ago doing an Ajax-like web applicaiton.

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley

Wrong by fathed · 2005-12-07 08:02 · Score: 1

Ajax is a great combination of different technologies. The issues the author points out can be solved with relatively little work. Perhaps he should look at the ajax scene and try to make some pages that use ajax before he thinks that all ajax sites suck.

--
Intelligence is a matter of opinion.

Part of the problem is the ignorance by TheSkepticalOptimist · 2005-12-07 08:06 · Score: 2, Interesting

AJAX is NOT a Microsoft technology, in fact, AJAX isn't a specific technology, it's using a bunch of web technologies together (http://en.wikipedia.org/wiki/AJAX).

It gets pretty funny when people jump on the bandwagon and flog Microsoft, without doing their homework first. Someone really wanted to criticize Microsoft, and just comes off as being ignorant of the technology they are criticizing.

--
I haven't thought of anything clever to put here, but then again most of you haven't either.

How I've used AJAX by akeyes · 2005-12-07 08:18 · Score: 1

One example of how I have used AJAX is the 'Latest #PCLUG Conversation' section of our home page: http://pclug.pct.edu/

Re:No, IFRAMEs are useless (primarily abused for a by psxman · 2005-12-07 08:20 · Score: 1

http://operalover.tntluoma.com/preferences/content _preferences/

Go Opera!

High school teachers and the web by Anonymous Coward · 2005-12-07 08:22 · Score: 0

That's a problem high school teachers need to adapt to, not the other way around. The reason is that high school teachers have no choice but to cooperate at the curricular level with univsersity instructors and in academia, electronic publishing is already the norm.
In fact, the same people who make the rules about how to cite a written work and instruct high school teachers on how they should teach their students are often heavily involved at surprisingly high levels of technology. You've heard of the Semantic Web no?

In other news by avik42 · 2005-12-07 08:24 · Score: 1

Web browsers sucks at being word processor.

"new Microsoft technology" ... riiiiiight by Anonymous Coward · 2005-12-07 08:31 · Score: 0

From the post: "this new Microsoft technology". Is the poster smoking crack? Microsoft provided the XMLHTTP object years ago, but they and no one else significantly took advantage of it until Google. Microsoft is completely behind the gun on this one.

What does Jakob Nielsen know anyways by Zane+Edwards · 2005-12-07 08:40 · Score: 0

Puleez...From the look of his boring non-flashy website, he doen't know the least thing about designing websites. I could design something with Frames and Flash AND ajax circling his boring nonsensical pages. What are they designed for Netscrape 2.0??????

--
If you mod me down, may you go down in history as completely clueless

Re:What does Jakob Nielsen know anyways by hebis+flobbis · 2005-12-07 12:42 · Score: 1

What? Yeah, you could design a really cool and neat website with frames and flash and all. That's obviously not the point of his site. I am so sick and tired of hearing people equate a well designed website with lots of stock photos, flash, and other pointless chrome. Maybe you work for cnn.com, I dunno. Is that your idea of a good website? His target audience is professional web developers, and as one of them, I appreciate the fact that at least it's not full of lots of fluff and impertinent crap. It's all about the content.

I am not a Nielsen acolyte or anything, but give me a break. Don't you think he could have his site full of useless crap if he wanted to? Marquee tags anyone? How 'bout blink tags? Maybe frames! Cool! The text, like, moves around! How DO they do that??!

Thanks by Anonymous Coward · 2005-12-07 08:40 · Score: 0

I'll have to look for that pref in Opera when I get home. Then again, I have not yet installed the latest version, so that may be why I missed it.

But is there... by Yvanhoe · 2005-12-07 08:41 · Score: 1

... an internet browser written in Ajax ?

--
The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.

Flash-SVG by Anonymous Coward · 2005-12-07 08:42 · Score: 0

"It's one thing to be able to rip text out of a raw SWF file, but its another thing entirely to for Google to actually understand what the point of the flash file is, understand any embedded heirarchy and follow links within the file. I expect Google will never do this unless Macromedia specifically make it easier for them to do so."'

And hence we have SVG. MS and Macromedia were on the board BTW.

Some validity but ... by Wilmerr · 2005-12-07 08:44 · Score: 2, Informative

I would contend that the statement :

"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."

Doesn't just apply to AJAX, but also applies to legacy pages constructed using frames - you can often relate to the site content initial state but not the state of the content. So if you exempt that from being a benefit of AJAX then do the other benefits stand on their own ?

Re:Some validity but ... by Wilmerr · 2005-12-07 09:04 · Score: 1

Sorry folks, didn't realize thatt eh article was a spoof on frmaes - duh. RTFA

RubyScript by Anonymous Coward · 2005-12-07 08:49 · Score: 0

As a replacement for Javascript?

Yeah... by XnavxeMiyyep · 2005-12-07 08:56 · Score: 1, Funny

Ajax was never as good as Achilles!

--
I put the 't' in electrical engineering.

I hate your web site by Anonymous Coward · 2005-12-07 09:03 · Score: 1, Funny

...and AFAIK I've never seen it, but I would hate it if I went there.

You've obviously won some awards - Nielson (or is it Tog?) says that if your page wins awards, you're throwing 10% of your readers away.

There is an old and simple design principle that applies to everything from web pages to electric drills: KISS, or Keep It Simple, Stupid". As Scotty said in Star Treck III, "The more complex the plumbing, the easier it is to stop up the drain."

The statement that makes me sure you really, really suck at web development that stuck out like a sore thimb: "Websites are designed for a minimum of 800x600 these days, if not 1024 wide."

Hope no geezers go to your site(s), because many if not most of them have two problems: bad eyesight and old monitors. Mix the two and you'll have a 12 inch monitor set to 640x480 that they have a hard time reading with glasses.

Only total incompetents make a page non-resizeable. Your page should look as good on WebTV as it does in a giant 1024 (or larger) monitor, and vice versa. Screens come in all sizes and resolutions, and if you don't realize this you have a lot of learning in front of you.

"The best use of AJAX, that I see, is with improving user interactivity with a web application."

This is actually a good use. However, how many web applications do you use? I only use one; my registrar's site. It's barely useable (has a horizontal scroll at 800x600, for example). How many do you use?

"The author talks about how 'the page' is the basic idea that was behind the Web. Well, I hate to break it to him, but after 12+ years, things have evolved."

Sure, now we have IM, Napster, streaming audio, etc. BUt the basic usint is still the page. Ever been to Google? Does it list "billions of web applications?" No, it lsts PAGES. Like, for example, the page you are reading right now.

Most web surfing is done in pages to this day and that will likely remain the case for a long, long time.

"The notion of the page has long since been an area of limitation with web applications and usability."

No, it hasn't. In fact, the opposite is true.

"Users don't like having to wait for a full page load to make a small request within an application."

True. But HTML Pages usually serve very quickly, while (eg) ASP database pages take forever to load. And pages written in AJAX (and even CSS) take forever to load.

"I am conscious that search engines can't necessarily index my content... so what!"

If you don't want or need your content indexed, then that's a valid point. However, most folks actually want a few visitors to their sites.

"Old browsers are likely unpatched browsers. With the vulnerabilities and security issues today, compatibility with AJAX is the least of their problems. Upgrade!"

No way most users will. Instead, they will simply stop buying stuff on the web or keeping sensitive stuff on their PC because they know that the black hats are going to exploit them as soon as a hole is found. Most users don't give a rat's ass about security. That is the reality - deal with it. They're not going to "upgrade their browsers" to visit your ineptly coded page when your competetition works fine in any old browser.

Too many times I've seen static content served up with an ASP at teh end of the uRL. I think of statements like yours when I see this, and shake my head in disbelief at how incompetent most web designers are.

Re:I hate your web site by diverman · 2005-12-07 09:59 · Score: 1

Well, I'll reply to the anonymous troll on some points.

800x600 is pretty much the minimum of MOST websites. If you're still using 640x480 to support the 3% of people still using that resolution, then you are in the vast minority of websites. Even /. looks like crap at less than 800x600.

KISS depends on how you look at it. I find interfaces that don't cause a page reload, removing the buttons, links, etc. for a moment only to bring them back in a different relative location (as the page sets itself back to the top on a "new page") as more complex. Using several complete page loads to do simple retrieval of informational components to a web application??? Are saying THAT is KISS? If so, you may want to focus less on the "Stupid" part of that acronym.

So, you again missed the point of my post. AJAX isn't being heavily used on basic content pages. It's wider use is in web applications. I stressed that this is where is benefits, and that I agreed with the author on some of the more key points in respect to abuse of AJAX, particularly on basic "pages" of content.

I can only assume you have little real experience in the world of business applications and websites. If a theoretical 5-10% of the market share is requiring me to hold back on usability factors that help me gain a larger portion of the other 90% of users, screw the 10%!!! They're not worth the overall 20% more I could gain by having features and easy of use that competitors don't have.

So, if you think of my statement when you see static content pages being served up with ASP on the end (not that you'd ever see that on my sites, not being a big MS fan), maybe you should re-read my statement. I specifically advise against misuse/abuse of dynamic content technologies for static content. Although if you think that static "content" should be limited to "static flat files" on a file system, then you're truly ignorant of a bigger picture. Flat files have so many limitations it's ridiculous... I'd rather see that someone has a decent content management system in place that uses ASP with a backend database to store the content (more options on content management in an organization bigger than one person to manage it) than see flat HTML files sitting on some file system, requiring direct access to the production server's file system to maintain.

Which leads me to security...

No way most users will. Instead, they will simply stop buying stuff on the web or keeping sensitive stuff on their PC because they know that the black hats are going to exploit them as soon as a hole is found. Most users don't give a rat's ass about security. That is the reality - deal with it. They're not going to "upgrade their browsers" to visit your ineptly coded page when your competetition works fine in any old browser.
Wow. Do you have ANY clue? You act as though the average web user has a clue about what is and is not stored on their computer. They're NOT going to stop buying on the internet, not in significant portions. Yes, you are right, many don't give a rats ass about security... until they realize their machine is so screwed up from trojans, spyware and other things. But I think more and more people are tired of reinstalling Windows, or having to figure out how to use a spyware program, or how to make sense of them... users are already leaning towards trusting auto-updates, and find it to be worth doing to feel assured that the activities they do anyway will be "more safe".

So, if making my websites inaccessible to people who are using insecure, unpatched browsers is one more irritation for them to push them up wise up and upgrade, good. You can argue that you know what you're talking about with user trends and awareness of security, but may I ask you how many software and application security conferences and discussions you've attended? See... I actually WORK as an application security specialist... I'm quite active in the application security community and we'r
Re:I hate your web site by ArsenneLupin · 2005-12-07 11:20 · Score: 1

... content management system in place that uses ASP with a backend database to store the content ...
I suppose that pun was not intentional, was it? Indeed, a nice shiny back end is usually what you end up finding in your spiffy MS SQL database once your ASP shite is found by a bored slashdotter...
Nothing against content managements systems, but for the sake of our eyes, please use secure technologies such as php or zope. We've seen that picture too many times already, we don't need to see it on your site!
Re:I hate your web site by diverman · 2005-12-07 11:30 · Score: 1

Heh. No, I don't use ASP or MS SQL. Much more of a PHP, *nix, Java, Mysql, Postgresql, Oracle kind of guy.

As for security concerns... trust me... I'm very conscious of them. It's what I do for a living. :) Anyone else going to the Software Security Summit in February? :) Looks like it will be much better than last year's.

One thing no one seems to have pointed out about AJAX (or rather poor implementation of it)... be sure to have the same security checks with the component requests as the main page has! I can't tell you how many stupid apps I've seen that have good security on the site... they implement something in AJAX, and totally forget to have those requests check for valid authentication to fetch data. *sigh* Out of sight, out of mind, I guess. heh.

URL 's of sites that use it? by xluap · 2005-12-07 09:10 · Score: 1

Can someone post some links to AJAX sites?

I would like to see if my browser works with it.

Told you so... by Hosiah · 2005-12-07 09:16 · Score: 1

I *knew* Ajax was crap when it was unknown, and then overnight, there were these cult-members chanting "Ajax!Ajax!Ajax!" all of a sudden. When I tried to find out what everybody was so excited about, it went:

"AJAX good!"
Me: "What makes you say that?"
"I use AJAX!"
"OK, any other endorsements?"
"Sonny Bono use AJAX!"
"And..."
"You use AJAX!"
"But why should I?"
"AJAX good!"

PS It's things like this that keep me from getting too closely involved with Ubuntu. Mind you, zealotry is somebody who was actually *won* to a cause. AJAXmania and other manias of it's ilk aren't zealotry. They are cultism. Cultists were persuaded by peer pressure and/or media hype.

Ajax free by Kortec · 2005-12-07 09:24 · Score: 1

The author seems to want us all to know that his site is ajax free; and being so diserves a Piece of Flare (tm). Well, I'd like the author to know that the w3c says his website is awful:

http://validator.w3.org/check?verbose=1&uri=http%3 A//www.usabilityviews.com/ajaxsucks.html.

So I guess he's just blatently against any standards as well as any interesting advancing technologies.

--
"My heart is in the work." - Andrew Carnegie

Solution for backslash by hemabe · 2005-12-07 09:24 · Score: 2, Interesting

I use Ajax in a few applications and there is no problem with "backslash".

For example: I'm developing a (german) flirt-portal, which makes extensive use of ajax and google maps.

Each interaction and it's result is stored in a cookie. If a user changes the zoomlevel of recenters the map, the new values are stored in a cookie. Next time the user visits the back, the cookie is read and the values are restored. Works peferct.

You may check this out: www.citybeat.de/flirt. Zoom into the map, select something from the menue on the "right side". leave the map and return, you will see you last settings.

Here's another ajax-thing, I'm working on: An Ajax-Chat, it's in early beta, but it's working finde. www.citybeat.de/chat/

Hah! ANOTHER pet peeve... by WebCowboy · 2005-12-07 09:25 · Score: 0

..to add to my list:

And if you want to print from gmail, it shouldn't be a print of the screen, but a specially built printable html page.

NO NO NO NO NOOOOOOO!

I HATE this "printer-friendly-link" thing! There is already a print button on my toolbar and I'd rather not clutter my screen with a redundant icon/link.

Besides, such a practice is soooo pre-CSS last-decade...it belongs in the trashbin with those JPEG-jigsaw, bitmap-and-table layouts of yore. It is becoming more common to use an alternate stylesheet for print media that hides navigational elements, sets more printer-friendly colours and fonts and so on. That way you do not have to launch another window or move to another page, print then close a window or use the (hopefully functional) back button to resume browsing.

Please tell me you aren't one of those web deveopers that puts big flash-animated, zero-content splash pages and back-button-breaking scripting on their websites too...

Where AJAX is useful? A developer's perspective by SukMuhNerD · 2005-12-07 09:26 · Score: 1

Component driven events Model View Observer pattern Partial page rendering ...merge a ven diagram of functional differences between a web model with a standalone app. It's potential lies not in websites but in Richer Internet Applications.

Talk about have your cake and eat it too by pavera · 2005-12-07 09:27 · Score: 1

Ok, so AJAX is all the rave and its this great new mozilla/google/apple technology, and everything is great and wonderful.

Then someone has a complaint about it, and now its MICROSOFT's technology, and it sucks...

I'm not an MS supporter, I don't run MS software anywhere I don't have to, I just found it quite amusing that every article I've ever read here raving about AJAX (which is cool technology) has never explicitly given credit to MS for inventing it. Only this one which is bashing AJAX gives full credit to MS.

I personally don't use AJAX, because to me this thing has submarine patent written all over it. I would be willing to bet that in among MS's thousands of patents there is one for this neat little trick, and in a couple years (or months) MS will suddenly be demanding royalties from every web service that uses their invention..

What a waste of time. by Anonymous Coward · 2005-12-07 09:31 · Score: 0

This article is a non-sense.

Solution for the "Back"-Button-Problem by hemabe · 2005-12-07 09:43 · Score: 1

I use Ajax in a few applications and there is no problem with the "back"-button if you use cookies to save the state.

For example: I'm developing a (german) flirt-portal, which makes extensive use of ajax and google maps.

Each interaction and it's result is stored in a cookie. If a user changes the zoomlevel or recenters the map, the new values are stored in a cookie. Next time the user visits the back, the values of the cookie are read back. Works perfect.

You may check this out: www.citybeat.de/flirt [citybeat.de]. Zoom into the map, select something from the menu, leave the map and return, you will see your last settings.

Nielsen is outdated by melimeli · 2005-12-07 09:54 · Score: 1

could we pleeease stop listening to that outdated dane. It's his fault the web design discourse has been one-dimentional for years. Ie simplicity everything else. It's not that simple!

Re:Nielsen is outdated by melimeli · 2005-12-07 10:09 · Score: 1

oops, spoof. I get it...

Tell that to Microsoft by catmistake · 2005-12-07 10:02 · Score: 1

They're investing millions in it... and they use the stupid word 'Ajax' now.

--
The Admin and the Engineer

Accessibility by ImaLamer · 2005-12-07 10:02 · Score: 1

but how often are you using bookmarks on gmail (a web application)? And if you want to print from gmail, it shouldn't be a print of the screen, but a specially built printable html page

That's great, we have those two figured out. Now what about accessibility? Gmail is popular and is used worldwide (except in Germany where it is called Google Mail), and by what I assume are a few users that need accessibility in web applications. You can't even open an e-mail in Ajax mode. I would assume that a lot of users find it the same.

--
Get your Unix fortune now!

don't make me laugh by cg0def · 2005-12-07 10:08 · Score: 1

Ajax is not an all-cure medecine and it is not supposed to be used as such. Half of the points that the article rises are not valid at all. Say you were building some site that needed an online design system. What possible good is it to book mark a step of the process? Also the back button was put in a browser and it did not just exist there. Anything that was made by man would be broken by man so quit bitching.

All that said Ajax does have some problems but this is to be expected at such a stage of development. Oh yeah and if you don't like it well just don't use it. Simple as that.

All I have to say about Ajax is that change is good and at least they are doing something about a very real problem.

This Isn't Even by Jakob Nielson by francisew · 2005-12-07 10:13 · Score: 1

The article linked to in the top level post is a cleverly crafted imitation of Jakob Nielson's original frames discussion. It is made to look like Jacob Nielson's work, which it isn't.

On his home page, Jakob Nielson specifically states that.

Even the sites that reported about the Nielson 'Alertbox about AJAX' have now realized they were hoodwinked.

It must very much suck for Nielson to have other people imitate him, to the point where it is difficult to distinguish his viewpoint from the imitations. Chris McEvoy, the author of the spoof, goes on to both apologize and gloat over the success of his prank.

"...at the new Microsoft technology..." by meregistered · 2005-12-07 10:30 · Score: 1

LOL

Microsoft technology...
Lets review the acronymn: Asynchronous Javascript And XML
If there are any here who still beleive this is a 'Microsoft technology' I have a great new news site for you to get your geek news:http://www.msn.com/ .
-ME®

Great when used for appropriate situations by Denis+Lemire · 2005-12-07 10:33 · Score: 2, Insightful

The problem with AJAX and many new technology paradigms is the early adopters who implement it "just because."

If you save AJAX for the projects that will actually benefit from it you will benefit from it much more, instead of annoying your end users.

AJAX is for on-line applications, using it everywhere is not a good idea.

Example of poor use:
A site that uses AJAX for navigation across the entire site. In this situation you now can't bookmark a specific article or piece of text, nor do you necessarily (depending on the site) have the ability to bookmark that particular section.

Example of a good use:
I built an on-line calender for scheduling various events within my organization. Before I added AJAX to the code the entire monthly calender view had to be reloaded on when you click an event to zone in on its details. The old way caused the entire months summary to be reloaded, reparsed, etc just so the end user could see the details for one event. Now that it uses AJAX one can click each event and have the details load almost instantly without regenerating the entire month view.

AJAX is the new XML by bearinboots · 2005-12-07 10:48 · Score: 2, Insightful

AJAX is a tool like any other. Like XML before it, all the hype will cause it to be used and abused for all sorts of things for which it is not suitable (remember "We don't need a database, we have XML!"?)

After the hype subsides, AJAX will become just another tool to be used when appropriate and eschewed when not.

havent had any problems with it... by dallask · 2005-12-07 10:50 · Score: 1

We just finished www.sendherflowers.com ... the main page and view cart page use a LOT of ajax functionality... the scroller at the top is all JS

We managed to maintain the history and book mark functionality with a system called Really Simple History which uses # locators in the URL to maintain the state...

We think it worked rather well.

--
The Code Ninja is swift with his tool, precise in his delivery, and deadly accurate in his execution.

AJAX sucks ? by phpCypher · 2005-12-07 10:58 · Score: 0

The girl in Cheech and Chongs up in smoke seemed to like it ? http://www.cduniverse.com/search/xx/music/pid/1099 235/a/Up+In+Smoke+(Sdtk).htm http://mfile3.akamai.com/14122/rm/muze.download.ak amai.com/2890/us/usrm/_!/546/89546_1_07.ram?auth=d aEaddAa9bdcsdvcbaodIdmbadravcadCcU-bdL2F0-Ci-dggbc &aifp=1234&obj=v10212

--
~darkness_falls

why this poster sucks (most of the time) by gru3hunt3r · 2005-12-07 10:59 · Score: 1

Yeah, it's not bookmarkable, it's doesn't work for the kids on the short yellow bus, and it doesn't print well --- hey Wait a Second!!!! Are we talking about Flash or AJAX here?

AJAX is nothing more than a non-plugin required, much lighter and more flexible, non-modal, proper font-rendering replacement for Adobe Flash.

You can expect people to come up with innovative solutions to the majority of the usability concerns addressed in this article. Also aside from the bookmark/back button argument the majority of the gripes the author has here are really with DHTML/CSS not AJAX at all.

AJAX sucks ? by phpCypher · 2005-12-07 11:20 · Score: 0

The girl in Cheech and Chong's "up in smoke" seemed to like it ?
http://www.cduniverse.com/search/xx/music/pid/1099 235/a/Up+In+Smoke+(Sdtk).htm
http://mfile3.akamai.com/14122/rm/muze.download.ak amai.com/2890/us/usrm/_!/546/89546_1_07.ram?auth=d aEaddAa9bdcsdvcbaodIdmbadravcadCcU-bdL2F0-Ci-dggbc &aifp=1234&obj=v10212

--
~darkness_falls

Re:PHP isn't difficult to learn. by diverman · 2005-12-07 11:22 · Score: 1

The issues that were stated about PHP, really apply to ANY language. SQL injection flaws can existing in PHP, Perl, Java, and .NET.

The reason you don't find much about "secure PHP", is that it's not just a PHP issue. You might want to read sites like OWASP (http://www.owasp.org/) and Threats&Countermeasures (http://www.threatsandcountermeasures/). There are plenty of others.

The thing is, it's not as simple to write a "how to" when it comes to security issues. It's a bit more abstract than that, if you try to encompass the whole concept. For example... SQL injection flaws:

Never take anything string of data that came from the user and stick it into the SQL string you are generating, without checking it for a few basic things. Escape ANY special characters that has meaning in SQL (quotes, semi-colons, etc). Quotes are your biggest threat. Quick example:

You are building this string:
"SELECT count(*) from users where username = '$username'";

Now imaging $username came directly from user input, and I typed:
'; delete from users; --

That results in a query like:
SELECT count(*) from users where username = ''; delete from users; --'

Assuming your driver or database doesn't limit single "prepare" or query executes to only one statement, it will run the select, and then delete all users, commenting anything else you would have had after that. Scary, huh?

The best thing is to look for API's that support prepare and execute of a query separately, where you place "?" placeholder in the SQL query string, and then give the data to the execute method. The execute method generally handles all escaping needs to treat it as "data". Clear separation of command and data. Of course, that's not 100%, as you could have a "LIKE" comparisson in your WHERE clause. A "%" in the data is still treated as a wildcard, so you would still have to be sure to escape that in variables you are using with where clause values.

So, there's your simple brief tutorial... but the whole way of thinking is different if you consider all the vulnerabilities. Read OWASP's top 10 list, and think about you are providing information and using information to/from the user. These are your attack surfaces.

Cheers,
Your friendly neighborhood Application Security Specialist

this is such a great headline. by BlackShirt · 2005-12-07 11:55 · Score: 1

you could say the same thing about most of the (program langauges), (politicians), (food)

Misleading-Not paying attention. by Anonymous Coward · 2005-12-07 12:06 · Score: 0

"I'm too smart to work in IT. Thanks for your troll though."

I didn't say you did, Garcia (6573). Thanks for not paying attention though.

AJAX Successes by Heembo · 2005-12-07 12:22 · Score: 1

I have had a great deal of success with Ajax in the last few months where the same code base works on IE XP, FireFox XP, and Safari - my three big targets. I'm using AJFORM and Googles XPATH library for XML parsing. Viva Open Source! Limitations be damned, I'm making my clients *very* happy.

--
Horns are really just a broken halo.

Oh, yeah, unbiased here... by cnerd2025 · 2005-12-07 12:23 · Score: 1

Yep, this is exactly what I call fair. Ajax is actually a very good idea. Maybe I'm tne only one that gets this, but having a local machine run code rather than have a server stream code to the client seems like a perfectly logical proposition for me. Bookmarkable? That's the whole point. You can't bookmark a rich user experience. What you can bookmark is the URL. A (well-designed) AJAX page will automatically pick up from where you left off. That has to do with sessions, not bookmarking. Back button? Ajax handles the back button better than frames, and actually an ingenious sliver of code in gmail completely fixes the broken back button (GMAIL gets and sends data from a 0 x 0 iframe). The fact that a lot of ajax sucks is inherent in the fact that it's relatively young (really, people, the technology has been here, but using javascript and xml as the primary modes of design rather than strict html is new). In fact, the web sucks most of the time. That's right, I said it. How many sites can you count that are incompatible with other browsers or have utterly irrelevant and useless features (such as mouse tails)? Really, who cares if someone can build the 1001st "yo momma" joke generator. Ajax is more about semantics than it is about actual coding. Instead of using (X)HTML as the presentation language and augmenting it with javascript, javascript is the language employing XHTML for presentation. It deals more with the fact that there are, indeed, a limited number of HTML tags, but Javascript is turing-complete. This is really ridiculous. In its infancy, most of the web pages sucked, most javascript sucked, most serverside scripting sucked, etc. The technology matures; change is inevitable.

PeopleSoft by Anonymous Coward · 2005-12-07 12:48 · Score: 0

If this is such a newsflash to you guys, I guess used never had to register for classes with PeopleSoft...it has all the same "features."

Time and Place by Anonymous Coward · 2005-12-07 13:01 · Score: 0

Just like any "technology", there is a time and place to use it, as well as times and places not to.

Personally, I have no use for AJAX on the frontend of things... but I find it extremely useful, handy, and efficient for admin areas.

This new, er, Microsoft technology? by BlackMagi · 2005-12-07 13:36 · Score: 1

Since when has AJAX been a Microsoft thing? It's simply not. You can have AJAX on any number of environments.

--
http://melbournephilosophy.com/

These Articles are foolish by JimBrownie · 2005-12-07 14:37 · Score: 2, Insightful

As a developer i see myself like any other worker, and I use the tool that works. Depending on the needs and criteria of a certain project, one may need to be versatile. People who stick onto one technolgy are narrow-minded and tend to write "inefficiet code" trying to force a lannguage to do things it was never intended to do. Like i said, there are reasons for it, preference just should not be one of them.

AJAX Shmajax by Anonymous Coward · 2005-12-07 16:47 · Score: 0

I wish they wouldn't call it by that silly buzzword. It's a freakin javascript object. You don't even have to receive XML. I hate silly buzzwords. They mystify things that shouldn't be shrouded in mystical techno hippie language.

Active Desktop by DynamiteNeon · 2005-12-07 17:30 · Score: 1

So, I realize this might not be the best place to mention this, but I recently discovered that active desktop is actually a bit more interesting than I used to think if you start thinking of the fact that you could be using AJAX to create a more interactive desktop on windows. A person had showed me how he messed with some javascript that made the desktop have snow, and it got me thinking of the possibilities.

I only spent a little bit of time on it, but I already created some animated menus that link to applications on my machine and added a calendar and better clock. There are limitations, such as you're forced to use IE as the rendering engine, but the possibilities really are interesting when you consider you don't have as much of a security concern on your own desktop and you could start playing with activex controls a bit more.

Just a thought.

Proof that AJAX sucks by tehgimp · 2005-12-07 20:15 · Score: 1

- I made a site using AJAX- http://www.slackometer.com/
- It sucks.

QED

Watch where you say that by Captain_Chaos · 2005-12-07 22:43 · Score: 1

You wouldn't want to say "Ajax sucks most of the time" too loudly in Amsterdam. You're likely to get your ass kicked... :-)

Microsoft Bashing by cmay · 2005-12-08 02:51 · Score: 1

How come when the article on slashdot is about "Ajax sucking" it's a Microsoft thing, and yet when the articles talk about how cool Ajax is, its a Google thing (GMail and Google Suggest come to mind)?

The Exchange WebMail client is nothing short of amazing. I don't really care if some stuff doesn't work in older or even in non-IE browsers. For me and the company I work for, it is fricking amazing and it couldn't do what it does without loads of Ajax.

510 comments