Talk:Ajax (programming)/Archive 1

Patent threathens Ajax?

I just learned today that there is a US patent granted today that (might?) threaten Ajax:

See: also: [http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=7,000,180.WKU.&OS=PN/7,000,180&RS=PN/7,000,180 United States Patent 7,000,180 Balthaser February 14, 2006

In short:

"The patent--issued on Valentine's Day--covers all rich-media technology implementations, including Flash, Flex, Java, Ajax, and XAML, when the rich-media application is accessed on any device over the Internet, including desktops, mobile devices, set-top boxes, and video game consoles."

"It's kind of unbelievable that (the patent) has such a wide ranging use because it covers so many technologies," says Bola Rotibi, a senior analyst at Ovum, an IT advisory firm in London. If the patent is enforced broadly, she says, "anybody who does anything with rich applications will have to pay royalties to the company."

Is latency a pro or con?

I'm confused here. In "Pros and cons", it is said that the main advantage is the speed at which an AJAX application runs and responds to user interaction; due to the client-side scripting taking place which reduces the amount of per-interaction network traffic. Later on in "Criticism", "critics focus on the technical issues AJAX raises, beginning with network latency" (with this link to someone's blog that goes on about how AJAX is no good because of latency). Wha...art??? -- Jin 23:06, 19 August 2005 (UTC)

That post talks about usability problems with Ajax. I have updated the critisicm section. --Sleepyhead 13:20, 20 August 2005 (UTC)

In terms of latency itself, it's a con -- as in, the fact that things that used to be instant are now dependent on the speed of the network might be confusing to users. (The advantage that's discussed in the article isn't related to latency per se, but rather, to the slowness of a browser needing to render an entire page when updating a small section of the page would do just fine.) The latency issue DID highlight a confusing part of this article, though, namely that the distinction between what is a "con" (in the pro/con sense) and what is a "criticism" is a little muddy. Thus, I combined the two sections into "Pros, cons, and criticism", and then clarified the latency issue a bit. Jason 16:38, 21 August 2005 (UTC)

Even now I think the criticism paragraph on latency is a bit on the negative side. I've been doing some research, and it seems that network latency is just something you need to consider carefully during AJAX development. If make a proper interaction and technical design, web applications will be more responsive. If you make mistakes, usability and responsiveness will suffer. Is it OK if I try a small rewrite of the latency paragraph? Jep 18:35, 4 September 2005 (UTC)

Have at it! (That being said, there's not a lot in the paragraph to lend a ton of credence to the argument, but rather, it exists just to give a nod to the argument.) Jason t [[Special:Contributions/Delfuego|c

Jason, could you please state some examples of "things that used to be instant are now dependent on the speed of the network"? --Kirils 14:48, 27 February 2006 (UTC).

I'm not Jason, but here you go.

There are two forms of latency. The first latency is the request to response latency when you perform a post/get operation (page load). The second latency is when you use a control on the page (control latency).

AJAX, overall, has more latency -- there is more overhead, because you have more requests and each request carries the overhead. However, AJAX, typically, has lower perceived latency -- and the perceived latency is what actually matters.

If you have two controls side by side, and the value of the second control is dependent on the first control, a non-AJAX DHTML page will update the value of the second control immediately. It will have a high page load latency, but a low latency while you are working with the page. An AJAX DHTML page will have to issue a web request when you change the first control in order to populate the second control, and so the second control will have a higher perceived latency than the non-AJAX version.

The principal of "user distraction" states that the perceived latency of a change in an application's state is driven by the proximity of the parent field (the field that the user changed) and the child field (the field that the program is changing), as much as by the actual latency. If you have a process that takes 20 seconds, but you have 20 fields the user has to update while it is going on, the user is unlikely to notice the pause.

If you look at Google search results, for example -- if you used AJAX on Goggle search results for the various result pages, the user experience would be improved. The user just keeps reloading the same page over and over again, with different results. If you can spool the results in the background, while the user is scrolling, the user perceives no latency when they go to the 150th search result by scrolling through the list in order, because you've already retrieved that data in the background.

Search Engine Accessibility

The entire Search Engine Accessibility section seems to be an ad for Backbase, something I realized after I removed the spammy Backbase link that ended the section. I'm deleting the entire section for now, as the entire rest of the Ajax article makes the point the section is making, and doesn't do so as a pretense for laying the foundation of a "problem" that's solved by the good folks at Backbase. Jason t c 00:58, August 30, 2005 (UTC)

Jason, I think Search Engine Accessibility is a very relevant topic for AJAX applications. I have added the link to provide more indepth information on the topic (the article is not a plug, but a contribution to a generic AJAX problem). If you know otehr articles about this topic as well, please include them. Let's be open, and cooperative instead of just deleting contributions. If you like you can contact me at info at backbase dot com. August 31, Jouk.

I'm happy to be open and cooperative, but Wikipedia isn't a manual, it's an encyclopedia. In other words, saying that Ajax provides challenges for search engine accessibility is appropriate, but providing detailed information about how to overcome the challenge is better left for a computer manual (perhaps the Wikibooks contribution that's linked at the bottom of the entry). Jason t c 12:53, August 31, 2005 (UTC)

OK, I just read over the addition about search engine accessibility, and it really seems like it's trying to be a manual. It would be just as easy to flesh out the pros/cons section so that the line that talks about bookmarking problems extends this to be a search-engine problem as well (since they're the same problem); it doesn't feel like WP's the place to go into this much detail on proposed solutions, though. Jason t c 13:51, August 31, 2005 (UTC)

The "Search Engine / Deeplinking" section makes absolutely no sense in the context of the rest of this article. It is not a general piece of relevant information about Ajax. At best, it's a tip for Ajax developers (which doesn't belong in an encyclopedia article); at worst, it's a self-serving advertisement from an unscrupulous company, which surely qualifies as graffiti. This section should most definitely be deleted (though I'm not doing so at this time). --IQpierce, 16:52 (Central Standard Time), November 3, 2005

I agree completely that this section should go. I read this article for the first time today, and it stands out as so obviously inappropriate that I went straight to the discussion page to determine why it's even there. It's been over a month since the two comments above this one were made, with no show of support in the meantime. How about we delete it in 24 hours from now? PaulHoadley 01:48, 9 December 2005 (UTC)

It's been aproximately 24 hours, and no one has voiced support. I'm deleting it now. PaulHoadley 01:33, 10 December 2005 (UTC)

AJAX vs. Ajax

Noting the global change to the former, I think the general concensus from both the archived discussion here and useage elsewhere is that it should be the latter. Ajax, not AJAX.

• Correct; the archived discussion is here, and the change to Mr. Garrett's original spelling/capitalization of "Ajax" was supported without dissent. I've changed the article back to reflect this. Jason t c 19:18, September 6, 2005 (UTC) a

xForms & Ajax

As xForms, an XML derivative of sorts, and Ajax "connect" it would seem useful to acknowledge that fact on the Ajax page. I am not competent to do that, but others who agree might want to undertake it. Be my guest. frankatca Nov. 18, 2005, 2:40 EST.

Example applications

When I look at the example links in the article, what I'm wanting to see are Ajax apps in action. The links were all mixed together with lots of pay-to-use, required sign-in sites at the top. I've rearranged them according to the following priorities:

• 1st: Free, no sign-in.
• 2nd: Free, sign-in required.
• 3rd: Pay, but no sign-in for live demo.
• 4th: Pay, sign-in required.

- Gamol

The "www.digg.com" link in the examples section: exactly how is this site showcasing Ajax? At a glance, it doesn't look like it's using any Ajax techniques at all. If it is, we should probably mention what it's doing in the link description. -Gamol

Good idea. Digg's using AJAX in its user moderation system. I'll edit the link description. -Anderiv

To see that in use, you have to be logged in. I moved the link to the "free but sign-up required" section. -Gamol

Seems like sockpuppets to me. No evidence of Ajax. Clearly linkspam. --Sleepyhead 11:08, 24 September 2005 (UTC)

It _is_ using ajax. Personally, I don't care if the digg link stays on this page or not, but please, check the facts before assuming anything. Check the javascript sources of the website if you're still skeptical. Anderiv 04:33, 25 September 2005 (UTC)

I think singling out Digg over the handful of other more-blatantly-spammy links is a bit unfair. But I think Sleepyhead has an important point. The reason for the Free to use and Sign-up required sections was to filter and contain the linkspam. Personally, I'd really like the links to simply show off Ajax techniques discussed in the article without any kind of signin. But this article was flagged as a "hot-spot for user in-fighting" so I've been reluctant to boldly prune the spammy links (and I'm thinking of others—not Digg). -Gamol

• I have created an additional article called List of websites using Ajax. I have moved all the examples in this article there. The list was getting too long and attracted linkspam. --Sleepyhead 08:09, 26 September 2005 (UTC)

• Thank God for that "cleanup-spam" notice! This was out of control. The Adaptive Path article that popularised the term Ajax was only published in early 2005 and already a Google search for "Ajax" returns 26 million results. The buzz around this really helped pack the example section full of crap. There were some links to nice implementations that aren't there any more but the change gets a big thumbs up from me—a clear improvement. - Gamol 07:13, 24 November 2005 (UTC)

Well, the word Ajax has more meanings than used this article. For example Ajax is a football(soccer)-club in the Netherlands and a household cleaner. So no wonder Ajax brings up a lot of results. --Sleepyhead 07:22, 24 November 2005 (UTC)

I was waiting for a comment like that! Right after I saved the page, it occurred to me that I didn't compare against Google's previous "Ajax" results. A search for "Ajax programming" returns a comparatively modest 27,400 results. I still stand by my "full of crap" comment though. - Gamol 08:44, 24 November 2005 (UTC)

• I was looking for some examples of websites using Ajax and couldn't find anything. Where are them? acidskin 16:10, 6 February 2006 (GMT)

• I came to read the article and added a link last night. After reviewing the rules this morning, I realize that the link should be considered by the community. I linked to http://wordlwideworlds.com in the first paragraph of the section on History of Ajax. I referenced a site called Valley of the Nile which was built in 1997 as an example of a very early implementation of Ajax compatable with Netscape 4.0 and completed prior to the devlopment Microsoft Remote Scripting. I added it primarily to verify that Ajax techniques preceded Microsoft Remote Scripting and that they are well-tested and stable. jlbeezer 18:07, 4 March 2006 (GMT)

• The addition mentioned in the previous entry was removed with the comment "unable to verify. probably spamlink". It's unclear which part of the addition was considered unverifiable. You can view source to see that Valley of the Nile works with Netscape 4.0 and the layer specification (http://worldwideworlds.com/main/mainframe.html). The site was built in 1997 for Netscape 4 and updated in 1998 to work with both 4.0 browsers available at the time. The earliest documentation was by Project Cool in August of 1999 (http://archive.devx.com/projectcool/sightings/auto_prev.asp?imonth=8&iyear=1999). This site is important to the history of Ajax because it verifies that Ajax techniques were in use, stable, and practical for the development of web applications much earlier than commonly stated. I will replace the line pending a more detailed counter-argument or a better suggestion about how to inlcude the information. jlbeezer 02:07, 6 March 2006 (GMT)

Archived Discussions

The following sections of this page have been archived:

• AJAX or Ajax? (page move discussion) Jason 14:41, 18 August 2005 (UTC)
• Proposal to unlock page (unlock vprotection discussion) - Sleepnomore 16:10, August 18, 2005 (UTC)
• Link to specific blog post - not entire blog (discussion on a particular link) - Sleepnomore 16:24, August 18, 2005 (UTC)
• Criticism (discussion of Criticism Section) - Sleepnomore 20:29, August 18, 2005 (UTC)
• Archive Linking to external images without sourcing them (discussion about linking to Garrett's images) - Sleepnomore 20:38, August 18, 2005 (UTC)
• Links (discussion about links) - Sleepnomore 20:42, August 18, 2005 (UTC)
• Link Proposal (discussion about links) - Sleepnomore 17:54, August 20, 2005 (UTC)
• Overload of External Links (discussion about links) - Sleepnomore 17:54, August 20, 2005 (UTC)
• Archive? (request to archive page) - Sleepnomore 17:54, August 20, 2005 (UTC)
• Concrete Example (Discussion of Example) - Sleepnomore 17:54, August 20, 2005 (UTC)
• Removal of Text from Criticism (Requests to remove some text from criticism) - Sleepnomore 17:54, August 20, 2005 (UTC)

Supported Browsers section

Um...

"Mozilla Firefox (and derived browsers)" "Netscape" asdasdasd Mozilla = Netscape = Mozilla Firefox

They may be burying the original Mozilla browser in the dirt, but the corpse is still warm.

• Mozilla 1.7.12 (actual browser that you geeks get Firefox from)
• Netscape 7.x (Netscape labeled Mozilla 1.7.x)
• Mozilla Firefox 1.x (browser only version of Mozilla)

Learn your browsers people!

Opera 7.6+? There was no Opera 7.6, really. There were some betas, but the final release ended up being numbered 8.0. Still, I can't remember whether Ajax was implemented in 8.0 or 7.5.

== What is this "Rangarajan" browser AJAX supports?

I have never heard of this browser, and it seems Google hasn't either.

• -----------for not confusing me with the guy above-----------

Umm...your a tool buddy.

• Netscape 7.X? Well Netscape 7.1 was based on Mozilla Application Suite 1.4.
• Yes, there was an Opera 7.6 browser...really. Do a bit more research buddy...maybe search Google by keywords "Opera Versions" or simply goto: http://www.markschenk.com/opera/history.html and scroll down.
• "Rangarajan" Not sure about a browser type named after him but do a bit of research, maybe search by "Rangarajan browser" and you'll see several articles involving this man and browser technologies.

• -----------done here--------------------------

opera 7.54 DOES NOT support ajax Kirils 19:31, 25 February 2006 (UTC)

Ajax?

These browsers to not support "AJAX", they support some form of XMLHttpRequest, this really needs to be fixed. AJAX is simply a (poor) marketing term for something that has existed for a very long time.

AJAX has become the de-facto term for the technology, as it's far easier to say, type, etc. You're just going to have to learn to deal with that fact. — ceejayoz ^talk 19:08, 19 November 2005 (UTC)...

``

Not a web directory

I've found that a few tech articles seem to have a rapidly-expanding list of links that provide no further information on the topic of the article. This is one of them. Let's keep in mind that this is an encyclopedia, not a web directory. Links to external sites should complement the information in the article.

I know this will upset a few people, but I'm going to delete all external links that don't have primary relevance to the article. If someone wants to revert, that's fine, but I'd like to hear an explanation why those links should be included. Mindmatrix 01:48, 9 November 2005 (UTC)

Aside: I've also nominated List of websites using Ajax for deletion. I realize that people have put effort into organizing those links, but I simply don't think this stuff belongs in WP. At any rate, if you want it kept, just vote on the AfD page. No big deal. Mindmatrix 02:15, 9 November 2005 (UTC)

I seem to be the only one that feels the links are pointless. Oh well. I would like to note, however, that the main portion of the article is just over two pages (in my browser), whereas the links take up five full pages. Most of them are useless, and do nothing to explain AJAX. Mindmatrix 20:34, 16 November 2005 (UTC)

I say delete them. Too many WP pages are full of this sort of crap. Alf Boggis [[User_talk:Alf_Boggis|(talk)]] 10:29, 17 November 2005 (UTC)

Well, we have two people who want the links deleted, and nobody that has requested to keep them. I will delete most of the links within 24 hours, specifically, those that fail to meet Wikipedia's external link guidelines. Mindmatrix 17:15, 18 November 2005 (UTC)

I've deleted the links, since nobody has requested to keep them in the ten days since I made my initial comment. I've kept several links, deleted many of them, and commented out a few. Could someone please parse the commented links, and keep those that are of high relevance to the article. Note that I visited each and every link I deleted to inspect its contents - I didn't blindly delete the list. Mindmatrix 17:58, 19 November 2005 (UTC)

No offense, but your choices in deletion are rather... bizzare. For example, you left script.aculo.us, which isn't AJAX, but took out Prototype, which is AJAX and which script.aculo.us requires. — ceejayoz ^talk 18:55, 19 November 2005 (UTC)

Oops. I had meant to comment out script.aculo.us; as for Prototype, I've had problems loading that site at various times, so I just deleted it. Thanks for checking the other links too. Mindmatrix 23:44, 19 November 2005 (UTC)

Prototype is one of the most widely used libraries, so it should definitely stay regardless of site availability. It's a key component of a number of development frameworks including Ruby on Rails etc. — ceejayoz ^talk 04:01, 23 November 2005 (UTC)

The basis is Wikipedia:External links. If you ask me, having a list for toolkit sites is already walking along "web directory" lane. If Prototype (or any in that list) is indeed notable, then someone would write an article on it. (Macromedia Flash is worse.)

Hmm, I wasn't watching, and WP has deleted List of websites using Ajax. I was curious how long that spam-prone external link farm will stay. I guess I should watch the fantastic List of websites now. -- Perfecto  05:24, 23 November 2005 (UTC)

Being a bit grumpy today and tired of seeing spam links creep in one after the other, I deleted the whole toolkits section. I don't see ajax toolkits (even the mere existence of them) being mentioned in the article at all. I don't deny their existence, but if they are worthy of a seperate external links section, the topic should be discussed in the article proper. Maybe some of those adding the links can contribute to the article on this matter (if it's important to the topic), and not just add links? Shanes 04:37, 1 December 2005 (UTC)

Wikipedia "ajax" search leads to an entry that says "Useless"

searching for "ajax" from the wikipedia front page leads to an entry that just says "Useless". I think just yesterday it lead to a disambiguation page, which was nice: this new entry is odd, seems like a prank (unless ajax really is useless, which doesn't seem to be the case).

Searching for "AJAX" goes to the correct page.

New Criticism: Fragility of Model

I actually think the biggest weakness of Ajax is that the entire developmental model is quite fragile. Consider that:

• The fundamental technology, HTML, was never intended to be used for pixel-precise layout, and has been "forced" to do this via browser hacks and odd CSS enhancements

Ajax doesn't require pixel-precise layout.

No, but most AJAX applications *do* require enough pixel-specific space to support any images or content inside of them. This is contrary to the nature of HTML, which is supposed to be a markup language. Robbyslaughter 03:48, 17 December 2005 (UTC)

That's beside the point. It's not Ajax that has this requirement. You are mistaking correlation with causation. It might or might not be true that "most" Ajax application require pixel-specific layouts (I don't believe you've cited any evidence for this claim), but they don't require these layouts because they use Ajax, and if Ajax wasn't present, they'd still have the same problems. Bogtha 20:33, 3 January 2006 (UTC)

That's a good point. I concur that you don't necessarily need pixel-precise layout to make an Ajax application, nor do you need it to make any web page. What I'm really trying to say is that HTML wasn't designed for this purpose, so using it is a fragile technique. That's dangerous enough on static web pages, which will probably at least render something even if they look ugly, but Ajax applications have the potential not to work at all. So, does this commentary go anywhere in Wikipedia?Robbyslaughter 16:08, 9 January 2006 (UTC)

Why do you claim that the effects of pixel-specific layouts are worse in Ajax-using pages than static pages? I see no basis for thinking so; the bad effects are a layout issue caused by layout code. How the information arrived in the browser in the first place is irrelevant to this. --Bogtha 18:12, 9 January 2006 (UTC)

Indeed. Unfortunately Robby, you are wrong. You are continually conflating generally designer-caused problems with weaknesses in Ajax, when it is simply not the case. "Pixel-perfect" layout for example, would be a problem with CSS, and nothing to do with this article. I know that you mean well, which is great. But please read up on these topics some more, put them into practice, and you will see it is possible to create usable, fast, solid Ajax applications that still work in browsers that don't support XMLHTTP, if you know what you're doing. See for example, this form submission example Break it if you can. ;-) Rufous 21:06, 9 January 2006 (UTC)

To respond to Bogtha: Effects caused by pixel-specific layouts for interactive pages seem generally worse than static pages. Obviously I can't argue that they will always be worse, but it seems that in general, if you futz up your static page design, people will still be able to read the content. But, with an AJAX application, the user may not be able to interact with it at all. That seems worse.

Why are you giving static pages a free pass? There's no reason to assume that if you screw up your page design, it will remain readable for either static pages or pages using Ajax. This is entirely a layout issue. In addition, a Wikipedia article should have established fact, not "it seems that in general..." opinions. --Bogtha 16:19, 23 February 2006 (UTC)

To respond to Rufous. Your example is great. If all AJAX applications worked as well, I would not have brought up this point. I have been going over it in my head and am not really sure if you *could* build Google Suggest as robustly as your example. But, that doesn't necessarily invalidate your counter argument.

I work extensively in web development, and (believe) I am very familar with all the issues. I appreciate the recent comments as constructive. I'm now convinced that the pixel-specific layout issues that some designers unwisely force upon users with poor HTML/CSS are not necessarily a problem with AJAX, since they can be avoided. I rescind this particular critique. Robbyslaughter 22:55, 17 January 2006 (UTC)

• Much of the code for Ajax depends on browser detection, and behaves differently

This is not true. You seem to be looking at a few bad examples and assuming that it's caused by Ajax instead of developer ignorance.

Many AJAX applications use XMLHttpRequest, which is not available in all browsers. Furthermore, it's possible to create a variety of "single page applications" using other JavaScript hacks with, say, IFRAMEs, which loosely fall under this category. These generally require browser detection, making this a fragile model.Robbyslaughter 03:48, 17 December 2005 (UTC)

XMLHttpRequest not being available in all browsers has nothing to do with browser detection. Competent Javascript developers use object detection, not browser detection.

Single-page applications are a specialised subset of Ajax with their own page, and the iframe technique you mention is a workaround for a specific bug in a specific browser - something that is extremely common in non-Ajax websites also. If you feel this is a legitimate complaint of SPAs, then by all means put it on that page, but it's not something general to Ajax. Bogtha 20:33, 3 January 2006 (UTC)

In general, though, Ajax applications are limited to a subset of web browsers and are based upon specific rendering behavior. This is contrasted with say, semantic recommendations like XHTML that ensure all content is rendered assuming the spec is enforced.

When you say "in general", are you talking about a specific quality of Ajax, or merely common mistakes web developers make all the time? I believe the latter may be true, but that is not relevant to this article. I see no reason to believe the former.

I'm talking about both. Ajax applications are very sensitive to the user browser, the configuration of that browser, the size of the window, etc. It's also easy to make mistakes in web development that still "render". The analogue---it doesn't compile---isn't really an issue for more rigorous technology stacks.Robbyslaughter 22:55, 17 January 2006 (UTC)

Static pages are very sensitive to the user browser, the configuration of that browser, the size of the window, etc. Again, you are pointing to a problem in page design in general as if it were unique to Ajax, while ignoring the fact that such problems apply to a page regardless of whether it is static or uses Ajax. --Bogtha 16:19, 23 February 2006 (UTC)

There is no spec for Ajax, it's a pile of browser hacks that depends on very precise, relatively unstable conditions.Robbyslaughter 16:08, 9 January 2006 (UTC)

There is no specification for Ajax because it's a technique. You might as well say "there's no spec for pair programming". The XMLHttpRequest interface has been specified though, first by Microsoft, and also by WHATWG. As for your other criticisms: it requires "precise" code? What doesn't? "Relatively unstable conditions"? Like what? You seem to be using FUD now, vague portents of doom without specifics. --Bogtha 18:12, 9 January 2006 (UTC)

All programming requires precise code. The difference is, leave off a semicolon in your C source and it won't compile, but leave off a tag closure in HTML or use poor CSS that specifies pixel sizes and something still gets to the user. However, they might not be able to use it. Robbyslaughter 22:55, 17 January 2006 (UTC)

No, Ajax and static pages are equivalent here as well. Leave off a closing tag and your entire page could be unreadable in static pages. Use poor CSS that specifies pixels sizes, and "something" gets to the user in the same way "something" gets to the user if you do it with Ajax pages. Whether that "something" screws up the layout is entirely a factor of the layout in question, and not whether the page talks to a server or not. --Bogtha 16:19, 23 February 2006 (UTC)

• Many of the browser paradigms break under AJAX (font resizing, printing, bookmarks, forward-backward navigation, images are optional, hiearchical markup, semantic adaption to non-visual devices)

Simply not true. Ajax has nothing to do with font resizing; that's CSS. Ajax has nothing to do with printing, optional images, hierarchical markup, or semantics. It touches on bookmarks and forward/backward, but there are solutions to that, so it's not true to say that Ajax "breaks" them.

Go to Google Suggest with Firefox. Increase your font size a bit, and you'll see it doesn't work. AJAX apps depend on the underlying technologies (CSS, HTML, etc), whose paradigms are not necessarily preserved with AJAX applications.Robbyslaughter 03:48, 17 December 2005 (UTC)

But that has nothing whatsoever to do with Ajax. If that design was used for a completely non-Ajax website, it would still break. That is somebody making the mistake of specifying a fixed height in CSS, not a problem caused by Ajax. There's nothing about Ajax that requires mistakes like that, and those mistakes happen just as often when Ajax is not used. The effect you are talking about is purely an artifact of the CSS in use. Bogtha 20:33, 3 January 2006 (UTC)

I believe you are incorrect. This is not a CSS issue---instead the box that Google Suggest renders to contain the search entries is not *aware* of the changing font size. I don't think there's any way for an Ajax application to *know* you have resized the font size and render differently. I am not saying that all Ajax applications guess the font size to make rendering decisions, but that there are aspects of the browser paradigm that Ajax applications can't account for. This makes the underlying model fragile, and I think that should be added to the article.Robbyslaughter 16:08, 9 January 2006 (UTC)

It's definitely a CSS issue. The height of each line is specified in pixels, when the user is using a larger font size than Google expected, it doesn't work right. This is extremely basic CSS. Thinking that Ajax needs to know about font resizing is another thing making you sound like a completely mixed up newbie. Ajax doesn't have to know about font resizing. You write the *CSS* to be flexible regarding font sizes, and when you update the page structure with Ajax, you don't have to give a damn about the font size because the layout is done by the CSS. You are *still* taking two completely different ideas and mixing them up. Ajax doesn't have to care about font sizes because Ajax isn't the bit that's doing the layout. --Bogtha 18:12, 9 January 2006 (UTC)

Hmm. What you write is true, yet still, Google Suggest doesn't work as I described above. Try it in Firefox, where there is no problem, and you can see the difference. Now, I'll go back on what I said before---it's certainly related to CSS. But this is an AJAX application, and it has a problem which I don't see as reconcilable due to issues with the underlying technologies, which is the source of my concern. Robbyslaughter 22:55, 17 January 2006 (UTC)

Please read what I wrote again. Just because something is wrong with a website that uses Ajax, it doesn't mean that Ajax caused the problem. If Google misspelt a word on the page, would it be caused by Ajax? No. If Google put a link to a non-existent site on the page, would it be caused by Ajax? No. If Google create a layout that relies on particular font sizes to display properly, is it caused by Ajax? No. This is a display problem caused entirely by CSS. It's not "related to CSS", it *is* CSS. Write a static page that displays a list of items with a pixel-based height. It will break in exactly the same way. Now add Ajax to get the list of items from the server. Does the problem become magically caused by Ajax just by association? Of course not! --Bogtha 16:19, 23 February 2006 (UTC)

I'd like to find a way to include this in the article, because I think it represents an important aspect of the topic. Incidentally, I think similar additions to HTML and JavaScript are also needed. Robbyslaughter 03:43, 21 November 2005 (UTC)

Please refrain from editing pages on these topics until you have a deeper understanding of them. You seem to be a newbie who is learning many things at once, and assuming that one thing (e.g. fonts specified in px in CSS) is intrinsically linked to another (e.g. Ajax), merely because you learned them at the same time or saw them in the same web app. Most of your criticisms are completely unfounded and only exist because of your assumptions. Including this information in the article would mislead.

Please refrain from insulting contributors who have made an effort to use the talk pages to discuss ideas, and please refrain from personal attacks on their expertise. Robbyslaughter 03:48, 17 December 2005 (UTC)

Robby, you are taking some very distinct ideas (layout and communication schemes), mixing them up, and assuming that just because you can correlate them, you have shown that one causes the other. This is very confused thinking, and I really do believe somebody with more experience would not have such confusion. Bogtha 20:33, 3 January 2006 (UTC)

Correlation does not imply causality. However, I'm not yet convinced it's possible to make an Ajax application that is not at least a little fragile, and certainly, most of the practical examples break existing elements of the paradigm. I will continue discussion here, though, considering the controversial nature of the subject.Robbyslaughter 16:08, 9 January 2006 (UTC)

Stop looking at examples. Seriously, 99% of the code on the web is awful. Start using Ajax yourself and you'll start to realise that Ajax isn't the thing causing the problems you see. --Bogtha 18:12, 9 January 2006 (UTC)

Bogtha, I agree that most of the code on the web is awful, but can we really seperate the examples from the theory?

Yes. Please go and write a few things with Ajax. It's *not* "extremely difficult to do well", and you would know this if you actually *tried it*. --Bogtha 16:19, 23 February 2006 (UTC)

In theory, Ajax is great! In practice, it's extremely difficult to do well---and, I'm arguing, more so than the underlying technologies because it magnifies the problems in each of them. I am not arguing that Ajax is the *cause* of these problems, just that the underlying model is fragile. Robbyslaughter 22:55, 17 January 2006 (UTC)

Robbyslaughter - you are simply wrong, and should stop. --Artw 16:53, 23 December 2005 (UTC)

Stop what? I am waiting patiently here on the talk page before submitting any changes to the article, to see if anyone has any substantive feedback on the proposed criticism. The anonymous user above provided some, to which I responded. Do you have any? Robbyslaughter 19:51, 3 January 2006 (UTC)

---

I still have not made any changes to the main page, but I think there are some valid points that have arisen from this disucssion. Building Ajax applications is not like writing, say, .NET or Java/Swing apps. I'm trying to capture this difference using the term "fragility of model". Does anybody agree with me that there is a difference? Robbyslaughter 22:55, 17 January 2006 (UTC)

I agree with Robbyslaughter for the most part. Ajax is a conglomeration of standards hacks and browser extensions to turn the web into something it wasn't designed for, and as such it is fragile and breaks on a lot of browsers. HTML renderers that can handle the rest of the web just fine often break on Ajax pages, and Ajax pages that work some places don't work in others (ie: Google maps, Google mail, etc. didn't work in Konqueror until the 3.5 release, even though they worked in Safari from the same code base, and other Ajax sites worked in older Konquerors.) It's a good solution and browser support is fairly solid now, but fragility is certainly a valid criticism. Kundor 03:48, 23 February 2006 (UTC)

Support. By they way - to check is Ajax responsible for breaking "Google Suggest" or whatever carry out this little experiment - turn javascript off (thus disabling Ajax), go to the page you want to test, to your font resizing or whatever the problem seems to be. If it breaks, Ajax is not the problemstart, if it works perfectly - ajax breaks it. Kirils 19:44, 25 February 2006 (UTC)

Kirils, that's not a test that works. Consider a page that has a spelling mistake in some of the text, but that text is only shown by using Ajax. Does Ajax cause the spelling mistake? Of course not. In a similar way, the layout issue that the drop-down box has cannot be seen until Ajax is used. If the drop-down box used static data, and Ajax wasn't used to retrieve the data, it would still have exactly the same layout problem. It's simply nothing to do with Ajax, in the same way a spelling error is nothing to do with Ajax. It's directly caused by a stupid fixed-pixel height on the lAutoComplete class that is not necessary and is unrelated to Ajax. By all means use a user stylesheet of .lAutoComplete { height: auto !important; } and see the problem disappear if you don't believe me. --Bogtha 15:05, 26 February 2006 (UTC)

Single Page Application

As written, I cannot see the difference between Single Page Application and Ajax (programming). I propose a merger. -- Perfecto  00:23, 25 November 2005 (UTC)

They are not exactly the same : google suggest is ajax, it is not SPA. SPA needs Ajax. Ajax don't need SPA. Some people says that SPA is FWP : Fat Web Page.

Agree. The concepts are different. Do not merge. --Sleepyhead 08:16, 25 November 2005 (UTC)

Do NOT merge. SPA does NOT need AJAX; that is a COMPLETE and UTTER misunderstanding of the concept. Jemptymethod 02:10, 26 November 2005 (UTC)

1. Enchanter, the {{mergefrom}} tag is designed for articles not their talk pages. It is rude of you to remove it from the article without contacting me, the proposer.
2. As I said, I cannot see the difference between the two by just reading the two articles. I apologise I have a "complete and utter misunderstanding of the two concepts" — I apologise I'm an idiot and Jemptymethod is so smart — but the two articles are written to be referring to almost the same thing. Please consider this a request to improve the article to distinguish the two.
3. Please see Rich Internet Applications. Gmail is there, too! I'm further confused.

Thank you. -- Perfecto  03:17, 26 November 2005 (UTC)

I knew I could well be giving offense but I decided I had to be vehement because these two technologies are diametrically opposed: AJAX relies on server interaction, SPA is entirely client side. I understand it can be difficult to fathom all this "technology soup", at least that is the impression I get especially now that you bring up RIA's (Rich Internet Apps). Actually of the 3 acronyms, SPA is probably the best defined, the other two are to a large extent either hype or misnomers. I agree that the SPA article could probably be improved, but I don't see the need to differentiate it from AJAX, if you understand that AJAX relies on a server side request it is apparent that the two technologies are significantly different, and to cast SPA versus AJAX seems to me another step on the slippery slope where EVERYTHING needs to get redefined in terms of AJAX, to the point that plain old server side programming is being called "degradable AJAX". Jemptymethod 07:36, 27 November 2005 (UTC)

You said, if you understand that AJAX relies on a server side request; perhaps you can improve SPA starting with this. If defining SPA in terms of AJAX is a slippery slope, then are you more comfortable defining AJAX in terms of SPA? The need is quite clear to me. We are doing a poor job defining the three things clearly. -- Perfecto  08:14, 27 November 2005 (UTC)

I don't see the need. The very first sentence of the SPA article is: "A single page application (SPA) is a web application that runs entirely in the client web browser." The third bullet point at the top of the AJAX article refers to "the XMLHttpRequest object to exchange data asynchronously with the web server." To me these definitions clearly frame the differences. Anyhoo this convo, if it is going to continue, probably needs to be taken to the SPA page; myself though I see no need for further discussion. Anybody else? Jemptymethod 11:15, 27 November 2005 (UTC)

Gollum a Ajax application

Hello, i want to add Gollum to the example applications. Gollum is a free Wikipedia Browser for the fast and eyefriendly browsing throw the free encyclopedia "Wikipedia". 212.114.250.36 17:29, 27 November 2005 (UTC)

It's best that you create an good-quality Gollum (browser) article first. But remember, Wikipedia is not the place to promote your site or product. -- Perfecto  19:42, 27 November 2005 (UTC)

Ajax' Achilles Heel Link

Let's discuss before removing this. I'm open to why it should be removed, but I also think there are valid reasons for keeping it, and refutations of arguments I've seen so far for removing it. While discussion is ongoing I can also make the article more pertinent. Jemptymethod 20:51, 29 November 2005 (UTC)

I am in favor of the content being added to the article, but I see no reason to have a link to a an external site that has all of one paragraph to add on the topic. Robbyslaughter 20:55, 29 November 2005 (UTC)

Indeed. It's a poor resource that adds nothing to the article. Anything you think is worthwhile can be very easily ported over. Rufous 22:23, 29 November 2005 (UTC)

Considering the Ajax Achilles Heel article corresponds directly to a column (restricted to 100-150 words) published a few months back in hotscripts.com's monthly email newsletter, I have not added verbiage. What I have added though is a screenshot of maps.google.com with Javascript disabled. If a picture's worth a thousand words, now the article is more like 1100-1150 ;) Jemptymethod 01:03, 30 November 2005 (UTC)

There was no further discussion here for about a week, and yet the link was removed yet again. I've since restored the link, and welcome discussion as to whether the enhancements to the Ajax Achilles Heel article make this a sufficiently valuable resource. My position ahead of time is that they do indeed, in particular for people who respond to visual input more so than textual. Jemptymethod 21:30, 6 December 2005 (UTC)

I still say this 'article' is not adding anything that the Wikipedia article doesn't already cover. We have a section on JavaScript being a requirement. Of course it is, XMLHttpRequest is a JavaScript object. 'Exposing' an AJAX application as requiring JavaScript is hardly a revelation. Rufous 18:04, 7 December 2005 (UTC)

I have to admit I see a consensus forming or at least nobody but me seems to be speaking in favor of retaining this link. However I would point out the following point #4 from External_links#What_should_be_linked_to ("On articles with multiple Points of View, a link to sites dedicated to each, with a detailed explanation of each link. The number of links dedicated to one POV should not overwhelm the number dedicated to any other. One should attempt to add comments to these links informing the reader of their point of view.") as an argument for keeping it. Jemptymethod 03:31, 8 December 2005 (UTC)

Link being removed more than once a day now but with no counter to the above argument on this talk page. If this link should be removed, it could be argued that so too should be the "Why Ajax Matters Now", because that POV "overwhelm(s) the number dedicated to any other." Wear me down here in the talk page and I may concede, but until then I will continue to revert. Jemptymethod 02:26, 10 December 2005 (UTC)

Replaced link to my own site with one to a Jakob Nielsen article. There goes 70+% of my traffic, but the writing was on the wall ;) Jemptymethod 02:47, 10 December 2005 (UTC)

That isn't a Jakob Nielsen article. It's a poor parody of a frames article that he wrote, with a few terms switched. A lot of the criticisms of frames simply don't apply to Ajax, it's naive to take it as meaningful criticism. I'm removing the link. Feel free to link to *worthwhile* criticisms of Ajax, but blindly linking to anything negative makes it look like you have an axe to grind.

--Bogtha 12:16, 11 December 2005 (UTC)

"Server-Independent and Server-Centric" section

As far as I can see, this section appeared as the result of an anonymous edit on 8 December 2005. After reading the article several times, this section strikes me as very poorly integrated with the rest of the article. It exhibits at least the following problems:

• The section title is borderline nonsensical: to what do these two adjectives apply?
• What are the "couple of frameworks" in the opening sentence? As far as I can see, only one is mentioned.
• This section introduces yet another "pro and con" list into the article. Pro and con lists are considered harmful.
• The entries in that list are mostly nonsensical sentence fragments. e.g., "No AJAX and JavaScript prerequisites of programming skills"—in fact, this one isn't even a fragment. It just doesn't make sense at all.

In my opinion, this section adds close to nothing to the article and should be removed entirely. Would the original author care to argue in support of keeping it? If anyone else wants to argue in support, would you care to re-write it? I propose that it is deleted entirely. PaulHoadley 02:29, 12 December 2005 (UTC)

I see that Samyem has just added another "framework" example. While this certainly addresses the issue of the plurailty of the word "couple", it wasn't really what I had in mind for salvaging this section. The first paragraph remains barely comprehensible. Samyem—are you offering to completely re-write this section, or at least argue for its retention? Any other comments? PaulHoadley 03:29, 12 December 2005 (UTC)

Are there any supporters for this section? In the absence of any support, I propose it is deleted entirely tomorrow. PaulHoadley 02:30, 13 December 2005 (UTC)

I gave this four days, and there has been no support for retaining this section. I just deleted it. It seems I got logged out just prior to doing so, and the edit was logged to '61.95.58.54'. This is me. PaulHoadley 00:19, 16 December 2005 (UTC)

I, Tomyeh, wrote this section originally. I might not describe it clearly, but the difference of these two approaches is dramatically. By server centric I mean applications process interactivity at the server, instead of at client (or mix). The synchronization between client and server is done by the framework that takes the server centric approach. The technology is AJAX-based, but the meaning to application developers is quite different.

Hi Tom—firstly, sorry for stomping on your work. I guess the one-line summary of my original criticism is this: the section just didn't fit in with the remainder of the article. Of course, there are other parts which are similarly rough, but the combination of the points I outlined above, the fact that it certainly seemed to be an anonymous contribution, and that no one came to its defense made it a prime candidate for deletion. Obviously, you're welcome to revert the deletion, but I still think the section would need some work. Does anyone else have an opinion on this? PaulHoadley 22:04, 21 December 2005 (UTC)

I think it is better to address this issue in this article, because developers who are new to Ajax might be confused. The question, I think, is how to fit it into, rather than whether to bring it at all. Maybe it could be a sub-section of the Server-side Approaches. -- User:Tomyeh

Go for it. My original criticism was that it was difficult to understand and out of place. By all means, re-write it and incorporate it into an existing section. PaulHoadley 09:49, 27 December 2005 (UTC)

BXML merge

A couple of people have suggested BXML be merged here. Can you please comment on Wikipedia:Articles for deletion/BXML. Thanks! -- Perfecto Canada 01:57, 22 December 2005 (UTC)

If we merged BXML, shall we merge XAML, XUL and many others? If we merged the markup languages, shall we merge Java, PHP and Ruby? They are better to put in different articles. Tomyeh

Please put your comments on Wikipedia:Articles for deletion/BXML. Vote whether Backbase stays, goes here or goes away. Thanks. -- Perfecto Canada 04:05, 23 December 2005 (UTC)

Libraries and Frameworks section

If I remember correctly, we already had a section like this before and it was deleted outright as it attracted link spam. Now it's just been added back, by User:Supernerd, who by all accounts is a link spam enthusiast, offering nothing more to Wikipedia than links to some framework called Zoop in whatever article they might fit. I suggest it be deleted again (and it would be nice if someone could track down all of this user's edits and make sure they belong). Rufous 03:45, 25 December 2005 (UTC)

Does this mean the whole section has to be removed? It was very useful. Maybe add a category or something?--Nkour 18:15, 3 March 2006 (UTC)

A category might be useful. That means that every framework must have a Wikipedia article though. And that is a good way to keep only the most relevant and popular frameworks listed. --Sleepyhead 18:32, 3 March 2006 (UTC)

Backbase got deleted not long ago, I suspect only a few of the frameworks have better credentials than it. --Artw 22:10, 3 March 2006 (UTC)

Pronouncing

How do I pronouce Ajax? I-axe or Ay-Jacks? --ComputerJoe 20:00, 2 January 2006 (UTC)

Pronounced "Ay-Jacks". --Gary King 21:23, 2 January 2006 (UTC)

To clarify, thats "A-Jacks" rather than "I-Jacks" (as the scottish would pronounce the above) Thelem 18:44, 5 February 2006 (UTC)

Lack of development tools? Also: Hummingbird and Desktop.com links

I'm not sure the "Lack of development tools" critisism holds true - while it's true that there are no specific Ajax development tools (unless you count the various frameworks) that's largely because AJAX is a composite of several different server and clientside technologies, all of which do have development tools.

OK, maybe I should have worded it more precisely... There are development tools that allow one to develop Ajax applictions. Some of them even help a little in the process. Then there are frameworks and/or librares that make specific tasks easier. However, there are no full-encompassing IDEs comparable to those for desktop applications.

I am not a VB fan, but let's use it as a well-known example. Developer starts it up, drags and drops UI components, ties handlers to events, writes some code and voila - there you have an app. Although this is theoretically possible even for RIA/Ajax apps (Hummingbird has entertained the idea but that is a whole different story), there is nothing even remotely comparable to what VB IDE offers. Arguably, the ease of development of VB apps in VB IDE is the spark that started the explosion of many (Windows) desktop applications - it became easy to write them. We can argue that most of them are of arguable quality, but the same idea exists in other IDEs as well. We have yet to see that for RIA/Ajax.

--Aleksandar Šušnjar 20:07, 13 January 2006 (UTC)

Hmm. I'm still severely dubious of several premises of this section: that having some kind of drag and drop development environment is the be-all-and-end-all of programming, that current frameworks don't count towards that, the implication that existing web development practices don't work for sites using AJAX, that a site using AJAX technologies has to be some kind of equivalent to a desktop app.

BTW What's the relevance of the Hummingbird link? It doesn't seem to mention AJAX on the site at all ("Your search - site:www.hummingbird.com ajax - did not match any documents.")

--Artw 21:49, 13 January 2006 (UTC)

Well, put it this way. Imagine if you had as many ready-made UI controls as you can find for desktop apps. Imagine if the IDE did all the linking between the code and instances for you, as pure JavaScript and HTML usually do not. Imagine if you, in fact, did not have to worry about any communication with the server at all - all you do is call methods of smart objects. Creating "Ajax" apps would then be a breeze. I am not implying that existing web dev practices don't work for sites using Ajax nor that Ajax apps have to be equivalent to a desktop app - but that is the direction they can be taken to and that is how they differ from "traditional web apps". Lack of tools is one of the reasons why there aren't many (I know of only one) desktop equivalent app.

Relevance of Hummingbird link is there for people who built their solutions on Hummingbird platform. You won't find Ajax there because that is just a very new term. Hummingbird calls its architecture different terms, incl. "Webtop", "Web UI Objects", "Constructs", etc. but is essentially the most powerful Ajax app (and platform) I've seen so far, and it was done in 2001 - long before "Ajax" is coined. On top of that it is flexible to use any (incl. custom) transport protocol, completely abstracted from both client and the server, so either XML, JSON or other "serialization type" can be used, via separate (de)serialization streams. Other important parts woth mentioning were the environment controller (sort of a rudimentary client-side operating system - resource manager), HTML element to proper object event distribution, library to aid/simulate classes in JavaScript along with inheritance, a library (class hierarchy) of ready-made UI controls, etc.

I also added "desktop.com", albeit without a link. I think those people deserve to be mentioned. I remember them being alive somwhere between 1999 and 2001 - not sure. They made, essentially, a simulator of a typical desktop - all with applications, program managers / start menus, window management, etc - your desktop. You could log in from anywhere and deal with your apps. To top it all they did it in IE4 and announced NN4 support. Bad part: took ages to log in, while it loaded all the stuff it needed. Generally very nice idea, maybe ahead of its time, which is why the domain desktop.com now seems to belong to someone else (or at least there is no mention of what it used to be). Maybe someone can bring some light about desktop.com?

I thought it makes sense to put the link to people who actually did something about it when there are links to those who just talked about it or did comparatively very little (Macromedia, Microsoft, Google).

--Aleksandar Šušnjar 22:39, 13 January 2006 (UTC)

If it worked in IE4 and NN4 it probably wasn't AJAX, as the XMLHTTP object wasn;t around until later versions of that browser. It sound slike what you're describing is some clever ASP/DHTML interaction that works in some other way. The links should be removed as they are confusing and not helpful to anyone wanting to know about AJAX. --Artw 23:09, 13 January 2006 (UTC)

I was interested in desktop.com at the time and saw what it did. If you limit AJAX to XML than they may not qualify. However, neither is "Ajax" any more limited to XML - see article itself (e.g. quote: "XML is commonly used, although any format will work, including preformatted HTML, plain text, JSON and even EBML"). On the other hand it had more verbose and powerful client-side implementation than most todays players and is comparable in complexity to Hummingbird's. I am not describing "clever ASP/DHTML" interaction in any other way. I had my hands "dirty" on both.

As for helpfulnes, this article also presents history. I beleve the credit for starting the idea should go to people who did something notable and either desktop.com or Hummingbird alone probably outweigh all others mentioned in the article combined.

--Aleksandar Šušnjar 23:25, 13 January 2006 (UTC)

Without wanting to get into an edit war, I really don't see much evidence that they're part of the history of AJAX, or even use AJAX at all - in fact all i can see is a dead link and a link to a rather impenentrable product information page. Are they browser based applications, in HTML and Jabvascript, which interact with the server without reloading the page? If so then they'd be AJAX-like, but without using XMLHttp (note: not necessarly XML) they fall outside of most definitions of AJAX. And if they don't use XMLHttp by what method do they work?

--Artw 23:44, 13 January 2006 (UTC)

It is hard to find evidence for desktop.com as it no longer exists as a company. Domain is currently owned by some other company. I tried my best and created the stub article for it, in hopes that people involved in developing it will notice and provide some more information. For now have a look at it and the links at the bottom - "online traces of existence" I've found.

As for Hummingbird solutions I was quite involved in developing and architecting (for) it. Unfortunately I haven't found public information - documentation seems to only be available to customers and partners, but I will probe further. Humminbird has a framework that can (but does not have to) use XMLHttp (different ones for different browsers). For example, for JSON communication it uses IFRAMEs. You are the first person restricting Ajax to XML. I grant that XML is in its name and that others are not but you have to acknowledge what the article already states and what most people think of Ajax - XML is common, but not required. If you want to discount all but XML then the article has to be seriously rewritten and many other references and links removed. Last but not least, AJAX does not require XMLHttp. There are ways of transferring and parsing XML otherwise, although not as efficiently.

Last but not least, I am honestly not trying to put ads here. I removed the links, but I believe all those people deserve the credit for their achievements, especially when compared to other listed. Don't get me wrong - I don't want them removed. Although rather simplistic (when compared to desktop.com/Hummingbird) the other companies mentioned (e.g. Google) are very popular and influential. But they are not the (only/true) pioneers.

Instead of spending time explaining all of these things here in the talk page, I'll set up the article for Hummingbird DM Webtop and put everything there. I just have to confirm with Hummingbird as to how much can be made public.

I'm also asking you for a little patience. The fact that you're not personally aware of some facts does not mean that they should be removed. After all most of us know very little and rely on others to provide information. I am myself very interested in Ajax/RIA/whatever-you-want-to-call-it architecture as I really never fully believed in "traditional web apps". They all too much smell of classic "dumb terminal and mainframe" paradigm, only with more colourful and less interactive terminals. Furthermore, while the servers are truly powerful, they are not as many times faster than a typical user workstation as many users they have to handle - therefore too much client-side power is wasted... If only we had compiled client-side JavaScript, for example, thing would start looking really great...

--Aleksandar Šušnjar 04:28, 14 January 2006 (UTC)

A lack of dedicated development tools seems like a very empty criticism to me. Tools will turn up if there is a definite requirement among developers for them. Since Ajax is simply well-known technologies that we've been developing in for many years, brought together, I don't see why — necessarily — development tools on the level of those designed for desktop application development are required.

Secondly, the addition of all of this Hummingbird etc. "historical" data has made the first sections of this article disastrously complicated. Aleksandar, you are talking about parts of the history of remote scripting, not of Ajax as we know it today. Please clean this section up. Rufous 16:40, 14 January 2006 (UTC)

Hmmm... I agree with you that "History" needs to reorganized and cleaned. But I disagree that I am talking about "remote scripting" (as proposed by Microsoft, e.g. via Java applets). Hummingbird approach is true Ajax in every aspect although it does take it even further (than anyone else) - underlying protocol and data formats are pluggable and not restricted to any one. What we call Ajax today is essentially a JavaScript-powered client (browser) side app technology where code is delivered on demand from the server and in which the client-side code can asynchronously communicate data (not visual HTML pages or snippets). XML is commonly used transport format but not really required. Hummingbird architecture, for example, fits the entire description and extends it further and was created years before the "Ajax" term has even been coined, before other players came up with their little Ajax "enhacements" to their existing products (Hummingbird app is "Ajax" in its entirety - it is not just used as an enhacement). I think that qualifies Hummingbird as a "pioneer" more so than others listed. Desktop.com is another example.

If anything was "hastily" added it is the mentions of everyone else. What has Microsoft done? Talked about it and implemented proprietary and rudimentary enhancements here-and-there. What has Google done? Came later and made some (although important) enhancements to their services. However, due to their popularity their actions became immediatelly visible. What has Macromedia done? Came really late, talked about it and wanted to do it with Flash (it is worth mentioning). So, if those companies are to be present in the article as late-coming all-talk-no-action (with some exceptions) then actual performers and pioneers such as Desktop.com and Hummingbird (and possibly others I would like to hear about) absolutely MUST be credited.

Last but not least about the lack of tools being "empty" criticism. It worries me as well, as I don't like including information to be dated in encyclopaedic content. However, in this case we have no choice. Pretty much all pros and cons are dated. Current fact is that even when tools do exist they support advance Ajax only to the level of "checkmarking" it - rudimentary. I am personally eager to see the time when that stops being the fact and will want to see the guys making those tools credited for their efforts. History is about what happened, explanations and important people. In this case desktop.com and Hummingbird are at least as important as anyone else listed.

--Aleksandar Šušnjar 17:37, 14 January 2006 (UTC)

I;ve just made a number of edits to the article, all of wehich seem to originate witgh yourself, and all of which seems to be intended to tilt the meaning of the term AJAX away from it;s common usage and (I suspect) towards wahtever Desktop.com and Hummingbird are.

Desktop.com sounds interesting, but I don't think it's as big a part of internet history as you imply it is, and is tertiaqry to AJAX history at best. This article will become meaningless if we start inclusing everyone who was using an iframe hack or similar to transfer data before AJAX. Perhaps a general article on remote scripting techniques would be a good idea?

Your claims that Hummingbird is an important part of AJAX history and are the top rpoponents of AJAX development at this time are completely unsubstantiated by anything Ican find - as far as I can tell they make a document management system with a nice but unremarkable interface. Until you can back it up it should not be included, and certainly not linked to in multiple places throughout the article as you would have.

Also I've deleted the "development tools" section as it seems to have devolved into gibberish. Free free to rewrite it in a clearer manner, and without a surfiet of crufty links, but please don't simply restore it.

--Artw 18:06, 14 January 2006 (UTC)

I tried the search myself ... did not find much on-line but here's one mentioning the customization course: 411: Customizing DM Webtop.

--Aleksandar Šušnjar 22:52, 13 January 2006 (UTC)

Article is vandalised by subjective, narrow-minded people

I have tried to bring some more information into the article, based on real-world proven facts and experiences. Yet people who do not (want) to understand the concept and are obviously restricted to glorifying few less important players freely and without any regard to actual facts, believing that what they know is the only and absolute truth beyond which there is none.

Just one of the worse examples is removing note on performance implicated by number and volume of network communication. Simpler or poorly written apps will not get any benefits. On the other hand, I have witnessed significant improvements I described in prior edits, possible due to proper and full architecture. I guess that's not important as the "authorities" do not approve. This is ridicilous.

Well then. Forget Ajax then, as it is apparently not what most people think of it. Go and use some other technology. For example, visit desktop.com or Hummingbird DM Webtop when and if they become available.

--Aleksandar Šušnjar 18:09, 14 January 2006 (UTC)

--- According to his website Aleksandar Šušnjar is currently employed as Technical Architect at Hummingbird Ltd.

I absolutely am. I pointed out my involvement in these technologies above. That only makes my statements re pros and cons more relevant. Would it make any difference if the improvements to the content were done by someone else?

--Aleksandar Šušnjar 18:29, 14 January 2006 (UTC)

One more thing. I was never employed with desktop.com or otherwise affiliated. In fact, you could say that I was their competitor. Yet, apparently, desktop.com doesn't fit either. Right? Why? I guess because "authorities" don't know about them.

--Aleksandar Šušnjar 18:33, 14 January 2006 (UTC)

You haven't backed up any of your information with references, possibly because the supporting materials do not exist. I can not comment on the validity of your claims re: Hummingbird, but if all you can offer are links to the company's generic homepage and your word, then this information is not very compelling. Rufous 19:25, 14 January 2006 (UTC)

Its not like I had any chance as most of my "Wikipedia" time went into this talk page. I can also add that I had all the wrong assumptions about collaboration on this site - at least this article. I remember desktop.com, for example, because I looked at the product and even at the code - as I was interested in learning how they did stuff. I was hoping that others, more involved (such as former desktop.com employees - developers) would shed light on details. I myself spend significant time trying to find desktop.com references, and I was only able to find some. Would anyone help? No. If something does not someones expected style or desires it is easier and apparently better to remove the entire section rather than fixing/improving it further. What a shining example of collaborative work! And I was under assumption that "British writers" actually write, not remove text.

As for Hummingbird it is both easy and hard. I am not doing this as a part of my job and have yet to talk to Hummingbird about releasing some material to the public. I originally assumed that it would already be available but I was proven wrong. "Proof", so much more required here than elsewhere, however does exist - many Hummingbird partners and customers do have the "DM Webtop Customization Guide" which talks about the architecture at length - and how to extend it.

Then there are those sections that are (sorry: were) self-explanatory. For example:

• "Load distribution and performance" and "Network utilization". I am not to blame for someone being "trigger happy" on HTTP requests. What Ajax (again, I'm sorry, apparently not Ajax but something better) allows is that we have smarter clients - much like the difference between dumb terminal with mainframes versus client-server or n-tier architectures. Can one make smart clients slower than dumb ones? Absolutely - I've seen all sorts of poorly designed apps. But with proper approach you get to squeeze many benefits out. Want real world examples? Here are some - navigation tree does not need to be regenerated on every click nor needs entire data to be sent. Data already received can be cached at the client, therefore reducing the need for subsequent requests. Client can also ask for some data ahead of time, combining it with other requests, further optimizing the performance. Need more? OK. Search results. When desktop apps handle them they get result data and show them as users scroll the list (for example). If users scroll back they don't need to refetch those results - they have them. Can Ajax do it? If we look at text that has been removed, apparently not. Well, I say that it is already happening, at least since 2001.

• Comment "restored "lightweight mini-applications" - no one is writing Office in Javascript)" is based on what? I provided the link to applications that are a) not lightweight and b) not mini. Can I say that Hummingbird rewrote Microsoft Office? Of course not. But the product is of equal importance, very large and very high complexity, as can be seen by following the links I provided. Did anyone bother actually checking this before the above statment is made and its corresponding edit? I guess not.

• Part of "Interactivity" section was removed pointing out to what DHTML does not do, yet is replaced by "using a full range of DHTML techniques". DHTML spec must have grown quite a bit since yesterday, as it is capable now of doing advanced features previously only available on desktop apps.

• Comment "Browsers that support Ajax - Changed to indicate XMLHttp support. Idf we start inclusing support for iframe hacks and the like on this list then it becomes meaningless" is very interesting. Is IFRAME hack or just a tool for the hack? What if the browser does not support other features needed for Ajax? Is XMLHttp really the only thing needed? Maybe we should rename Ajax to AjaXMLHttp and remove references to everything else. BTW, in this case and strictly speaking IE does not support Ajax.

I am also getting a message that people involved in work described are not supposed to contribute describing it. I guess by the same token Jimmy Wales should not write about Wikipedia, James Gosling about Java and all the articles should be written by bystanders. Do not confuse this with NPOV, though. I did my best to make my comments NPOV and probably went too far. Maybe I am mistaken and need to work on it, but there's that collaboration assumption of mine. On the other hand, some bystanders (or are they?) active on this article need to work on their approaches as well.

I don't have any intentions to create or fight an edit war. You win. I lose. I think Wikipedia loses as well, along with people interested in learning more about this technology.

--Aleksandar Šušnjar 20:42, 14 January 2006 (UTC)

Aleksandar - theres nothing to stop you working on the article to address any of the deficiencies you point out, and adding some text on the effect oif AJAX on sever load does seem like a good idea, and you certainly seem like you know what you're talking about. However in a collaborative process there is always the possibility that people will disagree with you. I'm afraid it seems pretty unlikely that anyone is going to agree with you on the importance of Hummingbird for instance (and, yes, if you try to introduce Hummingbird links it will always look suspect) but that's no reason to take your toys and go home.

-- 67.183.219.202 21:54, 14 January 2006

I had some time and invested it it what I believe was a good effort. But I don't have enough of it to fight wars. Basically all my edits were reverted and unless there's someone to back up what I started I am not going to get involved any more. I learned to like Wikipedia and spent enough time working on it that I neglected by other duties and life. Without any help there will be no point in me trying to do anything. As for "suspicion", I don't see where is the problem. I pointed out some facts that can be checked out, albeit maybe not online... and I got burned for it before I started. Hummingbird will not gain or lose any business dependent on this article and neither I will not see any benefit from it. In fact, I must be very careful as to what I say to avoid saying too much, as I am under non-disclosure agreement and I haven't talked with my employer about how much can be published. Further, as it seems, Microsoft-Macromedia-Google consortium on Ajax is the all-important for very little actual involvement. I've seen many people trying to post GOOD information about their (or not) companies providing good stuff re Ajax - all of their edits got reverted. Yet, at present, those links is exactly what I personally would have liked to see in the article - they would have helped me learn more. So, if someone wants to cool off the triggers and turn on the brains for some time - help and get involved.

--Aleksandar Šušnjar 22:25, 14 January 2006 (UTC)

Aleksandar, I recommend that you continue with your separate article on the Hummingbird product and then find an appropriate place to reference it here when the topic settles. It sounds as though it's a compelling work and worthy of attention. As someone who has spent a lot of time over the years with my ear to the ground on anything to do with the various techniques and implementations of browser-based Javascript RPC before the Ajax name arrived, the fact that I had never heard of Hummingbird's product until seeing this discussion last week leads me to opine that the History section is perhaps not the place for this item to be referenced from this topic. While your contention that it has been around since 2000/2001 is not in dispute, its absense from the radar of the community which was collaborating during that time to define and refine the techniques would not lead me to include its contribution as "historical". Once this Ajax (Programming) topic has settled somewhat, it might be time to reinstate the Libraries and Frameworks section where a reference would make a better fit.

--Brentashley 03:57, 15 January 2006 (UTC)

Thanks. I may do just that. As for the community which was collaborating to define and refine the concept - I am not sure that there was one such 'community'. I've seen a number efforts, some of which I'd like to learn more about (desktop.com). However, there was no and still isn't one such authority on the issue. If there is, I'd like to join it, as I believe I can bring a lot to the table.

--Aleksandar Šušnjar 04:53, 15 January 2006 (UTC)

Yes, I accept that it's inaccurate to give the impression that there was one cohesive community. I can only speak from my own experience - during those years I actively sought out any discussions from far and wide on the topic and there were a few people whose contributions stood out for me. Of course, your mileage may vary.

--Brentashley 05:18, 15 January 2006 (UTC)

Here we go again

Here we go again... logically challenged British writer and web developer currently based in Seattle. has done it again: Reverted to web applications - Rich Internet Applications has Flash connotations, also AJAX doesn't necessarily have to be used to create something so grandiose. If he read Rich Internet Application article he would have learned that it is not tied to Flash at all and includes description of JavaScript approach. Second, RIA is not a subset of AJAX but vice versa. So even if he does not think that AJAX does not have to be used to create something so grandiose, a) it is not even mentioned anywhere and b) even he says "does not have to be" which means that it still can.

Since User:Artw seems to be an absolute authority I hereby reiterate proposal to rename AJAX to AjaXMLHTTP and change "A" to stand for "Artw" instead of "Asynchronous".

Can it get any more ridiculous than this?

--Aleksandar Šušnjar 16:24, 15 January 2006 (UTC)

Wll I thought you might throw a fit about it, so I didn't like doing it, but you made a change to an established portion of the article which again subtley shifts the term. Web applications fits better in the sentence and has a broader, more encompasing meaning.

BTW - "The term "Rich Internet Application" was introduced in a Macromedia whitepaper in March 2002" - that's where your Flash connotations come in. Most people take it to mean a Flash movie which imports XML.

Also in the Rich Internet Application article: "Rich Internet Applications (RIA) are a cross between web applications and traditional desktop applications, transferring some of the processing to the client end"

Is that a good description of Google Suggest? Because I happen to think that Google Suggest is a very good example of Ajax usage. It's no Dektop.com, but it extends the usability of a website using javasacript and XMLhttp, and in a very stable reliable way, not hidden away in an intranet or limited by browser types.

I'm no absolute authority, in the most part I'm just reverting stuff that you are adding which seems to be damaging to the article / peculiar to your own interpretation of AJAX.

I would suggets you reread the original Adaptive Path Article in which the phase was coined and concider wether the changes you have been making are in the spirit of that. If not then they probably don't belong.

And please leave off the personal attacks.

--Artw 19:08, 15 January 2006 (UTC)

• To begin with personal attacks: You reverted every single edit I made without proper reasons to do so, as already shown above.

• Ajax concept came much later, by another company and it does not imply any products of that company. You should read about the concept and not stop at the point of reading who invented the term. It is a good term, much better than Ajax in many regards.

• Ajax apps do, whether you like it or not, transfer some processing to the client end. If you disagree with this, go learn about JavaScript. The "cross" between web and desktop is in that transfer.

• Google is one of the examples of Ajax and, therefore of RIA (as Ajax is RIA done some very specific way - JavaScript and XML). However, it is not the only or defining example of what Ajax is. I can show you much more done, not limited by browser types and also reliable. Intranet does not come into picture anywhere. Noone requires that Ajax is used only for public Application Service Provider approach. Also, if you're referring to Hummingbird Ltd its products have been exposed to public by customers.

• OK... So I am damaging the article with my peculiar interpretation of Ajax. And revert this based on public opinion since you are elected representative of 'public'? That has yet to be seen. My edits applied to Ajax even by your interpretation (as shown above) - yet you blatantly reverted them. How's that about vandalism and personal attack? If you don't have personal experince with something (as in many cases here) it does not mean that the edits need to be reverted immediatelly.

--Aleksandar Šušnjar 19:24, 15 January 2006 (UTC)

I'm no longer interested in this conversation, do whatever you feel like. i would urge others to treat your edits with extreme suspision and revert them if necessary, as so far they have all been without merit. --Artw 19:33, 15 January 2006 (UTC)

There will be no further article edits on my part. As for the 'merit' I don't need to put any more comments than are already available.

--Aleksandar Šušnjar 19:57, 15 January 2006 (UTC)

Pros, Cons, What Ajax is (not)

I've agreed and disagreed with rather interesting number of participants here. However, I have too many things related to this article to put in a talk page (I did try, as can be seen above). Whether you find me as "suspicious" or not, please have a look at my user sub-page I have set up, related to Ajax.

It has a lot of stuff in it and you might find that you agree with me or not and help me understand why am I wrong. I'd appreciate any sincere input. If you have any response, please do not make it here but here. --Aleksandar Šušnjar 05:48, 18 January 2006 (UTC)

AJAX acronym

If you look for AJAX on the web you will find people using two acronyms, "Asynchronous Javascript and XML" and "Advanced Javascript and XML." A few editors to this page do not agree with the second acronym. Should we exclude it despite its current use? Is there a formal AJAX specification that defines this? Some example sites that use the second acronym include:

• ITtoolbox
• Compuware
• Lockergnome

--Dirkbike 12:49, 16 February 2006 (UTC)

"Advanced Javascript and XML." != Ajax. See the original Ajax article. --Sleepyhead 13:24, 16 February 2006 (UTC)

Um... I think the question is whether the new acronym is worth mentioning in the article. By no means does the original Ajax article represent any authority in this matter. --68.61.72.130 23:42, 18 February 2006 (UTC)

SVG

Is there actually any evidence that a significant number of AJAX applications are using SVG for their output? If not we should remove the reference to it from the intro. --Artw 22:55, 23 February 2006 (UTC)

agree. --Kirils 19:50, 25 February 2006 (UTC)

Pronunciation

Hi All

Kirils just left the following message on my talk page. Is he in charge around here? --Nigelj 23:07, 26 February 2006 (UTC)

Hi. I agree to leave your edition while we discuss the factuality of pronunciation "A-JAX". Would you be so kind as to start a discussion concerning this on the talk page? -- Kirils 22:38, 26 February 2006 (UTC)

---

Hello. No, please! I'm by no means in charge aournd here! :) Nigelj insisted on removing pronunciation specification (A-JAX) from the article, so I wanted him to clarify his point in the talk page so that others can discuss it. In my opinion, pronunciation needs to stay in the article. It's not like we are MAKING everyone who reads the article to pronounce ajax that way (if you feel that's a wrong way to pronounce it). We are providing INFROMATION for thouse who have no idea on how to pronounce it and came here for the info. -- Kirils 07:31, 27 February 2006 (UTC)

---

Ajax, as a word, first appears in written form ('Αἴᾱς') in Homer's Illiad, written in probably about the 8th century BCE. It is a famous hero's name, widely believed to be in spoken use in perhaps the 13th or 12th century BCE, during the Trojan Wars, when the Illiad is set[1]. The word has therefore been in widespread use all over Europe for up to 3000 years. It is familiar to speakers of most European languages. It is the name of several European sports teams, including a famous football team in Amsterdam [2]. It is also the name of a range of cleaning chemicals manufactured in the UK and sold globally[3]. See the Ajax disambiguation page for many more examples of its use - check them for pronunciation guides if you like.

As an acronym for a programming technique, there is no reason why those referring to the technique should not pronounce the word however it normally pronounced - and has probably been pronounced for millenia - in their own country. With reference to programming, this is not a trademark or a word 'owned' by any person, group, organisation or company. There is no worldwide "authority" on the pronunciation of this word in this context[4]. I cannot even find any evidence that the multi-national Colgate-Palmolive is trying to tie down the pronunciation of the trademark when it refers to their cleaning products.

Even if we wanted to specify the "approved", "Wikipedia" pronunciation of the word with regard to programming practice, simply repeating the word in block capitals, and separating the two symbols ('A-JAX') would serve no purpose: people would still pronounce a, j and x how they like and would still stress whichever syllable they prefer.

I see that the developers and maintainers of this article proudly proclaim at the top of the talk page that "It has become a hot-spot for user in-fighting." and warn us to tread carefully or we'll be eaten alive. I don't know who's responsible for this approach here, but, jeeez, if you make such a meal of one simple, well-justified deletion of two words [5], I can't help feeling you are doing Wikipedia's development a mis-service. --Nigelj 21:46, 27 February 2006 (UTC)

Even if this is contraversial, its information thats really useful. An agreed pronounciation (or at least a selection) would be really handy becasue then when I go into a meeting, people will know what I am talking about. 62.232.6.254 17:13, 9 March 2006 (UTC)

Several parts of an article

I have found four links to Ibm/Alphawork: Mastering Ajax and then Mastering Ajax Part 1, and then Mastering Ajax Part 2, etc...

I have removed all the parts since a click on the first link gives access to the three parts.

But a day after, the links have resurected. Is this spam or not?

I have removed them, to leave just the main link, but tomorrows...

Multiple links on same website: need advice

The previous problem seems solved now. But Alphaworks still has two links on different pages, but these pages are linked on another.

I think one must be removed, and one must remains.

Some advice???

What does it take to keep an external link below the article?

Greetings all - I've published a demo and tutorial for live-searching with AJAX using the Ruby on Rails framework and I think it would be helpful for readers to see and learn how easily AJAX can be implemented with Rails. I noticed the discussion on frameworks above; that mention of them invites link spamming and perhaps I'd be labeled as one. Fair enough. So I'm asking - what does it take to keep an external link at the bottom of the article? Specifically, how would the demo and tutorial I've written need to change?

83.77.179.43 19:35, 5 March 2006 (UTC) ~ william@railshosting.org ~ Trying to actually be helpful...

Adding notable material, not self pimping, should be the goal. --67.183.217.212 05:09, 6 March 2006 (UTC)

If it is a tutorial, with source code, not associated to a commercial product, not a part of a commercial page, it is good. It is just my advice. 84.4.43.144 22:09, 6 March 2006 (UTC)

The link that just got deleted (bea web portal) wasn't particualrly adding anything, so no complaints there. --Artw 22:35, 6 March 2006 (UTC)

Ruby on rail is Ruby, not AJAX (if we don't use Ruby, not useful). But we need also for real free content, either text or code, and not disguised advertisement. Booles 06:35, 21 March 2006 (UTC)

That's all good and dandy, but shouldn't Rails be mentioned somewhere considering it's implementation of Ajax (and I'm not just talking about Prototype). One of the advantages of Rails is Ajax and Rails and Rails isn't mentioned once... --Weters 19:25, 22 March 2006 (UTC)

History

The current version of the history is absolutely horrible, and seems to primarily focus on finding things that are like remote scripting in order to disprove the origins of current techniques in MS remote scripting, presumably due to some kind of anti microsoft bias. This seriously needs fixing. The is no AJAX code in use today whatsoever that has its origins in hacks based on the layer tag, primalily because teh entire code base of NS4 was standards non-compliant and had to be scraped - it's an unleated dead end of no use to anyone interested in AJAX. --67.183.217.212 05:14, 6 March 2006 (UTC)

• Remote Scripting has it's own page, and it's full history along with it's possible predecesors should probably be moved to there. The history section should contain a link to that, and maybe a cutdown summary, but should mainly be reserved for the history of AJAX, focusing on notable uses of technology that are generally accepted to be AJAX. I'm guessing the Layer tag will not be involved --Artw 19:44, 6 March 2006 (UTC)

• • I've made a start on making History a little more sane, but itprobbaly needs a copy edit and shaping up. I'm still unneasy about including every single quasi-ajax technique for updating webpages - are obsucre coding techniques for depricated browsers really noteable or relevant? - and I still feel that if this becomes an extensive history of remote scripting techniques then it should sit under "remote scripting" instead. --Artw 19:06, 8 March 2006 (UTC)

The "Auction Demo" was the first application to combine DHTML, Javascript and XMLHTTPRequest in the Ajax-style. The "Auction Demo" showed live bid updates for an auction on a web page. The "Auction Demo" was written in either 1997 or 1998 by Adam Bosworth at Microsoft and was shown to many outside Microsoft. XMLHTTPRequest was created by Bosworth's team for the explicit purpose of creating what we now call Ajax applications. For reasons I don't understand, people did not pick up on the vision shown in the "auction demo" for a couple of years.

Accessibility

I'm removing the paragraph about accessibility from the cons section. It was in the usability subsection, although it's not a usability issue. Two short sentences aren't enough to create a subsection of its own, and accessibility has a whole section of its own directly underneath, so any subsection would be redundant anyway. If you disagree, let's talk about it here. --Bogtha 20:49, 8 March 2006 (UTC)

Markup Language vs Programming

Currently this section contains the sentences:
"The major advantage of the declarative approach is that non-programmers are allowed to define user interfaces with HTML-like markup language. The disadvantage is that pages are becoming harder and more obscure to design and maintain, as it becomes more sophisticated."
At best the wording of the second sentence is highly confusing. I propose changing it to read:
"...The disadvantage is that pages are becoming harder to design and maintain as the markup language becomes more sophisticated."
I don't have any experience with this particular part of Ajax, so I'm requesting comments on this change. --Jarsyl 01:58, 15 March 2006 (UTC)

I agree that it's confusing, but I think the entire section should be removed. As far as I can tell, it's just a reference to Backbase's BXML that is vaguely-worded to avoid being classed as spam. In my opinion, it's misleading as it implies that the Backbase approach is the "common approach", but that is not even close to being true. It should either be completely rewritten or removed entirely - as it stands, even with your proposed change, I don't think it adds anything but confusion to the article. --Bogtha 19:00, 16 March 2006 (UTC)

I've removed the section entirely as per Bogothas suggestion. if theres an AJAX specific framework that uses this technique let's mention it directly. --Artw 22:40, 16 March 2006 (UTC)

Ajax on Rails

I think we should at the very least provide a link (and a new page) to Ajax and Rails discussing Rail's implementation of Ajax. Considering it's one of the attractions of Rails, it shouldn't be ignored. Weters 19:27, 22 March 2006 (UTC)

IMHO thats for a Rails article, not an Ajax article. --Artw 19:43, 22 March 2006 (UTC)

I definitely agree with Artw. For one, Rails uses a few libraries for its Ajax implementation. --Booch 19:45, 26 March 2006 (UTC)

Ajax for ASP.NET

I wonder if this link is really relevant in the "tutorial" section.
I believe this section is for teaching Ajax, not application of Ajax in any environnments. Similar to Ruby on rail.
This is just my opinion...
The title is ASP.NET spiced. I have read the article, this is really not that I need to learn Ajax!

Booles 12:03, 27 March 2006 (UTC)

I agree. I thik the following links should be removed:

- Cross-browser Ajax Tutorial using the Sarissa library.

- JavaScript refactoring for safer, faster, better Ajax.

- ASP.NET Spiced: AJAX from MSDN.

The other articles from Apple, Mozilla and IBM gives a good introduction in how to use Ajax and should be listed. There is no need for additional tutorials.

I also think the 'Weighing the Alternatives How Ajax stacks up against competing RIA approaches.' link in the article section should be removed.

This article has a linkspam problem and we must be careful with adding links. Only relevant links from credible sources should be listed. --Sleepyhead 12:28, 27 March 2006 (UTC)

The external links section has finally come to rest in a state of sanity. Apart from the MSDN one, the links that are there now have survived peer review for months, and should be kept. I've removed the ASP.NET link, and added a comment to the code for users who wish to add new links. This same strategy was used in the HTML article, and has worked well. Rufous 14:08, 27 March 2006 (UTC)

I removed two other links because I do not think they add any extra value. If we keep the Sarissa article then there is a bunch of similar articles using other frameworks that can be added. The Apple article already explains how to implement a cross-browser XHR solution. --Sleepyhead 15:18, 27 March 2006 (UTC)

I do not support adding an explanation of the use of multiple frameworks, but I must argue the point that showing the use of a single framework does indeed add value. The code in the tutorial that uses Sarissa is significantly less complex than the code in the older Apple tutorial. Realistically, nobody should be writing their own code branching for creating the XMLHttpRequest object when that code can be abstracted cleanly through a framework. Furthermore, the article demonstrates the use of POST with Ajax, when many others incorrectly use GET requests to change data on the server. Rufous 16:02, 27 March 2006 (UTC)

I don't agree with Sleepyhead81 that is not a real contributor actually.
I believe there is need for several tutorials according to level of experience of many users.
There is nothing in the guideline about limiting the number of tutorials.
About IBM/Alphawork, their tutor is just the specification of XMLHttpRequest with lot of screenshoots. The screens display alerts, that if not of great interest. And the article is not readable.
Alphaworks also is known to be an agressive spammer and in the past they have removed links from others contributors to make room for several links to their article (part 1, part 2, etc...) Please, Sleepyhead81, don't remove links for yours reasons and not reasons from the guidelines. Booles 06:43, 28 March 2006 (UTC)

The guidelines does not specify how many external links there should be. But it should be kept to a minimum. Wikipedia is not a link farm. I agree with the IBM spam though. --Sleepyhead

I am not convinced we should restrict the number of tutorials. I come here to the text but also to the links that give me a lot more valuable info. Links must be relevant and not commercial, apart that, no reason to limit them. Please don't remove something without discussion (apart jokes and commercial ads of course). Or remove the IBM link instead. I'll investigate this link further. Booles 13:58, 28 March 2006 (UTC)

I think the link is yours. You are the one who added it. The link does not give any extra information compared to the other articles. It will be removed if you try to add it again.

Of course I have added it! My contrib is signed. Not yours. Apart to invent something, I can't add extra information. The linked page is a real tutorial, simple, clean for beginners not a big, verbose text as the one from IBM, that is not a real tutor, but that is a book actually. Can't add something to that, but nobody also want to read it. Removing a link without discussion here is vandalism. Booles 14:26, 28 March 2006 (UTC)

Well no, it isn't — it is a bold edit. Please do not enter into another revert war. This article has had enough of them. Rufous 15:31, 28 March 2006 (UTC)

This is an active website. These comments perhaps were right for the previous version, but the current page is far more complete than other tutorials here. The page from Apple speaks only of XMLHttpRequest, and would be most suited on the page dedicated to this object. Booles 11:36, 30 March 2006 (UTC)

Proposal for a new page

This is just an idea, I have no special interest in that, I have not written any Ajax framework, what I propose is another page dedicated to Ajax libraries, wrapper, framework, and so one... This will include Sajax, and any open source similar program. It is not normal to link a library, and even create a page for it (I am speaking of Sajax) and refuse other ones. Booles 14:41, 28 March 2006 (UTC)

Having edited this article for months, a separate page for this is probably not a good idea. We have had numerous attempts to set up a Frameworks section as part of the external links, and they have quickly degenerated into link farms and had to be deleted outright. The problem is, there are dozens of frameworks being developed, and it becomes very difficult for anyone to differentiate which ones are actually notable, which ones are redundant, and which ones are actually being used. Rufous 15:27, 28 March 2006 (UTC)

This was just an idea :) Booles 19:03, 28 March 2006 (UTC)

An external link to a page about frameworks may be valuable providing there are revieved, compared, etc... Alcalazar 11:24, 13 April 2006 (UTC)

Proposal for a book section

I am never short of ideas :) On another page of the wiki, I would have created it directly, but this page is very hot! I prefer to take advices before to change anything. I propose to add a section beside tutorials, for documents that are more a reference than a tutorial. It may be entitled "Online books" or "Reference manuals". Tutorials are intended for teaching, and manuals to be consulted when we need an answer to a question. The links to Apple and IBM should enter this new category, even if the former is very short. Booles 19:03, 28 March 2006 (UTC)

since Ajax is a collection of technologies you can find reference for those technologies in the respective articles. For xmlhttprequest reference go to the xmlhttprequest article. I think the sections for tutorials and articles are very suited. --Sleepyhead 08:16, 29 March 2006 (UTC)

I have found a book section on PHP and Python pages. Alcalazar 12:03, 29 March 2006 (UTC)

I have just read the PHP page, it needs really more link deletion than this one! Booles 11:33, 30 March 2006 (UTC)

About spam

Several links to a website on the same page is spam.
A link to a website on several pages at Wikipedia is also spam. I suspect that the one that spams the wiki with lots of links anywhere to its webpage that is not even really useful, is also the one that removes links to other websites (and I have good reasons). I wonder also why a big company with billions dollars of cash needs for spamming this wiki. This is atonishing! Booles 12:18, 30 March 2006 (UTC)

AjaxPatterns.org Reference

Ajax Patterns keeps being added (sometimes by me, sometimes by others), and removed again, usually indiscriminately with several other references. What's everyone's take on it? It's basically the complete draft text to a book on Ajax, with topics ranging from basic Javascript/DOM stuff to advanced architectural concepts, as well as details on 100+ famework and library details. With all content under CC. Sems fairly appropriate as an external reference, I'd have thought. Mahemoff

I suppose all this stuff is already dispatched in various pages at Wikipedia, else let me know... Spankman 12:14, 12 April 2006 (UTC)

As someone who watches this topic closely, I can attest that Ajax Patterns is the most complete and authoritative single point of reference available on the topic of Ajax. If there were to be only one external site reference included in the Wikipedia Ajax entry, this is the link I would recommend. Brentashley 13:25, 12 April 2006 (UTC)

There are billions of external links but no useful information related to Ajax for me. Spankman 06:11, 13 April 2006 (UTC)

Where are these billions of external links? Most links are to original content inside the website. Mahemoff 11:12, 14 April 2006 (UTC)

According to the guidelines one must avoid to link to "Any site that contains factually inaccurate material or unverified original research". Spankman 10:46, 17 April 2006 (UTC)

Well, you've got me there. If you're not able to point me to the billions of external links, could you help me locate the factually inaccurate material or unverified original research? --86.134.165.11 10:20, 18 April 2006 (UTC)

You are funny. Since this is a wiki, the whole site is made by no matter who and it is clear there is not at Ajaxpattern enough people to verify all the pages and all the links. Spankman 12:11, 18 April 2006 (UTC)

Seriously, I have watched this website closely, and found nothing valuable about Ajax. There are articles that are out of topic and seem taken from other websites, and links, links, links, but no real work. Alcalazar 11:21, 13 April 2006 (UTC)

Alcalazar, can you please provide an example an article that is "out of topic" on Ajax Patterns? Also, did you look at the 70 chapter-length entries of original writing, or just the Ajax Links page, which is the only page I'm aware of that is essentially just only links. Mahemoff 11:12, 14 April 2006 (UTC)

AjaxPatters.org is one of the most comprehensive collection of resources about Ajax on the web that I have seen. I do think it is very useful for Ajax developers. But so are many other sites and portals about Ajax. The problem we have with this Ajax article is that people keep adding links to their own site - useful or not. So as we have seen in the past, the link list keep growing and growing. There are two issues with keeping this link. First of all the link section is divided in two: articles and tutorials. Ajaxpatters.org is a collection of both but the link is to the main site while all the other links are to specific articles. I am not saying that this sectioning is good - in fact it makes it makes the job of cutting the links down harder as there are many good Ajax articles and tutorials. Second; there are many other portals and sites with a collection of tutorials/articles. Shall we add this as well? --Sleepyhead 11:45, 14 April 2006 (UTC)

I believe we should keep here links to articles closely related to Ajax (XMLHttpRequest +JavaScript all together) because we can except lot of developments in the future using Ajax, and the size of this page will become virtually unlimited. Maybe we should create other pages to cover all subjects. Ajaxpatterns is not a tutorial actually and if a link is added here, put it at root of "External links" instead. Booles 12:28, 14 April 2006 (UTC)