For many applications, the overhead associated with generating and executing the JavaScript to perform the requests to fill in the missing parts of the page can often exceed that of just sending the complete page in the first place. Generating? Why would you generate the JavaScript in Ajax? The JavaScript makes a request to the server, the server sends back XML, the JavaScript parses the XML and renders it. How could that possibly take any longer than the browser making a request to the server, the server sending back HTML, and the browser rendering it?
When we sit down and run the numbers, AJAX just isn't feasible. The savings you claim either do not exist, or are actually negative (ie. the AJAX solution uses more bandwidth, client and server CPU time, etc.)! Those problems couldn't possibly be caused by Ajax, and suggest a fairly high level of incompetence of whoever wrote the new Ajax solution (not unlikely, as another poster mentions).
And that's ignoring all of the other problems, such as the inability to bookmark pages, non-standard textfield behavior, an inability to use multiple browser tabs, and so forth. Traditional web applications suffer from an inability to bookmark pages as well - try submitting a method="post" form and bookmarking the resulting page. I've already told you that non-standard textfield behavior could not possibly be caused by Ajax (which is nothing but a JavaScript library that lets a Web page communicate with a server), and is actually caused by bad JavaScript programming. An inability to use multiple browser tabs also could not possibly be caused by Ajax, and is actually caused by certain methods of storing session information - many non-Ajax applications suffer from the same flaw.
It's not an ad hominem attack to point out that a particular individual does not have the background and experience to be discussing a particular topic. [...] The fact is that the kid is inexperienced in this area, and the technology he advocates does not perform as he thinks it does. It's not an ad hominem attack to point out his inexperience and incorrectness, as they are both 100% factual and correct. I am, in fact, quite experienced in this area. Ajax is a fairly new technology, and because of that, age doesn't play that big of a role in experience with it.
And I have yet to hear a single person give me an example of how I am incorrect. I've heard plenty of people say "Oh, I know you're wrong... but I'm not going to tell you why." Sometimes, they go further, and say, "I've had a few bad experiences with a few Ajax apps, which clearly means that all Ajax apps are bad, never mind all the ones that aren't such as Google Maps or the fact that Ajax can't possibly cause any of the problems I describe unless it's used incorrectly. I'm EXPERIENCED, I can't possibly use it incorrectly!"
So, please. Drop the elitist attitude and tell me exactly why Ajax is bad.
The Post-and-Redirect design pattern (or the use of unique once-only form ids) solves this problem in almost all cases. Only badly written web apps still suffer from it.
The rest of your points are good, though. I was giving an example. The "form id" solution still gives the annoying "Content has Expired" message in IE and the "Are you sure you want to resend form information" dialog in Firefox. The "Post-and-Redirect" method breaks the back button even worse, unless you try to press Back several times really quickly or use the Back menu, in which case it suffers from the same problem as I mentioned earlier. Although both solve the problem I mentioned, Ajax is still better for it (as long as you have a fallback for public sites).
AJAX advocates tell us that the main benefit of AJAX is that we don't have to generate a complete page for every request from a user. We are encouraged to generate the page dynamically on the client-side in small chunks, via AJAX requests. And when we do so, we run into severe performance problems.
So then you AJAX advocates turn around and tell us to reduce the number of AJAX requests we perform. To get decent performance, we end up having to generate a complete page for each client request. Thus we end up with a situation where we don't get any of the benefits of AJAX, as we're still generating complete pages for each client request, but we have to deal with its added complexity.
You're missing the point. You generate a complete page, minus the part that doesn't change between pages. (Which, for most actions, is the majority of the page).
In theory it is "easier" on the server. But what we actually find is that the overhead of the requests can be greater. This happens when too many AJAX requests are made to generate a page. Soon the overhead of the request made by each individual AJAX request, plus the XML processing on the server-side, end up consuming more CPU and RAM than would be consumed had a typical CGI, PHP, JSP, etc., script been run.
Well, the obvious solution is not to make so many Ajax requests to generate a page. You only need one.
It has numerous technological flaws, and it seems that developers, even highly talented ones, are unable to develop quality software using it.
Name one technological flaw, then. And I doubt "highly talented developers" would design a system that uses multiple Ajax requests to generate a page and then blame the resultant server slowdown on Ajax.
We actually stuck with only commercial vendors for the AJAX apps we tried. We even worked with one of them to try to improve the performance of their Webmail product, with no avail.
You worked with one of them to improve the server-side performance of their Webmail product, which has absolutely nothing to do with Ajax, to no avail.
And, earlier, you said:
Sure. And the very "design" of AJAX encourages such poor development to occur. The fact that virtually every AJAX application is problematic shows that the problem is not with the developers, but with the technologies those developers are trying to use.
If said commercial vendor had problems with the server-side performance, a technology that has nothing to do with Ajax, I think the problem is with the developers.
I didn't say he was stupid. I suggested he was inexperienced.
And I replied that I am not.
When faced with empirical evidence that such technologies as AJAX just don't cut it, the best thing to do is to admit that they can't be used.
You gave anecdotal evidence. I supplied plenty of counterexamples: GMail and Google Maps.
Sure. And the very "design" of AJAX encourages such poor development to occur. The fact that virtually every AJAX application is problematic shows that the problem is not with the developers, but with the technologies those developers are trying to use.
Have you missed the portion of my post where I explained exactly what Ajax was? It's just a JavaScript library that allows the page to communicate with the server without clicking a link and bringing up a new page. How does that encourage poor development?
And I have to dispute your claim that "virtually every Ajax application is problematic". I've seen plenty of places where Ajax is used effectively - Google Maps and GMail, to name two. Maybe in your experience, they are, but, as they say, the plural of "anecdote" is not "data".
Now I understand why you don't comprehend anything about how ineffective and pathetic real development is when using AJAX. Come back when you've had to deploy a real system, jimbo. You know, where it actually has to work. If you brought up an AJAX "solution" at the firm where I work, the rest of us would laugh at your sorry ass for suggesting a technology that fails in so many obvious and integral ways.
Care to give examples of these "obvious and integral ways"? I have deployed real systems, and they have worked, and I haven't come across any of the problems you've mentioned.
Have you ever considered that those could all be badly programmed? I mean, I could write a Java program that took tons of resources, ran really slowly, didn't allow text selection, and more. And I could write an Ajax application that ran far faster than the equivalent non-Ajax one.
As for your specific case of a text field being unhighlightable, I suspect that has to do with the Ajax application using onSelectStart to disable selection within the page (sometimes as really crappy DRM, sometimes because click-and-dragging is needed for some other functionality), and not knowing how to re-enable it for the text field (which is something I, a 16-year-old, know how to do). Problems like the ones you describe are usually caused by vendor incompetence.
Ajax, by itself, can't possibly cause any of the problems you describe. All it is is a system by which Web pages can interact with the server without needing to load a new page. This means:
1. Less bandwidth is used because you don't need to load layout information for each page. Consequently, it's faster than non-Ajax applications.
2. The Back button goes to the last page, as opposed to the last action, which is a good thing for true Web applications, since the Back button usually causes tons of problems (Ever seen "DON'T PRESS THE BACK BUTTON OR YOU COULD ACCIDENTALLY PAY FOR THIS PRODUCT TWICE"?).
3. If coded to do so, the server can relegate translating raw data into a human-readable HTML layout to the client. This is usually done because the client usually has many processor cycles to spare, while the server doesn't. (This also doesn't take much processing power, and should be unnoticeable to the client)
4. You have more control over page transitions, and you can have things like "Loading..." messages while the data is being fetched from the server (as opposed to traditionally, where the only indication is "Loading..." in the browser status bar and the top right loading animation, and then, when it loads, the page goes white and the new layout is loaded.)
Those are the only differences. So, in reality, Ajax is superior in every way for Web applications, and the problems you describe are caused by bad programming practices, and would've happened whether or not they were written in Ajax.
Re:But universal close tag not flexible enough...
on
The NSFW HTML Attribute
·
· Score: 4, Informative
There are instances where elements can be nested not in the order they are opened. For example, having an underlined and bolded sequence intersect would be such a case:
<i>this <b>is a</i> test sequence</b>
It seems silly, but it is valid html that doesn't perfectly nest as would be required for a universal close tag. That's not valid HTML at all, and would fail the W3C's validator. The correct way to do something like that would be:
The problem with that strategy is that sooner or later, companies will realize that particular feature of GMail, remove everything between the + and the @, and bam! It doesn't work any more.
I own plenty of things I didn't invent. They are my belongings, still.However, you don't own any intellectual property you didn't create yourself. They are two entirely different concepts.
Re:Standards! Standards! Where are the standards!
on
The Web Is 16 Today
·
· Score: 3, Informative
I just recently bought a laptop for my wife and I had to go through hell getting all the pre-installed crap out of it. It had adware and spyware preloaded by the factory. [...] I would have much rather paid less for the laptop, added windows onto the price and arrived in mostly the same place.
See, the adware and spyware companies PAY to get their stuff on the computer, so, in the end, it'd probably be cheaper (or at least not significantly more expensive) to buy a laptop with Windows and all that stuff preloaded than to buy a laptop with nothing loaded on it.
So the question becomes, would you rather have paid MORE for the laptop, added Windows onto the price, and arrived in mostly the same place?
Well, I can't think of any way to test whether an iPod works with a PC than to use PC QA equipment.
According to TFA, "Vice president of iPod product marketing at Apple, Greg Joswiak, had no specific response to the comments; however, he did acknowledge that the iPods became infected by a Windows system used to test compatibility."
Well, #2 isn't going to be fixed until Firefox 3.0, as the developers mentioned a long time ago. And as for #1, I don't remember ever having that problem.
Therapist: "Okay, now it is time to address frustrations. Mac, express a frustration about PC. " Mac: "I'm really upset that you loaded a virus on our flagship product when we connected it to you for QA testing." Therapist: "I see. PC, express a frustration about Mac." PC: "Mac, Why did you use me for QA testing in the first place?"
Therapist: "PC, maybe you'd better come in twice a week to deal with your anger-displacement issues."
Well, middle click or ctrl+w is what most people use to close tabs. I prefer the close tab button on the side, as it's harder to accidentally click, and stays in one place. Of course, if you truly want close tab buttons on each tab, just install Firefox 2, which does have them.
If Firefox is getting slower and crashing more often, you probably have some strange extensions installed. Uninstall them. There's nothing IE7 has that Firefox (Well, Firefox 2 at least) doesn't come with.
I don't believe they are packed to the brim; I meant that one could not fit a flash drive in the space they did have. Other posts suggest otherwise, so perhaps all the flash drives I've seen were larger than average.
Well, when I said "MP3 player", I mean it in its colloquial usage: a portable music player (at least that's what we call them here in China). I didn't mean to imply that it would be able to play MP3s without first converting them into a usable format.
Well, the last time we had a Slashdot article on TI calculators, we mentioned that we could probably get Linux working if we had a bit more memory to work with...
Slashdot Mirror
[...]
The fact is that the kid is inexperienced in this area, and the technology he advocates does not perform as he thinks it does. It's not an ad hominem attack to point out his inexperience and incorrectness, as they are both 100% factual and correct. I am, in fact, quite experienced in this area. Ajax is a fairly new technology, and because of that, age doesn't play that big of a role in experience with it.
And I have yet to hear a single person give me an example of how I am incorrect. I've heard plenty of people say "Oh, I know you're wrong... but I'm not going to tell you why." Sometimes, they go further, and say, "I've had a few bad experiences with a few Ajax apps, which clearly means that all Ajax apps are bad, never mind all the ones that aren't such as Google Maps or the fact that Ajax can't possibly cause any of the problems I describe unless it's used incorrectly. I'm EXPERIENCED, I can't possibly use it incorrectly!"
So, please. Drop the elitist attitude and tell me exactly why Ajax is bad.
The rest of your points are good, though. I was giving an example. The "form id" solution still gives the annoying "Content has Expired" message in IE and the "Are you sure you want to resend form information" dialog in Firefox. The "Post-and-Redirect" method breaks the back button even worse, unless you try to press Back several times really quickly or use the Back menu, in which case it suffers from the same problem as I mentioned earlier. Although both solve the problem I mentioned, Ajax is still better for it (as long as you have a fallback for public sites).
Name one technological flaw, then. And I doubt "highly talented developers" would design a system that uses multiple Ajax requests to generate a page and then blame the resultant server slowdown on Ajax.
You worked with one of them to improve the server-side performance of their Webmail product, which has absolutely nothing to do with Ajax, to no avail.
And, earlier, you said:
If said commercial vendor had problems with the server-side performance, a technology that has nothing to do with Ajax, I think the problem is with the developers.
And I replied that I am not.
You gave anecdotal evidence. I supplied plenty of counterexamples: GMail and Google Maps.
Have you missed the portion of my post where I explained exactly what Ajax was? It's just a JavaScript library that allows the page to communicate with the server without clicking a link and bringing up a new page. How does that encourage poor development?
And I have to dispute your claim that "virtually every Ajax application is problematic". I've seen plenty of places where Ajax is used effectively - Google Maps and GMail, to name two. Maybe in your experience, they are, but, as they say, the plural of "anecdote" is not "data".
Care to give examples of these "obvious and integral ways"? I have deployed real systems, and they have worked, and I haven't come across any of the problems you've mentioned.
Have you ever considered that those could all be badly programmed? I mean, I could write a Java program that took tons of resources, ran really slowly, didn't allow text selection, and more. And I could write an Ajax application that ran far faster than the equivalent non-Ajax one.
As for your specific case of a text field being unhighlightable, I suspect that has to do with the Ajax application using onSelectStart to disable selection within the page (sometimes as really crappy DRM, sometimes because click-and-dragging is needed for some other functionality), and not knowing how to re-enable it for the text field (which is something I, a 16-year-old, know how to do). Problems like the ones you describe are usually caused by vendor incompetence.
Ajax, by itself, can't possibly cause any of the problems you describe. All it is is a system by which Web pages can interact with the server without needing to load a new page. This means:
1. Less bandwidth is used because you don't need to load layout information for each page. Consequently, it's faster than non-Ajax applications.
2. The Back button goes to the last page, as opposed to the last action, which is a good thing for true Web applications, since the Back button usually causes tons of problems (Ever seen "DON'T PRESS THE BACK BUTTON OR YOU COULD ACCIDENTALLY PAY FOR THIS PRODUCT TWICE"?).
3. If coded to do so, the server can relegate translating raw data into a human-readable HTML layout to the client. This is usually done because the client usually has many processor cycles to spare, while the server doesn't. (This also doesn't take much processing power, and should be unnoticeable to the client)
4. You have more control over page transitions, and you can have things like "Loading..." messages while the data is being fetched from the server (as opposed to traditionally, where the only indication is "Loading..." in the browser status bar and the top right loading animation, and then, when it loads, the page goes white and the new layout is loaded.)
Those are the only differences. So, in reality, Ajax is superior in every way for Web applications, and the problems you describe are caused by bad programming practices, and would've happened whether or not they were written in Ajax.
<i>this <b>is a</i> test sequence</b>
It seems silly, but it is valid html that doesn't perfectly nest as would be required for a universal close tag. That's not valid HTML at all, and would fail the W3C's validator. The correct way to do something like that would be:
The problem with that strategy is that sooner or later, companies will realize that particular feature of GMail, remove everything between the + and the @, and bam! It doesn't work any more.
I own plenty of things I didn't invent. They are my belongings, still.However, you don't own any intellectual property you didn't create yourself. They are two entirely different concepts.
Oh, c'mon, it's an HTML document, not an XHTML document. Let's see how it does in the latest version of HTML... Oh, look, it validates.
See, the adware and spyware companies PAY to get their stuff on the computer, so, in the end, it'd probably be cheaper (or at least not significantly more expensive) to buy a laptop with Windows and all that stuff preloaded than to buy a laptop with nothing loaded on it.
So the question becomes, would you rather have paid MORE for the laptop, added Windows onto the price, and arrived in mostly the same place?
I would've gone with &@&, personally.
Every photograph is, by definition, a photograph of light waves ("photo"="light"), which, by definition, go at 100% the speed of light.
Well, I can't think of any way to test whether an iPod works with a PC than to use PC QA equipment.
According to TFA, "Vice president of iPod product marketing at Apple, Greg Joswiak, had no specific response to the comments; however, he did acknowledge that the iPods became infected by a Windows system used to test compatibility."
Well, #2 isn't going to be fixed until Firefox 3.0, as the developers mentioned a long time ago. And as for #1, I don't remember ever having that problem.
I think you mean:
Therapist: "Okay, now it is time to address frustrations. Mac, express a frustration about PC. "
Mac: "I'm really upset that you loaded a virus on our flagship product when we connected it to you for QA testing."
Therapist: "I see. PC, express a frustration about Mac."
PC: "Mac, Why did you use me for QA testing in the first place?"
Therapist: "PC, maybe you'd better come in twice a week to deal with your anger-displacement issues."
Considering Firefox 2 RC2 has already been released and Firefox 2 will be out soon, Tab X is nearly obsolete.
Well, middle click or ctrl+w is what most people use to close tabs. I prefer the close tab button on the side, as it's harder to accidentally click, and stays in one place. Of course, if you truly want close tab buttons on each tab, just install Firefox 2, which does have them.
If Firefox is getting slower and crashing more often, you probably have some strange extensions installed. Uninstall them. There's nothing IE7 has that Firefox (Well, Firefox 2 at least) doesn't come with.
I don't believe they are packed to the brim; I meant that one could not fit a flash drive in the space they did have. Other posts suggest otherwise, so perhaps all the flash drives I've seen were larger than average.
Well, when I said "MP3 player", I mean it in its colloquial usage: a portable music player (at least that's what we call them here in China). I didn't mean to imply that it would be able to play MP3s without first converting them into a usable format.
Or a not so shitty mp3 player, for that matter.
Well, the last time we had a Slashdot article on TI calculators, we mentioned that we could probably get Linux working if we had a bit more memory to work with...