Talk:Ajax (programming)/Archive 3

Archives
April 2005 – April 2006 May 2006 – July 2006

Proposed changes

Per the request for this article, I'm posting here some wording changes I want to make. If I don't get any constructive feedback, I'll go live with them in a few days. --71.131.70.115 17:12, 6 July 2006 (UTC)

Paragraph 2, first bullet

XHTML (or HTML) and CSS, for marking up and styling information.

• concur Artw 17:14, 6 July 2006 (UTC)

Paragraph 3, sentence 2 and 3

The iPhone, Apple, and Flickr examples feel like marketing. Aren't there better places for examples than this? If this is a good place, are these the best examples? Quadnine 17:50, 3 July 2007 (UTC)

Paragraph 8, first sentence

The Web development community, first collaborating via the Usenet newsgroup "microsoft.public.scripting.remote" and later through blog aggregation, subsequently developed a range of techniques for remote scripting in order to enable consistent results across different browsers.

• concur Artw 17:16, 6 July 2006 (UTC)

Section on "Interactivity", paragraph 1, sentence 1

Ajax applications execute mainly on the user's machine, by manipulating the current page within the browser using document object model methods.

• semi-concur - It scans better, but the like the current text is factually dodgy. To be AJAX there has to an exchange of data betwene the page and the server that doesn't require a page reload, however theres no reason why it needs to execute "mainly" at either end. Artw 17:32, 6 July 2006 (UTC)

How about: "Ajax applications reduce the burden on the remote server by moving processing of the page being viewed to the client computer." --Chris 16:24, 10 July 2006 (UTC)

I believe this is not entirely true. The processing of the display only is moved to client, not the whole page. Processing of data remain on the server (this is part of the page). Booles 09:56, 2 August 2006 (UTC)

Section on "Interactivity", paragraph 1, sentence 3

Generally only small requests need to be sent to the server, and relatively short responses are sent back.

• concur Artw 17:32, 6 July 2006 (UTC)

Section on "Interactivity", paragraph 1, sentence 4

This permits more responsive user interfaces due to the use of DHTML techniques.

• concur - could probably do with further decluncling though. Artw 17:33, 6 July 2006 (UTC)
  • 'decluncling' ? (Andywebby 11:22, 14 September 2007 (UTC))

Section on "Interactivity", paragraph 2

While the Ajax platform is more restricted than the Java platform, current Ajax applications effectively fill part of the niche first served by Java applets: extending the browser with lightweight mini-applications.

• concur Artw 17:34, 6 July 2006 (UTC)

Not need to compare AJAX with Java. AJAX may works with Java (or other languages/environments). Booles 09:58, 2 August 2006 (UTC)

Section on "Usability", paragraph 1, sentences 2 and 3 (combined)

The difference between returning to a previous state of the current, dynamically modified page versus going back to a previous static page might be a subtle one; but users generally expect that clicking the back button in web applications will move their browser to the last page it loaded, and in Ajax applications this might not be the case.

• concur Artw 17:34, 6 July 2006 (UTC)

Section on "Usability", paragraph 1, sentence 4

Developers have implemented various solutions to this problem, most of which revolve around creating or using invisible IFRAMEs to invoke changes that do not populate the history used by a browser's back button.aha... kollam..

• semi-concur - i;m not sure iframe based techniques for doing this are that common anymore. Artw 17:36, 6 July 2006 (UTC)

How about: "Developers have implemented various solutions to this problem. These solutions can involve using invisible IFRAMEs to invoke changes that do not populate the history used by a browser's back button. The IFRAME technique is regarded by some as outmoded. Although the World-Wide Web Consortium (W3C), a standards-setting body, has not formally deprecated IFRAME, it recommends the more general OBJECT instead." --Chris 16:24, 10 July 2006 (UTC)

I agree, I don't like iframes too much. Booles 09:59, 2 August 2006 (UTC)

I disagree. The alternatives are (wihout consorting to more complex and propritary alternatives) : IFRAME, IMG or the SCRIPT-tag. I do not see how OBJECT is a better solution in a real-world example. Besides, whether users on wikipedia like or dislike iframes is irrelevant. --Sleepyhead 10:14, 2 August 2006 (UTC)

timeouts session keep alive

Should there be something in disadvantages that discusses the difficulty of maintaing session keep alives/ timeouts with AJAX?

I believe that Ajax is here to remove timeouts, but perhaps I am wrong... Seriously, I don't know! Booles 09:52, 2 August 2006 (UTC)

I don't think so as session timeout is a general client/server issue and not specifically Ajax-related. Using Ajax will actually in many cases minimise the case of a session timeout as requests are sent more often to the server from the client. --Sleepyhead 10:16, 2 August 2006 (UTC) sdf sf sdf sd sd sd

After reading the article I was going to make this point too. afaik if something happens on the server side, it cannot be transmitted to the client without it being specifically requested by the client. This results in timeouts running constantly on the client side, and I consider it a limitation. —Preceding unsigned comment added by Zefram144 (talk • contribs) 17:02, 26 January 2008 (UTC)

Logo

I have removed the so-called unofficial logo from the article as being out of place. Besides, what technology needs a "logo"? --John Seward 08:04, 16 July 2006 (UTC)

I agree. Booles 09:53, 2 August 2006 (UTC)

Made the final two changes discussed earlier

Here they are FYI

Paragraph 9, sentence 2

• Was: "However, they are still used where wide compatibility, small implementation, or cross-site access is required."
• Is: "However, they are still used where compatibility with older Web sites or legacy applications is required."

Section on "Usability", paragraph 1, sentence 4

• Was: "Developers have implemented various solutions to this problem, most of which revolve around creating or using invisible IFRAMEs to invoke changes that populate the history used by a browser's back button."
• Is: "Developers have implemented various solutions to this problem. These solutions can involve using invisible IFRAMEs to invoke changes that do not populate the history used by a browser's back button. (The IFRAME technique is regarded by some as outmoded. Although the World Wide Web Consortium (W3C), a standards-setting body, has not formally deprecated IFRAME, it recommends the more general OBJECT instead.)"

External links

I added a a series of articles to the external links, but they got removed. There are actually very good articles, for both the beginner and the expert. They contain very interesting topics and they should really be here, having more the role of a tutorial than a simple article.

• Mastering Ajax, Part 1: Introduction to Ajax Article on IBM developerWorks
• Mastering Ajax, Part 2: Make asynchronous requests with JavaScript and Ajax Article on IBM developerWorks
• Mastering Ajax, Part 3: Advanced requests and responses in Ajax Article on IBM developerWorks
• Call SOAP Web services with Ajax, Part 1: Build the Web services client Article on IBM developerWorks
• Call SOAP Web services with Ajax, Part 2: Extend the Web services client Article on IBM developerWorks —Preceding unsigned comment added by Beradrian (talk • contribs) 13:40, 29 January 2008 (UTC)

I added a link directly to the references section because I had the impression nobody takes care of the discussion here. The link I sugesst for adding to the references section is http://en.pediax.de - this is a project (to which I contributed), which develops ideas for a user-interface for Wikipedia largely based on AJAX. It further enables visitors to geo-browse Wikipedia articles on a map. I think a link to Pediax would be really interesting for the readers of the "Ajax (programming)" article, since it exhibits Wikipedia with AJAX support. soeren 21:11, 15 January 2007 (UTC)

It's nice, but if we added thid it would open the way for adding other, similar links, and then the article would become a link farm. —The preceding unsigned comment was added by Artw (talk • contribs) 21:28, 15 January 2007 (UTC).

I'd like to suggest this two web site for External links:

• ajaxnetbeans.dev.java.net This is a project hosted by java.net, with different Ajax samples in NetBeans project ready, so that people can build and run the applications with minimum effort.
• Ajax Code Camp 10-Week Free AJAX Programming Online Course ( by Sang Shin, Sun Technology architect, consultant, and evangelist )

That's all Thanks

I've added the following links to the External links section. They're keynote addresses from the Ajax Experience in Fall 2006.

• Video - Firefox 2 and Javascript with Mozilla Corp's Brendan Eich
• Video - The Once and Future Web with Microsoft's Chris Wilson
• Video - Towards a Service Oriented Stack with TIBCO's Kevin Hackman

I notice that the Links section has been commented out for a pending review. I am not sure where may I see/contribute to this review, but I would like to point out that the inline references used in the main article (now encapsulated under the References section) should be placed under the same scrutiny as well. --Pkchan 10:51, 21 July 2006 (UTC)

I don't think any formal review is necessary for the external links we have now. They have survived peer review for months. Sugarskane initiated this review after things didn't go his way, but it's nothing personal. We have been over this time and time again: if we start listing Ajax libraries it quickly degenerates into a spamming match. It has happened many times before, until we just started deleting them all outright. Personally I quite like the idea of Feather Ajax, but a link directly from the article is not the right place to put it. Rufous 15:11, 21 July 2006 (UTC)

Just because something's been listed for months doesn't mean that it complies with the general policy for the article. Currently there is an external link to the Open Directory project -- I think this should stay. As for the other links, however, I think we DO need to bring some scrutiny. An argument of "That's how it's always been" is not valid -- if it was, we'd still have slavery and women wouldn't be voting. Please use your best judgment, rather than historical presidence, in deciding whether a link should stay. The following is my humble opinion of what's currently posted:

• Reference links 1-4 are extremely good sources/references -- they aren't personal pages, and are exactly the type of source that one would expect in an encyclopedia
• Reference link #5 (Remote Scripting with AJAX, Part 2) has no practical purpose for being listed as a reference. This should be removed.
• Reference link #6 (Listen kids, AJAX is not cool) has NO business being listed as a reference. It doesn't comply with the typical criteria for being a reference. This should be removed.
• External link #1 (Open Directory) - This is a great way to send people off to a series of links related to Ajax without cluttering up the page. Keep this!
• Articles - Any of the articles, with the exception of the first two by Jesse James Garrett (creator of Ajax), should be removed. Articles by Garrett have historical value. The other articles are more like external links, and are no different than the hundreds of external links that have been removed from the article in the past.
• Tutorials - The Mozilla should stay because it's a tutorial from the horse's mouth. If this were an article on ASP.NET, for example, I would say that anything by Microsoft should be added. Although Mozilla didn't come up with Ajax, it programmed it into its web browser. I would also add that any articles from Opera or Microsoft should be added, if applicable. Other than that, however, it is unfair to keep the two other tutorial articles. Either you add all the tutorials people want to add, or you stick to your guns and only add direct links to pages/companies that have programmed the infrastructure for Ajax.

--Sugarskane 17:07, 31 July 2006 (UTC)

I agree that links should be always under scrutiny. The relevant guideline for external links is WP:EL and according to my reading:

• The Open Directory Project listing should be kept as an appropriate web directory to this article. Its being open is a plus.
• The Garrett articles should also be kept, not merely as external link but as references to be cited at appropriate places in the article's main body, to back up his original point of view.
• This article: http://www.ajaxinfo.com/default~viewart~8.htm Weighing the Alternatives - How Ajax stacks up against competing RIA approaches is the textbook example of what "does not provide a unique resource beyond what the article here would have once it becomes an example of brilliant prose", and should be removed.
• These two: http://www.softwaresecretweapons.com/jspwiki/Wiki.jsp?page=JavascriptRefactoringForSaferFasterBetterAJAX JavaScript refactoring for safer, faster, better Ajax and http://www.sitepoint.com/article/ajax-screenreaders-work Techniques to allow screen readers to read off dynamically added content are how-tos, which Wikipedia is not. I see no reason to keep them, so I'll remove them unless someone is going to convince us otherwise.

As for the Tutorials, I would take an even bolder position: it's not Wikipedia's job to recommend any tutorial to the reader. It appears a bit too far-stretched to me to establish that Mozilla should make a better reference than everyone else as they do not hold exclusivity to this technology umbrella. As there does not exist any guideline for us to judge which tutorial to include and which not to (even though if Mozilla would win clearly if judged solely on fame, as fame is not the right measurement here), I would suggest to remove all. But I am open to all other editors' comment on this as well.

As for the cited references, they are not covered by WP:EL but instead WP:RS, which is less clear-cut a guideline than the former. As I see it, link [5] (http://www.xml.com/pub/a/2005/08/22/ajax.html) is not a direct reference on the point of clear feedback to user as it only covers this topic tangentially. However in the absence of a better one this seems the best we can cite for this particular point, so that makes a marginal keep for me unless and until we find a better source as support. Link [6] (http://www.lastcraft.com/blog/index.php?p=19) is a self-published sources and does not fall within WP:RS as an acceptable source, so I'm going to remove that. The rest are all reliable sources and should be kept. --Pkchan 14:47, 1 August 2006 (UTC)

I've changed my mind regarding the second Garrett article (http://www.ok-cancel.com/archives/article/2005/09/why-ajax-matters-now.html) and have removed it: it offers nothing special to be included here. Not every article written on this topic by the person who coined this phrase is relevant here. --Pkchan 15:27, 1 August 2006 (UTC)

I agree that the tutorials section does not have a place in the article -- users can access relevant tutorials through the Open Directory link. The Mozilla tutorial was the only one I'd considered keeping -- but I think that Pkchan's argument is effective enough to warrant the removal of all the tutorial links. --Sugarskane 16:55, 1 August 2006 (UTC)

I would like to nominate http://ajax-tutorials.com as a replacement for Ajax:Getting Started by Mozilla Developer Center and "Building an Ajax page with get, post, text, XML example" in the Ajax Tutorials section.

Why to replace?

Because, those two tutorials force people to believe that they have to write the bunch of low-level script with direct access to the XMLHttpRequest in order to have an Ajax functionality in their own web applications. However, it is not true. It is even not close to truth today. It sounds sooooo 2005ish. Think about it! One and a half year brought the valuable solutions that make life much easy and allows to concentrate on the real business problems, but not on the low-level Javascript programming.

The nominated resource is a completely independent from any particular vender web site exclusively dedicated to the theme of ajax tutorials and presents the wide spectrum of helpful tutorials (no room for blah, blah, blah articles). Currently, ajax-tutorials.com contains more them 130 links to the existing tutorials and updated on the daily bases.

I believe, the readers need to have an access to such up-to-date information.

--Alexa White 05:59, 18 October 2006 (UTC)

External links are here to avoid users to search documents at Dmoz. The articles of Garrett, etc... are also on Dmoz! This is a very poor argument to remove links. I request revocation of your edit and for restoring the previous links, because users need for them. Booles 09:38, 2 August 2006 (UTC)

Sugarskan, previously, has attempted to add a link to its own website: not the person to speak of spam! But the discussion is opened, please, wait for users to say if they want these links of not. If a lot of users is against the links, remove them. Booles 09:47, 2 August 2006 (UTC)

Links restored (save the first Garrett article, which is now referenced at the References section) pending further discussion here. I am more than happy to allow the links stay at the article for a couple of days to allow a more elaborated discussion, though I'd expect that a resolution would have been made by then.

I would like to note, however, that any discussion here should revolve around WP:EL and WP:RS. I would be more than happy to listen to your view as to whether my interpretation above is correct or not, but I am afraid it won't be helpful if our discussion here travel out of the scope of WP:EL and WP:RS. In particular, I do not find the argument that the links are "users need them" is convincing enough to keep them: you may find one link useful but another user may find it rubbish. The guideline we should follow is WP:EL, according to which a link should be added if it adds something that it is difficult for the present article to include.

And please also assume good faith while discussing. --Pkchan 11:23, 2 August 2006 (UTC)

Our Ajax article, as it stands, is a very strong article describing what Ajax is, its history, pros and cons. What it does not include (nor should it include) is a description of how to implement Ajax. This is exactly why we should link to a few strong tutorials at the end of the article. This falls under WP:EL, “Sites with other meaningful, relevant content that is not suitable for inclusion in an article, such as textbooks.” — i.e. implementation instructions.

The dmoz link is peppered with links to Ajax frameworks, with little or no educational value, which we've tried and succeeded — over the course of many months and hundreds of edits — to keep out of the article. It is a useful inclusion to resolve disputes, but not nearly as useful as directly including good tutorials ourselves. I've been actively editing this page for a long time, and the tutorial collection we have come to agreement on has taken a long time to be decided on. They should remain as part of the article. Rufous 11:56, 2 August 2006 (UTC)

I don't think the Sarissa library link should be kept due to the total volume of Ajax libraries available. It does not seem right to add one link, but refuse "hudreds" of others -- it's a slippery slope either way. If Sarissa is kept, then you should allow the addition of additional libraries -- which would be far too numerous, and would make the article a collection of links. Conversely, if Sarissa is removed, then no users will be able to access Ajax libraries from the Ajax page. Would anyone consider a stub on Ajax libraries? Because Wikipedia is a repository of content, not links, and the Sarissa link shows favoritism toward one single library, I don't think the Sarissa link should be kept. As for the 'Building an Ajax Page', I still see this as a tutorial that is no different than the hundreds of other tutorials on the internet. Why is this one so special that it receives the sole spot on the article? Again, Wikipedia isn't a place to store links, and while it may be helpful, I think it is silly of the editors of the article to 'outlaw' any other tutorial links aside from this one. I still argue that they both should be removed. --Sugarskane 15:54, 2 August 2006 (UTC)

The point of the link discussing the use of Sarissa is not to recommend Sarissa over any other libraries, so please do not characterise it as such. Each of the libraries available have their benefits and issues. It is not favouritism, as other leading libraries are listed in the tutorial. The mention of Sarissa in the link description was not in the spirit of the article though, so I have amended it to say it is discussing a generic “JavaScript library.” We need a tutorial that discusses the use of a library to create cross-browser Ajax without the user writing the code branching code themselves, and this tutorial runs through the design and implementation of a form submission script that does just that. Also, cf. Ajax framework. Rufous 16:31, 2 August 2006 (UTC)

I'd agree that this article can do with a few tutorial links. The problem is, what are the criteria for including a link and excluding others (because for obvious reason we can't include all relevant tutorials here). This is not only an editorial issue but also an issue of fairness and transparency, as Wikipedia is a high-traffic website and any link on this article is bound to generate quite an amount of traffic, and we have the responsibility to act fairly to the Ajax tutorials all over the world.

Would you please point to us those previous discussions which lead the Tutorial section to its current state? (I skimmed through the talk archives but didn't find much relevant discussion) Perhaps we can summarise the past criteria applied so that we can use such criteria to judge whether to include a tutorial link or not in the future and make this more transparent (by inserting in at the relevant section of the article as hidden text). --Pkchan 18:46, 2 August 2006 (UTC)

What other leading libraries are listed? Within the article, ARSCIF is listed -- but I can find no other libraries. The Sarissa/Javascript link should be moved to the Ajax Framework article -- it doesn't belong here if you are so insistent about removing 'hundreds' of other links. Judging by the history of the edits, it seems that when a tutorial or library is added, it is promptly removed (usually) without much discussion. Just because you want a short list of external links doesn't mean that any of the removed links shouldn't be listed, and just because you've been editing the article for so long doesn't mean you have ownership of the external links section, or the article itself. Can you point to the relevant discussion that Pkchan is asking for? The Mozilla link is just as informative as the http://www.xul.fr/en-xml-ajax.html link -- why are we including both? The "Sarissa" link isn't even the official Sarissa website! Sarissa belong in the Ajax Framework article -- you aren't learning Ajax if you are using a library -- you'd be learning how to use a prebuilt library. I still vote to remove all but Mozilla. --Sugarskane 17:47, 3 August 2006 (UTC)

Rufous, I now understand why you've been holding onto the external links section with such fervor. Upon closer examination of your User page, it appears that your name is 'Ross Shannon'. That wouldn't, by any chance, be the same Ross Shannon listed at the very botton of the Cross-browser XMLHttpRequest Tutorial link, would it? I bet that's really giving you a lot of traffic. Due to neutrality concerns via WP:EL ("A website that you own or maintain, even if the guidelines above imply that it should be linked to."), I'm removing your link. You're more than welcome to look at my long discussion with this, as I too added an external link to my page. There are clearly more notable and significant articles on Ajax (the Mozilla link). I suggest you either release your vulcan death grip from the Ajax external links section, or you follow the rules you've been enforcing and leave your page off the EL section. --Sugarskane 17:56, 3 August 2006 (UTC)

There being no discussion on the external links under the "articles" sub-heading I have now removed them for the reasons stated above. It is possible to re-add the two how-to articles under the "tutorial" sub-heading, provided that we have come up with some plausible criteria on what to include/exclude there. --Pkchan 15:28, 6 August 2006 (UTC)

Please see my comments earlier in this thread, I feel they are cogent. I sincerely believe that we need good instructional tutorials on implementing Ajax in a practical manner — which means using a library to abstract away the browser compatibility problems. People come here to learn what Ajax is, but also how they can implement it themselves. As I said, tutorials like this clearly fall under WP:EL.

If another editor thinks they have found a tutorial better than this tutorial (which I wrote) for this purpose, then they should add it to the article. I have continually edited my tutorial so that it is — I feel — the best of its kind. It goes through the creation of a form submission script from scratch (one which works when JavaScript is disabled too). I will not add my tutorial to the article myself, but I ask my fellow editors to read it and restore it to the article if they find it relevant and informative. Rufous 23:54, 7 August 2006 (UTC)

I propose to add an external link to developerWorks Ajax Resource center which provides a complete Ajax Resource repository with features articles, blogs, tutorials and forums.This will also conform to WP:EL guidelines as it contains levels of detail which is not appropriate for Wikipedia. I will wait till Nov 8th for soliciting comments. I request people to evaluate the website and provide their feedback on whether it is ideal for this article. I strongly feel it deserves to be here.Mehraj 14.45, 3 November 2006

Security section under "Cons"

Should this section just be entirely removed? I buy the samy worm as an example of a worm that happens to use AJAX, but that seems to be all it is - Samy seems more like an exploit of secutrity flaws in MySpace and in browser handling of Javascript that an AJAX specific worm.

Anyone have any information to the contrary? Artw 18:50, 5 August 2006 (UTC)

The cited comment about the "surface" of attack that AJAX enables is interesting, but I've no idea where that citation comes from. As for the rest of it, I think it's bunk and misguided. AJAX hasn't given hackers anything new that they didn't have before: given JavaScript and HTTP GET you could do everything that the Samy worm did, years ago. It just gives hackers some new ways of doing old things. I mean, the only innovation (and it's not a small one, don't get me wrong) that AJAX brings is the ability to have server interaction without page reloads. That's it. Saying AJAX causes new security holes in sites is like saying a new brand-name of crowbars causes new security holes in cars. — Saxifrage ✎ 00:40, 6 August 2006 (UTC)

Whenever you increase the "surface" area of code that handles network access, you are more likely to have security problems and/or bugs in this area; that is straightforward enough. The quote is probably from this article: http://www.technewsworld.com/rsstory/52233.html (the Samy worm is mentioned in there as well).--68.238.68.229 09:55, 6 August 2006 (UTC)

I don't think it's right to delete a whole sub-section[1] just because the quote was un-referenced. The quote is reported on http://news.yahoo.com/s/usatoday/20060804/tc_usatoday/cybercrooksaddajaxcodingtobagofhackingtricks

and possibly elsewhere. It is certainly being reported that this attack was in some way related to AJAX, and I think that is a fact worth recording in the article, regardless of ppl's POV. --Nigelj 20:08, 7 August 2006 (UTC)

I agree with Saxifrage, anon and Nigelj that there is something here worth preserving - I find "surface area" concept interesting. Also with Artw that this is an insecurity that just happens to be Ajax. I'd like to see a section on security, and for it to mention that the complexity allowed in Ajax means that security loopholes can be hard to spot, or something like that. Stephen B Streater 20:19, 7 August 2006 (UTC)

I can see that sort of stuff being useful for the article. Most importantly, though, we need external sources that have already written these things about AJAX, since Wikipedia doesn't publish its editor's original research on subjects. — Saxifrage ✎ 20:49, 7 August 2006 (UTC)

The trouble with that Yahoo article is that it doesn't talk about security holes in AJAX, just that "AJAX can be used to do bad things". This isn't really an exceptional statement, as many things can and have been used to do "bad things". Looking up the two worms cited in the article, it appears the security problems were actually in Yahoo Mail and MySpace, and AJAX was just the tool used to exploit those holes. Like I said about, that's like saying HTTP GET has security issues because it has been used to exploit bugs in Yahoo Mail, or that a browser has security holes because it can be used to exploit security holes in broken web services. Certainly there are people who think AJAX presents new problems, but the article doesn't actually show that their beliefs are true. The only "security holes" in AJAX are the ones it inherets from JavaScript, the browser's implementation thereof, and the website in question. If they didn't have holes, neither would AJAX have "holes". — Saxifrage ✎ 00:36, 8 August 2006 (UTC)

Decentralization as a discussed advantage of Ajax

Previously, I had added a section discussing one of the advantages of Ajax which has helped to make it a popular technology. My contribution may not yet be brilliant prose, and might require citations in a few choice locations or massaging, but I would like to discuss it

BRD is optional, but complying with Wikipedia:Editing policy § Talking and editing and Wikipedia:Edit war is mandatory.

The BOLD, revert, discuss cycle (BRD) is one of many optional strategies that editors may use to seek consensus. This process is not mandated by Wikipedia policy, but it can be useful for identifying objections, keeping discussion moving forward and helping to break deadlocks. In other situations, you may have better success with alternatives to this approach. Care and diplomacy should be exercised. Some editors will see any reversion as a challenge, so be considerate and patient.

Bold editing is a fundamental principle of Wikipedia. All editors are welcome to make positive contributions. It's how new information is added to Wikipedia. When in doubt, edit! Either the edit will get the attention of interested editors, or you will simply improve the page. Either is a good outcome.

Revert an edit if you disagree with it and cannot immediately refine it. If you revert, be specific about your reasons in the edit summary or on the talk page. BRD does not encourage reverting, but recognizes that reversions happen. Revert only when necessary.

Discuss your bold edit with the person who reverted you. To follow BRD specifically, instead of one of the many alternatives, don't restore your bold edit, don't make a different edit to this part of the page, don't engage in back-and-forth reverting, and don't start any of the larger dispute resolution processes. Talk to that one person until the two of you have reached an agreement.

Cycle. To avoid bogging down in discussion, when you have a better understanding of the reverter's concerns, you may attempt a new edit that reasonably addresses some aspect of those concerns. You can try this even if the discussion has not reached an explicit conclusion, but be sure to avoid engaging in any kind of edit warring.

General overview

It is often hard to find out who to talk with to gain consensus. By making a bold edit you attract the attention of people who are genuinely interested in a page, and have it on their watchlist. You can then discuss your issues with them. Compare Wikipedia:Consensus.

When to use

While editing a particular page that many editors are discussing with little to no progress being made, or when an editor's concerns are not addressed on the talk page after a reasonable amount of effort.

How to proceed

Find an interested person, and reach a compromise or consensus with that person, in one-on-one discussion.

1. Be bold, and make what you currently believe to be the optimal changes based on your best effort. Your change might involve re-writing, rearranging, adding or removing information.
2. Wait until someone reverts your edit. You have now discovered your first VIP.
3. Discuss the changes you would like to make with this VIP, perhaps using other forms of Wikipedia dispute resolution as needed, and reach an agreement. Apply your agreement. When reverts have stopped, you are done.

Use cases

Consensus is stuck. BRD to the rescue!

BRD is most useful for pages where seeking and achieving consensus in advance of the bold edit could be difficult, perhaps because it is not clear which other editors are watching or sufficiently interested in the page, though there are other suitable methods. BRD helps editors who have a good grasp of a subject to rapidly engage discussion.

Examples cases for use include where:

• Two factions are engaged in an edit war and a bold edit is made as a compromise or middle ground.
• Discussion has died out with no agreement being reached.
• Active discussion is not producing results.
• Your view differs significantly from a rough consensus on an emotionally loaded subject.
• Local consensus is currently opposed to making any changes whatsoever (when pages are frozen, "policy", or high-profile)

BRD is best used by experienced Wikipedia editors. It may require more diplomacy and skill to use successfully than other methods, and has more potential for failure. Using BRD in volatile situations is discouraged.

In general, BRD fails if:

• ...there is consensus in the community against the specific change you'd like to make.
• ...there is a dispute on the page, by editors with entrenched positions, and you are reigniting a debate that has achieved stalemate without consensus.
• ...the page is protected. (You may request unprotection.)
• ...the page is subject to some other access control. (Get the control lifted.)
• ...you lose tempo.
• ...a single editor is reverting changes and exhibiting other forms of ownership attitudes.
• ...individuals revert bold changes but aren't willing to discuss improvements to the page.
• ...the individual who reverts the bold change actually supports it, but is reverting as a proxy for some other, unidentified person.

BRD is especially successful where:

• ... people haven't really thought things through yet.
• ... people are only discussing policy or theory, and are not applying reasoning or trying to negotiate consensus.
• ... people are talking past each other instead of getting down to brass tacks with concrete proposals.

In short: boldly negotiate where no one has negotiated before.

What BRD is not

• BRD is not a justification for imposing one's own view or for tendentious editing.
• BRD is not a valid excuse for reverting good-faith efforts to improve a page simply because you don't like the changes.
• BRD is never a reason for reverting. Unless the reversion is supported by policies, guidelines or common sense, the reversion is not part of BRD cycle.
• BRD is not an excuse to revert any change more than once. This applies equally to bold editors and to reverters. If your reversion is met with another bold effort, then you should consider discussing instead of reverting. The talk page is open to all editors, not just bold ones. The first person to start a discussion is the person who is best following BRD.
• BRD is not mandatory. Neither are editors obliged to start it nor are they obliged to stick to it just because you started it. They may try one of the alternatives given below, or even an alternative not mentioned here.
• BRD is not a valid course of action when using advanced permissions. Editors with permissions such as administrator or template editor can take actions which few editors are able to revert if they disagree, preventing the R step of BRD.

Process

Making bold edits may sometimes draw a response from an interested editor, who may have the article on their watchlist. If no one responds, you have the silent consensus to continue editing. If your edit is reverted, the BRD cycle has been initiated by the reverting editor.

After someone reverts your change, thus taking a stand for the existing version or against the change, you can proceed toward a consensus with the challenging editor through discussion on a talk page. While discussing the disputed content, neither editor should revert or change the content being discussed until a compromise or consensus is reached. Each pass through the cycle may find a new, interested editor to work with, or new issue being disputed. If you follow the process as it is intended each time, you should eventually achieve consensus with all parties. As such, BRD is in general not an end unto itself; it moves the process past a blockage, and helps people get back to cooperative editing.

If the BRD process works ideally (sometimes it does not), people will after a time begin to refrain from outright reversion, and edits will start to flow more naturally.

For each step in the cycle, here are some points to remember.

Bold

• Stay focused: Make only changes you absolutely need to. A bold edit doesn't have to be a huge edit, and keeping your edit focused is more likely to yield results than making an over-reaching change. If a bold edit might be controversial, consider adding "(revert if inappropriate)" or similar to the edit summary to alert others.
• See what happens next: Stop editing the page long enough to see if anyone objects. Depending on the nature of your change and the traffic on the page, this may take anywhere from mere minutes to more than a week.
• Expect resistance—even hostility: Be ready to start a discussion as soon as you notice that anyone has objected. If you want, you can even write your response while you are waiting to see what happens.
• Be respectful: Regardless of what others say, keep your composure.

Revert

• Before reverting, first consider whether the original text could have been better improved in a different way or if part of the edit can be fixed to WP:PRESERVE some of the edit, and whether you would like to make that bold edit instead. Partial reversion, WP:PARTR, is better than complete reversion. The other disputant may respond with another bold edit, or with a refinement on your improvement. The "WP:Bold-refine" process is the ideal collaborative editing cycle. Improving pages through collaborative editing is ideal. However, if you find yourself making reversions or near-reversions, then stop editing and move to the next stage, "Discuss".
• Before reverting a change to an article in the absence of explicit consensus, be sure you actually have a disagreement with the content of the bold edit (and can express that disagreement), not merely a concern that someone else might disagree with the edit. A revert needs to present a path forward, either by expressing a concern with the content of the edit itself, or pointing to a previous discussion that did.
• In the edit summary of your revert, briefly explain why you reverted. You can encourage the bold editor to start a discussion on the article talk page if they want to learn more about why you reverted. Alternatively, start a discussion yourself on the article talk page about the issue. People feel more cooperative if you let them know that you're willing to listen to their case for the change. Otherwise, a revert can seem brusque.
• If you revert twice, then you are no longer following the BRD cycle: If your reversion is reverted, then there may be a good reason for it. Go to the talk page to learn why you were reverted.
• If people start making non-revert changes again, you are done: The normal editing cycle has been restored.

Discuss

• If your bold edit was reverted, then do not re-revert to your version. If your reversion was reverted, then do not re-revert to your version. Instead, take it to the talk page (see below). If you re-revert, then you are no longer following BRD.
• Adhere to Wikiquette and civility guidelines: The easiest way to intensify this cycle and make it unbreakable is to be uncivil. Try to lead by example and keep your partner in the same mindset.
• Talk with one or at most two partners at once. As long as the discussion is moving forward, do not feel the need to respond to everyone, as this increases the chance of discussion losing focus and going far afield. Stay on point and pick your responses. If discussion dies off, you can always go back and get yourself reverted again to find (or refind) other interested parties.
• Carefully consider whether "policy", "consensus", or "procedure" are valid reasons for the revert: These sometimes get overused on consensus-based wikis even though consensus can change. On the other hand, repeatedly rehashing old arguments without new reasoning might strike some editors as being disruptive (see also rehashing). It is OK to disagree with a past consensus, but use reasonable discretion when you want to revisit such issues. If you choose not to back off immediately, it will help if you:
  • Listen very carefully: You are trying to get the full and considered views of those who care enough to disagree with your edit. If you do not listen and do not try to find consensus, you are wasting everyone's time. You should not accept "It's policy, live with it."
  • Be ready to compromise: If you browbeat someone into accepting your changes, you are not building consensus, you are making enemies. This cycle is designed to highlight strongly opposing positions, so if you want to get changes to stick both sides will have to bend, possibly even bow. You should be clear about when you are compromising and should expect others to compromise in return, but do not expect it to be exactly even.
• Discuss on a talk page: Don't assume that a re-revert edit summary can constitute "discussion": There is no way for others to respond without risking an edit war. See also WP:QUO. You can use the article's talk page (preferred) or the editor's user talk page, or invite the editor to the talk page if they insist on using only edit summaries, but one or the other is the proper forum for the discussion component of the BRD cycle.

Bold (again)

• Let the other editor apply agreed-upon changes. If they don't want to, that's okay, but be sure to offer. The offer alone shows deference and respect. If that editor accepts, (1) the history will show who made the change and the other editor will have control over the precise wording (keeping you from applying a change different from the one agreed upon). And, (2) such a practice prevents you from falling afoul of the three-revert rule.
• Assume this revision will not be the final version. You do not have to get it all done in one edit. If you can find consensus on some parts, make those changes, and let them settle. This will give everyone a new point to build from. Having completed one successful cycle, you may also find it easier to get traction for further changes, or you may find you have reached a reasonable compromise and can stop.

Edit warring

"WP:BRR" redirects here. Previously it redirected to WP:Desserts.

• Do not edit war. Once discussion has begun, restoring one's original edit without taking other users' concerns into account may be seen as disruptive. These so-called "re-reverts" are uncollaborative and could incur sanctions such as a block. The objective is to seek consensus, not force one's own will upon other editors. If you encounter several reverts, it is best not to escalate the situation by reverting again. Instead, try to build consensus through seeking additional input. Several methods for this are listed at Wikipedia:Dispute resolution.
• However, don't get stuck on the discussion. Whichever side you happen to be on, try to move the discussion towards consensus by getting pro/con points identified so that a new edit may be attempted as quickly as possible. Feel free to try a new bold edit during the discussion if the new edit reasonably reflects some aspect of the opposing editors' concerns. This approach quickly determines whether the important issues have been resolved; if not, it brings the core sticking points into focus.
  • Warning: Repeatedly doing this can easily violate the 3RR policy and get good-faith editors blocked even during a productive editing exchange. Any such edits must be clear attempts to try a modified solution that reflects some aspect of the other editor's remarks. If you have reached three reverts within a 24-hour period (3RR bright-line rule), do not edit that content in any manner that reverts any content, in whole or in part, even as little as a single word, for over 24 hours. Doing so just past the 24-hour period could be seen as gaming the system and sanctions may still be applied.

Additional considerations

• Because of the nature of Wikipedia, a BRD cycle may begin naturally, without either editor even realizing it. Once begun, its purpose requires that no reversion be counter-reverted. If this happens, something akin to stalling an aircraft happens. If you're not feeling up to it, it might be best to walk away for a while. Unlike the immediate danger of an aircraft plummeting to the ground, Wikipedia will be here a long while, so you can always come back later. Otherwise, if you have the energy and the time, use the suggestions on this page to "pull out". Then continue working as per consensus.
• BRD is a way of letting you focus on one editor: You cared enough about the page to try to improve it, someone else cared enough to revert your bold change, and you both cared enough to find a compromise through discussion. This is an excellent collaborative style. But there may be other editors interested in that page, so a third editor might revert your compromise, or might revert your next attempt to improve it. If so, that's okay: You can repeat the BRD cycle with that third editor. Just start a new discussion, and find a new compromise.

Alternatives

"BOLD, revert, discuss" doesn't work well in all situations. It is ideally suited to disputes that involve only a few people, all of whom are interested in making progress. There are many other options, and some may be more suitable for other situations.

• Discuss first: Don't be bold with potentially controversial changes; instead, start a discussion on the talk page first. Make no edits to the page until you have agreement.
• Bold, discuss: You do not need to revert an edit before the discussion can start. If you see (or make) a bold edit and you want to talk about it, then you can click on the talk page and start discussing it. You might discover ways to refine it, or you might discover that you're satisfied with the edit as it is.
• Bold, discuss, revert: You make a bold edit, then open a discussion. The edit is found to be problematic or lacking, so it is reverted. This sometimes happens when people attempt to make an edit that has severe flaws or problems that cannot be resolved via other methods. If this cycle happens, it might be best for you to step away from the article, and consider the discussion feedback.
• Bold, discuss, bold: You make a bold edit, then open a discussion. After the discussion, you or others boldly improve the edit based on the discussion suggestions. This cycle is useful if your edit is helpful, but needs to be improved, and if feedback would be valuable to improving the edit.
• Bold, refine: You edit, they edit, you edit again, with each edit improving the prior edit. This is successful, collaborative editing. Keep at it.
• Bold, revert, bold again: Don't stop editing, and don't discuss. Make a guess about why the reverter disagreed with you, and try a different edit to see whether that will be accepted. It's often helpful if your next effort is smaller, because that may help you figure out why the other editor objected to your change.

• Bold, revert, revert: If you genuinely believe the reversion was a mistake you might try speeding things up by reverting the revert, but you should explain why you think the other editor made a mistake in a note or edit summary to reduce the risk of edit warring.
  • An example of such a mistake is when someone reverts your removal of duplicate material because they didn't realize that the same sentence was on the page twice.
  • Not an example of such a mistake: A revert with a rationale that you disagree with, or that does not make sense to you. Another case where the re-revert may be necessary is when an incumbent editor reverts without justification in the edit summary, which is a form WP:Status quo stonewalling. But see WP:QUO.
  • Sometimes bold, revert, revert may function as a form of bold, refine (see above), particularly among editors who already have a positive working relationship. Beware, though: To an outside observer, such "friendly reverts" may not be readily distinguishable from edit-warring, and the three-revert rule still applies.
• Let it go: Move on to another article. You might be able to improve a hundred articles in the time that it takes you to discuss this one. Why not move on?

Several dispute resolution processes may also be useful to break a deadlock.

See also

• Wikipedia:Method for consensus building
• Wikipedia:Short BRD
• Negotiation
• Wikipedia:Editing policy § Try to fix problems

. Do you feel this bullet point can be refined to meet your expectations, and if so what should I do? Or if not, please tell me why you feel the point is unsalvageable? Thank you. Jesset77 23:23, 16 August 2006 (UTC)

Now that end-user machines are becoming more powerful and bandwidth is becoming more plentiful, a web application server will have a more difficult task time-sharing between a large number of clients. To save resource costs, it may behoove web service operators to use Ajax to export much of the workload directly to the clients themselves. Workload performed by one client fails to distract the service provider from answering the queries of other clients, and also helps bring to bear computing resources that the client may otherwise be underutilizing.

Merged Desktops

I've merged the article 'Ajax Desktops' in here as it seems unneccessary to keep them separate. I added the external link from that page into here, however I've noticed your note on additions so to carry over the information rather than make a statement as to whether it should be there or not. Cheers. Orchid Righteous 12:03, 23 August 2006 (UTC)

I don't think this merge should have been implemented. Whether or not Ajax desktops are encyclopedic is another discussion, but for now I don't think they are at all relevant to an article about the technology itself. Please reconsider. Rufous 16:17, 23 August 2006 (UTC)

Ugh, No. It's basically a "sites that use AJAX" section, and as such I'm deleting it. Artw 19:10, 23 August 2006 (UTC)

Good call. --Sleepyhead 19:37, 23 August 2006 (UTC)

Was obvious spam. Other topic: I wonder why you have added twice the article of J. J. Garrett. Booles 12:05, 25 August 2006 (UTC)

Good article

I've passed this article as a good article - nice work! A couple of things, though:

• I had a little bit of trouble relating some of the info in the History section to the Ajax concept, particularly "Remote Scripting Frameworks such as ARSCIF[5] surfaced in 2003 not long before Microsoft introduced Callbacks in ASP.NET[6]." A couple more sentences in this section wouldn't go amiss.
• The pros and (especially) cons sections are missing references. I know there's not a lot of stuff to reference, but something like "This is possible because many browsers allow JavaScript to update the fragment identifier of the URL dynamically" would be easy enough to find a source for.
• It's a little weird to say that Ajax means "Asynchronous Javascript and XML" and then say that XML is optional. I'd probably prefer it if it was mentioned in the same list as XHTML, DOM and XMLHttpRequest; but I'm not overly bothered by it.

Apart from those, this is a really good article - a great introduction to Ajax. Nice work! --james^(talk) 13:21, 26 August 2006 (UTC)

Ajax Mobile

Some mention needs to be made of Ajax used on mobile phones. Microbrowser mentions ajax, for example. http://ajax.phpmagazine.net/ajax_mobile/ Mathiastck 21:53, 7 September 2006 (UTC)

• Why? Artw 22:50, 7 September 2006 (UTC)

Ajax mobile seems notable to me, (admittely anything mobile seems more notable to me then the average user). Still, I think such info would best belong here, rather then as it's own article. Mathiastck 18:25, 12 September 2006 (UTC)

I guess I jumped the gun on mobile ajax, the mobile world was all abuzz about it, but it hadn't happened yet. It has happened now, witht he Opera browser.

http://www.russellbeattie.com/notebook/1008690.html Mathiastck 06:59, 18 September 2006 (UTC)

Implementations of AJAX

I feel it would be useful to give some links to specific implementation of AJAX. Specifically ATLAS which is Microsofts implementation of AJAX. Any thoughts?

--12.10.219.36 18:26, 15 September 2006 (UTC) Mark

Look here.
Booles 09:46, 16 September 2006 (UTC)

Probably bets to keep any mentions of specidfic frameworks or libraries out of the main article as it would lead to everyone trying to get their favoured one as the lead example. Artw 17:57, 16 September 2006 (UTC)

As mentioend above, opera implemented AJAX in their mobile browser, with various widgets. Mathiastck 07:00, 18 September 2006 (UTC)

Possible addition to External Links

Hi reviewers, when you get time please consider whether the following links would be useful if added to External Links. I may not add them because I maintain one of the sites. I was one of the instructors for the summer course at Univ of Penn and these pages were created for that course. They consist of very simple Ajax code samples (server and client side) and a few book reviews: | Ajax code samples | Ajax book reviews, and they also link to the course Wiki which has other useful, related information. Harborsparrow 08:15, 1 October 2006 (UTC)

The JavaScript widgets exaple looks very well, but this is JavaScript not Ajax, should be linked to the JavaScript page. The book is just an advertisement. Booles 12:17, 5 October 2006 (UTC)

I wish you'd take another look. These are independent book reviews; I have nothing to do with their authors, and it does help to provide guidance given the vast number of books that have become available. As for the code samples, the majority of the code has to do with managing the HTTP communications; the Javascript part is minimal and essential. I do not agree that these go on a Javascript page. Request that you take another look at the suggested links.Harborsparrow 18:17, 26 October 2006 (UTC)

I did not submit the comment below. It is unsigned.Harborsparrow 00:49, 11 January 2007 (UTC)

Additionally, I'd like to request that you consider adding a link to Klir Analytics as a Web 2.0 network monitoring tool built using AJAX:

• www.klir.com An example of web based performance management software using an AJAX interface]. —The preceding unsigned comment was added by Timventura (talk • contribs) 19:03, 8 January 2007 (UTC)

You've been spamming this link across several articles. Not a good way to convince us of the merits of the link, as it looks like plain spam right now. --AbsolutDan ^(talk) 01:11, 9 January 2007 (UTC)

Stop Perpetuating the Acronym Reference

An annoying trend that seems to have built a momentum of its own is the belief that Ajax is an acronym for Asynchronous JavaScript and XML. It's not even a shorthand for that. Those technologies are used in Ajax, but it is a misnomer to equate them to Ajax. Jesse James Garrett himself has defined Ajax applications as meeting two criteria:
1) Uses an asynchronous interaction model
2) Utilizes native browser technologies
Ajax is a TERM, not an acronym or even a shorthand - it's more like a classification or categorization of a way of approaching web application implementations. Someone please revise the text on the page to alleviate the confusion, and remove the reference to "Asynchronous JavaScript and XML". It was disturbing to hear many presenters at the 2006 AjaxWorld conference making reference to this pseudo-acronym, as it made me question whether they really knew what they were talking about.
12.162.3.126 01:55, 6 October 2006 (UTC)

I would say that if "many presenters at the 2006 AjaxWorld conference [made] reference to this pseudo-acronym", then that, in itself gives it a notable, and public-domain existence. Wikipedia does not 'make the facts', it reports them; the same goes for Jesse James, I expect, too. --Nigelj 19:46, 6 October 2006 (UTC)

However, since Jesse James Garrett is the one who coined the term and he, himself, has mentioned in his presentations that Ajax is not an acronym, it just seems like perpetuating an inaccuracy does not make it valid (or a fact), just because so many people make references to it. Sounds like religion to me. -- 198.144.206.109 20:41, 9 October 2006 (UTC)

I'm confused. You say he has mentioned it is not an acronym, but it's his very own paper that says "The name is shorthand for 'Asynchronous JavaScript and XML'". That pretty much makes any claim to the contrary pretty bogus. And this form of "shorthand" does fit the word "acronym" pretty well. - furrykef (Talk at me) 01:42, 24 October 2006 (UTC)

Exactly. I think this is splitting hairs. The A, J and X in "Ajax" refer to Asynchrony, JavaScript and XML. He didn't just pluck the word out of the air. I think the whole "not an acronym" problem stems from the fact that Garrett doesn't want the A to mean "and". In his original paper he used a plus. To argue over this is a waste of time. Whether it's an acronym or not is largely irrelevant—it is a shorthand. Rufous 15:38, 8 December 2006 (UTC)

Drugstores sell many articles in addition to drugs, but it would be absurd to deny that the word "drugstore" came from the words "drug" and "store". However incomplete a description "Asynchronous JavaScript and XML" may be of the methodology the term "Ajax" refers to, the derivation is what it is. —Largo Plazo 13:29, 25 February 2007 (UTC)

Ajax vs. AJAX

The article should settle on whether it's "Ajax" or "AJAX" and use only that form. My vote's for "Ajax" because it's the original form, and it's very common. - furrykef (Talk at me) 01:42, 24 October 2006 (UTC)

Agree (discussed at length some time ago), and done, except external links. --John Seward 13:31, 24 October 2006 (UTC)

disagree - AJAX is an acronym that stands for Asynchronous Javascript And XML. I think this article should be renamed. --Dandaman32 04:16, 29 October 2006 (UTC)

Ajax is not an acronym. Artw 04:19, 29 October 2006 (UTC)

It is called Ajax in the article of J.J. Garrett and this is, I believe, the subject of the current article. Booles 12:59, 7 November 2006 (UTC)

Booles, I assume you meant the article by J.J. Garrett introducing the term. --Rschmertz 18:27, 13 November 2006 (UTC)

Artw, please explain your statement that "Ajax is not an acronym." --Rschmertz 18:27, 13 November 2006 (UTC)

Ajax is not an acronym. Artw 18:38, 13 November 2006 (UTC)

I think this is rebutted well here. --Rschmertz 19:19, 13 November 2006 (UTC)

In particular, this was discussed here. Please give that a read-over, furrykef. It more-or-less persuaded me that referring to it as Ajax more closely meets Wikipedia standards. --Rschmertz 19:19, 13 November 2006 (UTC)

---

I'm about to correct usage in WordPress Codex: Ajax, not AJAX. Viz.:

Ajax is not AJAX

"When Jesse James Garett had coined the term Ajax it was used in camel case. But due to its expansion coming into the limelight as “Asynchronous JavaScript and XML” (notice the uppercase of the words) people represented it as AJAX and not Ajax." [...]

"The reference of the usage is correctly attributed to the creator of the term itself i.e Jesse James Garette. He used Ajax (camel case). Wikipedia also uses in the same way, alongwith many big vendors, so it ought to be Ajax and not AJAX."

"Arun Gupta recalls his experience in making the changes at Sun Microsystems.

"Ajax is a popular term for past few months but is still being written incorrectly as “AJAX” (all capitals) instead of “Ajax” (camel case). I started using AJAX but then corrected myself and have been using Ajax since then."

Ajax Exposed from TechTracer.com

--BenTremblay (talk) 19:33, 9 February 2008 (UTC)

---

Non-Ajax

Non-Ajax users would ideally continue to load and manipulate the whole page as a fallback, allowing the developers to preserve the experience of users in non-Ajax environments (including all relevant accessibility concerns) while giving those with capable browsers a much more responsive experience.

This is the last sentence in the article and I wonder if this makes sense? Booles 13:02, 7 November 2006 (UTC)

It makes sense to me, however it could probably do with some editing for clarity. Artw 04:52, 8 November 2006 (UTC)

It's pretty compressed – I had to read twice and thrice to understand (?) what's intended. I interpret it as: if written well, an Ajax web page is loaded in the conventional way into web browser not fit for using Ajax "tech", while at the same time users of modern web browsers fit for Ajax may enjoy the improved response times inherent in the "tech"; then of course disregarding my personal doubts about time and resources to implement a complicated technique in a time-and-money pressed world. Said: Rursus ☺ ★ 10:16, 8 August 2007 (UTC)

Pronunciation

Ay-Jacks or Ah-Jacks? or both?--sin-man 05:17, 9 November 2006 (UTC)

I think one is expected to pronounce it the same way one pronounces the Greek hero's name. I usually hear that pronounced Ay-jacks. - furrykef (Talk at me) 07:36, 19 November 2006 (UTC)

Matter of taste, but the hero is pronounced I-yux (no pun intended). Said: Rursus ☺ ★ 10:19, 8 August 2007 (UTC)

The hero is also pronounced Ay-Jacks Ajax in Merriam Webster's Online Dictionary Ajax in dictionary.com. In fact, I haven't found any references for the other pronunciation in English. Razeetg 12:13, 3 December 2007 (UTC)

AJAX based player

You can watch all the Reuters news on your Google homepage. An AJAX based Retuers player is available here -

http://padmanijain.googlepages.com/myexperiments.html

Same player is also available as Google gadget.

Edits by 87.203.160.112

I removed the following, added by 87.203.160.112. While s/he may have the germ of an idea here, it does repeat information in the article and is not yet ready for the lead section. S/he also wrecked the References section, so it needed reverting pretty quick.

<removedText>

DHTML + XMLHttpRequest + ServerFiles = Ajax

• DHTML:Filters data for display on the page
• XMLHttpRequest:Transfers data between the server and the page
• Server Files:Provides data that is either static or dynamically generated

How the classic Web user experience works: Although someone can use DHTML, to make changes to the content being displayed on the screen, all of the data used to create the content(displayed or not) of a Web page must be contained within the code that was initially sent. If the user interacts with the page and new data is required to respond to what they have done, a new Web page must be sent from the server and loaded in the browser.

How the Ajax Web user experience works: Ajax changes the classic Web experience by allowing the browser to go back to rhe server incrementally to make changes to the content, turning the Web page into a filter that processes data coming from the server. Instead of having to wait as data is sent to the server, the data is sent and received in the background while the visitor continues to work.

</removedText>

--Nigelj 23:41, 8 December 2006 (UTC)

Javascript reliability

This section needs to be edited for encyclopedic tone and grammar. —The preceding unsigned comment was added by 69.19.14.35 (talk) 20:35, 8 January 2007 (UTC).

Validity of bandwidth example?

The articles explains how Ajax can save bandwidth with an example:

With Ajax, the HTML of the page, e.g., a table structure with related TD and TR tags can be produced locally in the browser and not brought down with the first page of the document.

That seems like a poor example. Any data that's to be displayed in a table structure will be downloaded in XML format, which means that data is going to be marked up with some set of tags that organize it into multiple sets (i.e., rows) of related data values (i.e., columns). "TR" and "TD" at least have the benefit of being only two characters each. —Largo Plazo 13:33, 25 February 2007 (UTC)

I can't think of any non-trivial (or non-silly) example of a significant net savings in bandwidth. Indeed, the emphasis in Ajax for numerous, short, queries suggests that in addition to the usual unavoidable XML/HTML/JSON bloat, the HTTP request and response headers, and all the TCP setup-and-shutdown stuff, will add more than one might save.

If I may be permitted a brief rant: I agree in a very large degree with the comments from Robbyslaughter and Kondur found under "New Criticism: Fragility of Model" in the first archive of this talk page. Ajax is at best an abuse of existing standards (HTML was never intended to be used in the ways it is now; ditto JavaScript), will likely lead to the development of fragile systems (relatively speaking of course!), and certainly no way to save development time, bandwidth, etc. Web browsers are very poor platforms for large application development, and running RPC via a HTTP is ... well, it makes about as much sense as running RPC via SMTP. Sure, you can make it work, but, really, should you? An inkling into the looming issues can be found at a number of websites now. As an example, when reading http://ajaxexperience.techtarget.com/east/html/building.html, I was struck by convergence of the problems with Ajax development (and solutions) to "normal" application development. This raises the question to the real value of Ajax, perhaps even it's long term viability: eventually most people are going to realize that sugar coating a turd doesn't make the turd go away, and some new interactive-content standard will emerge. mdf 14:57, 8 November 2007 (UTC)

David W. Radcliffe

Is the part about David W. Radcliffe really necessary in this article? I feel it is particularly wrong that the reference points to a zip file. It's a bit unfit for wikipedia, IMHO. //BankingBum 05:49, 26 February 2007 (UTC) ^$$

To BankingBum: Whilst I agree that my post wasn't strictly about AJAX (Ajax or ajax, depending upon who you ask) in its present form, it was about the (pre-Ajax) development of alternative technologies to full-page reloads. You allowed other references to alternative technologies under the history section, so why not mine? This seems a bit one-sided to me, as I'm not from Microsoft or the USA. Maybe there should be a seperate section refering to (or at least mentioning) alternatives to Ajax, or an umbrella subject covering ALL web user experience enhancements. If not, where in Wikipedia should my post/article be located? 217.68.129.254 13:43, 27 April 2007 (UTC)

AJAX disambiguation

The following is a cut and paste from User:Artw's talk page following a session of edits and revertions. -- SGBailey 22:24, 6 April 2007 (UTC)

Start cut & paste

Since you are so keen to not have a disambig at the start of Ajax (programming), I am converting AJAX into a redirect to Ajax not to Ajax (programming). -- SGBailey 06:40, 5 April 2007 (UTC)

• Reverting (see AJAX talk). I'm really not sure eho you think you;re helping out here. Artw 17:31, 5 April 2007 (UTC)
  • I got into this because I typed "AJAX" into the search box and pressed "Go" and ended up at Ajax (programming) when I wanted stuff about greek warriors. You can't hijack a word for just one application and deny use of it for other (probably more common) uses elsewhere. Either AJAX must point to the Ajax disambiguation page or Ajax (programming) must have a link to the Ajax disambiguation page. It doesn't matter which, but you can't deny both options. If I don't get a convincing reasoned reponse to this in a few days I'll re-revert AJAX. Assuming you re-re-revert it then I suggest we get arbitartion involved. -- SGBailey 21:59, 6 April 2007 (UTC)
    • TBH I'd considered someone typing it in all caps without wanting the programming term pretty unlikely, perhaps that's not the case. You should probably take this to talk:Ajax (programming) for discussion there. Artw 22:10, 6 April 2007 (UTC)

End cut & paste

Also relevant: talk:AJAX. Artw 22:30, 6 April 2007 (UTC)

• The reason I typed AJAX not ajax is that my caps lock key got turned on and I didn't bother retyrping it cos I expected it to work. This is a common screw up for me and I suspect for many others. I understand the argument that AJAX is often about programming and so I concur that it would be better for that to link to Ajax(programming), However I don't see what harm there is in putting a disambig link on the Ajax (programming) page, I only see benefits in doing this. I doesn't harm the programming article in any way. -- SGBailey 09:38, 7 April 2007 (UTC)

If users typing the all caps verison of AJAX by accident really is a problem then we should keep the disambig at the top of the page, though I dislike it as it's messy and and we'd only be doing it to help users who have made what amounts to a typo. It's certainly preferable to redirecting AJAX to the disambig (see the relevant alk page for the reasoning on that).

But, again, I have real trouble beleiving that this is really all that much of a problem or that it happens very often. Artw 20:03, 9 April 2007 (UTC)

I assume theres no way of putting in a conditional message? Artw 20:05, 9 April 2007 (UTC)

Clarifying policy for Artw: Artw, WP:DISAMBIG states ... When a user searches for a particular term, he or she may have something else in mind than what actually appears. In this case, a friendly link to the alternative article is placed at the top. ...

the policy also states ... When there is no risk of confusion, do not disambiguate or add a link to a disambiguation page. (emphasis not in original).

So far, the facts here seem to be as follows:

• No one has claimed that there is zero risk of confusion over the title of this article
• A "typo" may be one source of confusion, but is not necessarily the only potential confusion
• The "typo" scenario did not even originate from misspelling but letter-case
• The upper-case "AJAX" appears in more contexts than just the subject matter of this article (see e.g. [2])
• The title-case "Ajax" appears in numerous contexts already identified in the disambiguation page
• The rationale I dislike it as it's messy does not appear to have support under any relevant Wikipedia policy

Based on these facts, it seems quite clear that a disambiguation link at the top of the page is both appropriate and consistent with Wikipedia policy. Whether the "typo" scenario is common or frequent is not really relevant. Unless you wish to clarify or correct any point made here, a fair conclusion seems to be the disambiguation link should remain in the article. Regards. dr.ef.tymac 21:59, 9 April 2007 (UTC)

Theres zero risk of this articles title being a source of confusion. I'm still kind of dubious as to whether AJAX is a potnential source of confusion - I'd have said no, but if others disagree that strongly then it's good enough for me. Artw 23:27, 9 April 2007 (UTC)

The upper-case "AJAX" is very commonly used in organizations and in education, e.g. by Microsoft, Mozilla Foundation, Opera Software, W3Schools, so it has been an accepted standard name. Thus it should be mentioned in the first paragraph of the article.--Wengier 03:45, 24 April 2007 (UTC)

Example sites

How is a list of some AJAX-enabled sites SPAM? maybe my list was a little long, i've added a shortened version. jez

Pronouceation

Is it pronouced [A-JACKS] or [I-ACKS]? Kicken18 10:42, 19 April 2007 (UTC)

See above. --JohnAldis 13:20, 10 May 2007 (UTC)

SEO Considerations

There are some serious Search Engine Optimization issues that IMO need to be discussed in this article, such as: I think this topic should not be ignored - many AJAX programmers face huge frustrations daily as they butt heads with SEO's - some informed tactics and best practices can eliminate this frustration - both sides need to be communicating more and don't in fact need to be opposed, because AJAX can be part of a search engine optimized site. Feel free to use this article on AJAX, Web 2.0 and SEO for reference. LunaticBeatnik 01:05, 4 May 2007 (UTC)

Rather verbose, for me. SEO problem may be solved by extracting dynamic content from other HTML pages, but this is hacking. The problem is in dynamic pages, not in Ajax. Macaldo 18:28, 4 May 2007 (UTC)

I agree that the problem is not in AJAX itself - problem is in how AJAX is applied to the page. For example, is there key content upon initial load, use of unique URL's, etc? On the other side of the coin, AJAX can be a benefit to SEO if used to create a useful AJAX tool or gadget that other site owners would be compelled to link to. If you feel that article is verbose, feel free to reference another source that you feel explains the optimization issues better. SEO for AJAX is not a simple topic, but it does need to be addressed because it is a challenge that developers face every day.LunaticBeatnik 21:26, 4 May 2007 (UTC)

Examples

Are there any examples of the use of Ajax, to see it working online ?. --HybridBoy 06:06, 31 May 2007 (UTC)

Did you try searching for it? This article once contained lots of linkspam, which is still available if you click the history tab, but we won't be adding the links back, per WP:EL and WP:NOT. Mindmatrix 15:09, 31 May 2007 (UTC)

Using objects to record history?

Taken from article:

"The dynamically created page does not register itself with the browser history engine, so triggering the "Back" function of the users' browser might not bring the desired result.

Developers have implemented various solutions to this problem. These solutions can involve using invisible IFRAMEs to invoke changes that populate the history used by a browser's back button. Google Maps, for example, performs searches in an invisible IFRAME and then pulls results back into an element on the visible web page. The World Wide Web Consortium (W3C) did not include an iframe element in its XHTML 1.1 Recommendation; the Consortium recommends the object element instead."

This implies that it might be possible to use the object element in the same way as using an IFRAME element for populating the browser's history. Is that possible? If so, why does anyone use IFRAME, when object is recommended? Callum85 23:22, 31 May 2007 (UTC)

Pronounciation

It would be good to indicate how is Ajax pronounced in the beggining. Example: Ajax(pronounced .....) is a technique in... and so on. If it is possible, it could be with proper transcription symbols. Johny1407 17:25, 16 June 2007 (UTC)

It's been considered in the past: I think the general consensus was that it's clutter and unnecessary. Artw 17:55, 16 June 2007 (UTC)

I think it is never any kind of clutter and is quite helpful since it helps people sort out whether it is pronounced A-J-A-X
or 'a-yaks it is a good and important for an introduction. For this article exactly I think a transcription is quite neccesary.Johny1407 19:46, 16 June 2007 (UTC)

Seems like it, as I wouldn't have pronounced it in either of those ways

About see also

"see also section should not include articles which are wikilinked in the article body."

Not sure. Macaldo 13:38, 12 July 2007 (UTC)

84.226.158.62 (talk) 20:56, 4 March 2008 (UTC)
Hello,
there are other ways to make a http request with simple javascript instead of ajax
Actually I don't know where to enter something about the easy server side request, but I believe it's useful for many ppl, who don't know Ajax, but Javascript. Then they don't have to learn a new language without reason.
That's why I want to publish somewhere or set at least a link ;), since I'm not a big content writer and also I'm not used to work with these huge pages like wiki or something else.
Have you any suggestions where without getting trouble ?
( I've set the ip-talk page to my favorites for a while)
cheers Tümmel

Don't understand this sentence...

In Constituent Technologies: "Given [Given that? Because?] XMLHttpRequest can eliminate the need for page refreshes, other technologies become more prominently used and highlighted with this development approach." Which other technologies? Other than what? Does "prominently" mean "frequently"? What does "highlighted" mean in this context? In sum, can this sentence be deleted without loss of information? Brec 16:00, 31 July 2007 (UTC)

I think it's esentially saying that because people are using XMLHTTPRequeat to avoid a page reload other technologies - well, Javascript basically - are being used to update the page. But yes, it;s a horrible sentence - feel free to rewrite or delete. Artw 17:32, 31 July 2007 (UTC)

I have rewritten the sentence, for the reason above: which other technologies? Should be mentionned . JavaScript is a part of Ajax, the sentence is useless. Macaldo 15:46, 6 November 2007 (UTC)

Sample Code

The Sample Code in the article does not have any context nor is it explained what the code does. Wikipedia is aimed at the layman and I, who knows nothing about AJAX (and that was why I read the article) have no idea what the Sample Code is trying to get across. And in particular, why that piece of sample code, as opposed to any other AJAX code? What makes it special? --Daleh ^T 10:37, 19 January 2008 (UTC)

- The javascript code given as an example downloads a page from the server and replaces the current document contents with it. It fails however to explain this leaving confusion. Also it only replaces the body of the current document meaning the pages it fetches are expected to contain only the body portion of the page. Writing the content directly instead of trough the DOM is faster but less compliant to W3 specs. One more thing would be that by using innerHTML to write the content most current browsers will not run any scripts contained in it.