Jump to content

Talk:Ajax (programming)/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3→Archive 5

Have proposal for append link to worked sample http://smirnov.org.ru/myfaces-ajax/ajax.jsf and description http://smirnov.org.ru/en/ajax-jsf.html of open-source AJAX - Java Server Faces Integration library. Unsigned comment by User:195.182.140.58.

Another link proposal for AJFORM. AJFORM is simple toolkit which can be used to submit any HTML form through XMLHTTP.

Maybe we should add some links to full-features applications written in Ajax. This will demonstrate that ajax is a pretty powerfull framework to be using in these xml-enabled days... One of them examples could (should) be:

I trimmed half a dozen links out of the External Links section a week ago, and now it is creeping up again with a new one added every couple of days. I don't think Wikipedia is designed to be a Web Directory - that is what Yahoo!, dmoz, etc are for. Can we agree to keeping the External Links down to important pages - namely, origins of the term, balanced analysis of the term, perhaps an example in action - and that's it? --kjd 12:24, 13 Apr 2005 (UTC)

I find myself continuing to do this on a weekly basis until anyone gives a good reason why there should be a hundred links in this article to external pages. I don't see how listing every AJAX related page on the web is encyclopaedic, as seems to have been done with some edits in the past few days. Just like to one or two of the many numerous specialist AJAX sites which in turn documents such things. --kjd 11:35, 26 May 2005 (UTC)
Don't you find that you are being elitist by continuing to remove these links? Sure, Yahoo! and dmoz may be better suited for these types of references, however, the most important thing for wikipedia entries is the conveyance of information--in a clear and thorough manner. When i began to research I found these links extremely helpful. Defining these links as superfluous is obnoxious and not necessary. If you don't like them on the page just ignore them.
No, I don't consider myself elitist, I am trying to be encyclopaedic and remove a superfluous morass of links that adds little value. Besides that, perhaps you can explain why articles such as What kind of language is XSLT?, if worthy of linking at all, are more suited to an AJAX article rather than one on XSLT? --kjd 07:51, 27 May 2005 (UTC)

The list of links were useful and most were relevant. The problem is; where shall it end? If all links shall be included then the article will be a long list of links. And that is not what Wikipedia aim for. --Sleepyhead81 08:58, 27 May 2005 (UTC)

My thoughts precisely. --kjd 09:42, 2 Jun 2005 (UTC)
Why not have a link that provides additional information for a SPECIFIC POINT? In other words, if one is talking about a specific AJAX technique, one can omit all the technical information about that technique in the article and add a link to the detailed technical information. Dropping in a link out of the blue that isn't touched upon in the article text makes little sense. If we're going to do that, then only one link is needed for the entire article: Google. Safety Cap 14:31, 16 Jun 2005 (UTC)

Just to add a little levity to the "remove" versus "keep" external links discussion... For months I had been getting new comments on a blog that I had written on my impressions of AJaX at the TSSJS convention. I couldn't figure out why I was getting so many hits... these were just some random musings and not all that interesting. As it turns out, somebody had added a link to my blog to the AJaX Wilipedia entry. The link was finally removed on June 2nd, which just happens to be my birthday. Coincidence or Cosmic... who knows? Some of the external links may be worth keeping, but mine certainly wasn't. John Reynolds.

  • Also the link "AJAX' Achilles Heel maps.google.com with Javascript disabled" should also be removed. The page does not have a lot of information.

I disagree. Read Garrett's original article, and search for the phrase "Javascript turned off". Specifically at the end of the question "Can Ajax applications be made to work for users who have JavaScript turned off?" He answers maybe, but the "AJAX' Achilles Heel" article refutes this: the answer is actually no.

    • With all due respect, that's crap, for two reasons. First, the "Achilles Heel" article proves that Google Maps specifically doesn't work with Javascript turned off, not that ALL Ajax apps won't work. Second, Garrett specifically does not ask whether Ajax itself works when Javascript is turned off, but rather asks whether Ajax apps can be made to work without Javascript; there's a difference. It's not hard to design a web app that includes Ajax but also degrades gracefully -- that seems more to be the spirit of his question, and it's a legitimate perspective. And to return to the primary point, I agree that the "Achilles Heel" link doesn't seem to have a lot going for it. Jason 00:20, 9 August 2005 (UTC)
      • I'm not going to insincerely preface this with "all due respect" and then proceed to use disrespectful language (if you disagree just say "I disagree". If you want to call something crap, don't preface your comment with "in all due respect", unless you don't care whether you are considered disrespectful or insincere). But I will assert in no unclear terms that an application that relies entirely upon AJAX therefore relies entirely on Javascript, and if Javascript is disabled, then so too is your AJAX application. Under this circumstance you will have no choice but to turn to non-AJAX capabilities in order to "degrade gracefully", as you put it. As for the "spirit of the question" and "legitimate perspective", it's alot easier to ascertain perspective when, such as in the Achilles Heel article, somebody just comes out and says it: no Javascript, no AJAX.

Concrete Example?

Doesn't this example just describe using javascript to re-order a table? There's nothing asynchronous about this example, there's no XML being used. At best this example is really only an example of Javascript. Short of deleting it, maybe it could be re-written to show how client side javascript functionality (as described) could be extended using AJAX to actually change the content being displayed in the table, rather than just reordering the table.

--Sleepyhead81 10:51, 20 July 2005 (UTC): The example could very well use XMLHTTPRequest to get an XML document from the server. But if the result is just to change the order then client-side javascript would do the trick as well - there wouldn't be a need to get a new list from the server and use the DOM to manipulate the table displayed. A better example is probably instant editing - clicking save and the changes are saved without refreshing the page.

--- I agree that the potential use of all client-side Javascript made that example a bit muddy for beginners; I replaced it with a new example, based on how Flickr allows caption editing. Jason 02:46, 9 August 2005 (UTC)

AJAX or Ajax?

In original Garret's article he refers to the term as Ajax, not AJAX. Shouldn't we rewrite the title then?

  • My vote is for "Ajax". My guess is that if we persist in calling it "AJAX" people will notice and then this groundbreaking new technology will be pronounced Ay-Jay-Ay-Eks, and that would suck. Eric B. and Rakim 22:02, 16 Jun 2005 (UTC)
  • How can you call it groundbreaking new technology? It's neither groundbreaking nor new. Nor is it a single technology.
  • "AJAX". Despite how it is spelt in the initial article, the prevailing common usage is "AJAX", and it is in fact an acronym. I don't think pronunciation has any bearing on it. (Who pronounces LASER, DARPA, SCUBA etc by their initials?) --kjd 07:29, 20 Jun 2005 (UTC)
  • I vote for Ajax. If you google for for the name, it becomes apparent that the most widespread usage is not the uppercased one. So there, Ajax as the person who coined this term intended, and not "AJAX". Fatalis 12:48, 20 Jun 2005 (UTC)
  • "Ajax". No one capitalizes LASER, and no one should, despite it being an acronym. "Ajax" wasn't coined with capitals, and there's no need for them. The term makes a techie concept friendly and accessible to non-techies (which is a good thing), and capitalizing it undermines that effect.
  • * But everyone capitalizes NASA.
  • Ajax. The term was unequivocally coined using the "Ajax" spelling form, which really should trump anything else. Likewise, as the Google search by Fatalis shows, the prevailing common really isn't all-caps. Jason 16:35, 5 August 2005 (UTC)
    • NOTE: I've requested a page move to either Ajax or Ajax (Programming), based on a consensus of the minor amount of discussion here (and in the hopes that it will stimulate any further discussion that needs to happen). I'd love to see it end up at Ajax, but I'm not sure that it'd be entirely warranted, as the Ajax disambiguation page is currently there and I'm not sure that this use of Ajax is enough to warrant displacing it. The other option I propose is to move the page to Ajax (Programming), but of course I'm up for other suggestions. Also note that I didn't edit the page itself to change AJAX to Ajax, as I wouldn't begin to claim that that wouldn't be controversial without first having this discussion. And lastly, I obviously didn't rename this section to "Requested Move", in deference to the original author of the section. Jason 16:20, 7 August 2005 (UTC)

Moved to Ajax (programming), as of today. Jason 22:33, 13 August 2005 (UTC)

Link to specific blog post - not entire blog

The link to http://htmatters.net/htm/1/2005/06/AJAX-Achilles-Heel.cfm should be linked to that specific blog post not the entire blog which user User:Jemptymethod is trying to do. He is the author of that blog. A link should be relevant to the article. That blog is not. But the blog entry is at least somewhat relevant (can be discussed). --Sleepyhead81 16:01, 13 August 2005 (UTC)

  • About a month and a half ago I noticed an increase in traffic to my blog coming from this wikipedia article. In the meantime I've kept the link at the bottom, and now I've added another Ajax article, albeit satirical, to a new "Ajax" blog category on my site, so I linked to that category instead of the original article. Plus I added an actual image relevant to the original article, a screenshot of maps.google.com with Javascript disabled. Other people have links to entire blogs rather than just blog articles, but still I will work on this: on the Ajax category page that is linked to, I will "explode" the entire original blog article, plus put it at the top. That should be almost identical to how the page was before, except with a relevant image and a link to another article. I don't know about anybody else but this seems like a fair compromise to me. Jemptymethod 11:53, 14 August 2005 (UTC)
    • It is only the specific blog post that is relevant here. The rest of the posts on your blog are not relevant. IMHO the blog post isn't even relevant. It's like saying JavaScript doesn't work when the browser has turned JavaScript off, or images are not shown when images are turned off. --Sleepyhead 07:42, 15 August 2005 (UTC)

Linking to external images without sourcing them

Is it considered OK to link to the images from Jesse James Garrett's Adaptive Path article directly, without crediting them? It's the worst of all worlds -- using someone else's bandwidth, and doing so in a way that makes it appear to casual users that the images are part-and-parcel of Wikipedia. (Specifically, I'm referencing the two linked images in the "Compared to traditional web applications" section.) I'm going to provide citations on both the links, but I still think that providing external links solely to images that are part of a more definitive article is something that deserves thinking about. Jason 11:42, 5 August 2005 (UTC)

  • I don't know what the Wikipedia guidelines states regarding this issue but I think the images should be uploaded to Wikipedia. The images are very relevant for explaining how Ajax is different than tradtional web applications so I think they should be displayed in the article not just linked to. --Sleepyhead81 11:56, 5 August 2005 (UTC)
    • Directly uploading the linked images from the article would be a clear copyright violation, though -- those are firmly within the intellectual property of Adaptive Path. That's the conundrum -- linking them as individual external articles makes them appear to belong to Wikipedia while using someone else's bandwidth, and uploading them is worse (illegal). The ultimate solution is one of the following: (a) someone can illustrate the concept themselves in an original way; (b) someone can ask AP for the right to reproduce the images here; (c) the links can be removed, and replaced with a link to the article and explanation that it contains useful illustrations of the difference between the two models of web applications. Jason 12:22, 5 August 2005 (UTC)
Linking to external content on Wikipedia is annotated with the external link graphic like so: [1] There's no ambiguity that implies that the linked content is part of Wikipedia, and the bandwidth is not an issue. If the link target wanted to prevent the bandwidth usage, they would simply reject any requests with Wikipedia as a referer (the way bugzilla.mozilla.org refuses Slashdot-refered requests). -Harmil 10:20, 15 August 2005 (UTC)

Criticism

The criticism here is controversial at best. "XMLHTTP" was not very common terminology, if used at all to mean a style of programming. In any event, Ajax encompasses more than XMLHttpRequest based calls. This section should at least be balanced by the benefits of the "Ajax" term - ie formation of a community, bigger push for rich browser features, a slew of new. publicly available, examples. - Sleepnomore 21:09, August 13, 2005 (UTC) This section basically amounts to: Some people don't like the name, and some people don't think it should be characterized as "new." Neither of these points seems significant enough to include in Wikipedia. The section on accessibility should be moved up into Pros and Cons and this section should be eliminated.

Other topics exist that carry a criticism section. I know that you are new to Wikipedia and you are not used to doing this. I also know that you are a personal friend of Jesse James Garrett. The problem is that you cannot simply remove cricism from the public eye and public documentation because you don't like it. Your dubious claim is invalid because you don't dispute the fact that the criticism claimed on the AJAX article doesn't exist. It would be impossible to prove since there are many citations of such criticism to point to. Please come back with valid claims before marking an item as dubious or disputed. - Sleepnomore 21:09, August 13, 2005 (UTC)

  • I think the Criticism section should be removed altogether, as it is not entirely relevant to Jesse James Garrett as a person. You don't like the word, fine... but so what? Once the industry picked it up your dislikes become moot. btw the links you've added are almost entirely prejudicial remarks about not liking the word. The whole thing is just silly. You've lost, but somehow you find solice in having a Criticism section with links to posts (mostly, the criticism is in posts, not in the articles themselves) ranting about how they hate the word? Please... ask someone close to you to shake you.
    • This article is not completely about Jesse James Garrett (although he does come slightly into play since he coined the term). This criticism needs to remain as it does exist. This argument has become rediculous. There is no factual basis by which you continue your vandalism and terrorism of an otherwise peaceful topic. - Sleepnomore 21:39, August 13, 2005 (UTC)
It should be noted that a) Sleepnomore should avoid making this personal b) the anon editor should sign his/her comments (consider creating an account). c) The anon editor is being abusive, and the removal of criticism, given that the criticism is factual, is not reasonable. Wikipedia works best when you expand its content rather than trying to remove what you disagree with. Do research. Edit content to add in the fruit of your research. Problem solved. -Harmil 10:27, 15 August 2005 (UTC)

Proposal to unlock page

Isn't it possible to just prevent User:sleepnomore from editing the page and allow all others to do so? Technology like Ajax is rapidly changing, and locking this page is absurd.

Sleepnomore, I hate the term Ajax too but just deal with it or leave Wikipedia.

No. Unless the ArbCom has made a ruling, Sleepnomore is allowed to edit any Wikipedia page. Zscout370 (Sound Off) 22:26, 15 August 2005 (UTC)
What sort of evidence would ArbCom need to consider? Can wikipedia determine all IP addresses he has used when he has been logged on? And then determine if he stays behind a proxy, or uses an IP that is readily identifiable with being from his area, which he freely divulges on his user page? Or, if some combination of proxied/non-proxied, whether there is a pattern, such as being behind a proxy at times when massive reverts have appeared on this and other pages he has been instrumental in having restricted? Jemptymethod 22:59, 15 August 2005 (UTC)
You first need to file a WP:RFC and see what happens there. If the request for comment does not help you, then go to WP:RFAr. Zscout370 (Sound Off) 23:25, 15 August 2005 (UTC)
Once again, I'm forced to ask why I would be the one blocked from editing in the first place. Wikipedia admins blocked THIS page because of the vandalism from an anonymous IP. They blocked it because he was removing a criticism section that existed before I even joined wikipedia. I did in fact start a JAXASS article. I did, in fact, add a criticism section to Mr Garrett's article. I do in fact have a problem with Mr Garrett's renaming existing technology. But that doesn't negate the fact that this article is locked do to "Michael" aka "Catmistake" aka anonymous IP's continued vandalism and refusal to follow rules or listen to reason. I've made all attempts to bring this matter to a smooth close and all he seems to be doing is stir the pot. - Sleepnomore 16:55, August 17, 2005 (UTC)


You have nobody but yourself to blame for having become a "person of interest". You yourself have previously "stirred the pot", to use your own phrase, through your characterization of your JAXASS article as a "direct antagonist" to AJAX, your link to your own blog with the caption "AJAX=FRAUD", and your prolonged conflicts with other users you have come into contact with from the AJAX article. You didn't seem to have much interest with the AJAX page for several days after JAXASS was deleted, but then when you did subsequently have a lot of involvement, it involved a revert war that resulted in the page being locked down. It seems like 95-98% of your involvement on Wikipedia has been with AJAX, user pages of contributors to AJAX, plus other pages those users have contributed to, and JAXASS. As you can easily find out I'm not AJAX' biggest fan, with a blog with two articles that are anything but pro-AJAX. So I think I can be impartial. But I also think your activity on Wikipedia needs to be investigated. If you have done nothing then you have nothing to fear. However at this point I don't think there is anything you can say to convince people not to consider you for this. Jemptymethod 20:14, 17 August 2005 (UTC)
I'm actually rather proud of my work. I don't care to "blaim" myself for anything but providing insight that I felt relevant. Obviously, I choose to create a farcical technology called JAXASS and place this in its seperate article. When this failed, I did provide my own insight into Ajax and Jesse James Garrett articles. Criticism already existed for this article so I appologize for nothing in reverting it back after vandalism. Yes, a great deal of my time has unfortunately be involved in edits, reverts, and user talks concerning this technology. Its something I'm very involved in and obviously took the initiative to make sure that the other side of the Ajax argument was heard. Obviously, folks such as yourself are not interested in seeing all sides of an argument. You simply want your voice heard and anyone else should be damned for having a say. That's not the way this works here. I have, several times, welcomed an RfC. I question its legitimacy, but welcome the investigation. I have no fears with being the subject of an RfC so trying to convince anyone otherwise is not something I intend to waste time on. What I do intend to invest my time on is making sure that this situation isn't manipulated into a "lets bash the opposing opinion" rant as it already has. From what I've heard, the person who started Wikipedia left the project to its own vices for this very reason. It became a sesspool of elitist jerks who wouldn't let articles work in an NPOV. Take,for instance, the actions and threats against the administrators who simply locked the page after the anonymous vandal kept deleting portions of this page. He was simply trying to get to the bottom of the error while others continued to bash him and anyone else that expressed a different point of view. In fact, I saw several instances where the others who agreed with my side (even if only slightly) were accused of being my sockpuppets. It couldn't have possibly been that the opinion I was expressing does have a following, even if they don't all edit on Wikipedia. In any case, I don't intend to keep dragging this out. If you want to keep fighting a dead issue, you are more than welcome to and I'm up for the challenge. Otherwise, I suggest you get back to some real work now that the article is unlocked. - Sleepnomore 20:57, August 17, 2005 (UTC)
You yourself couldn't make my argument any better, e.g. "People like yourself", "Elitist jerks", "my side", "up for the challenge" etc. Plainly judgemental and POV, yet then you yourself cite NPOV. Why so defensive? Again, if you had no involvement, you have nothing to worry about. You don't have to "up for the challenge"; you should be able to sit back knowing that nothing will come of it. 139.76.128.71 21:04, 17 August 2005 (UTC)
So when you state "my argument" you don't add your own POV? Strictly speaking, articles need to be POV, talks in articles do not. I say I'm up for the challenge because I am. If you have a problem with my comfort on this matter, perhaps you should be looking at your own relevance to this argument. - Sleepnomore 21:09, August 17, 2005 (UTC)

Remove text from critisicm

I think the text below should be removed from the article. I don't think it's relevant comparison. Ajax should be compared to normal web pages not other approaces to building software. What do you think?

"Ajax is not a new approach to building software. From a higher perspective the presentation layer is like a form and a programming layer behind handling the events, commonly known in programming terms as MVC. This kind of programming is very well known in older programming environments like Smalltalk, Delphi, MFC, Visual Basic, Oracle ADF, and Windows Forms, just to name a few. Applications using this model of programming have been around for years: Microsoft Outlook Web Access using WebDAV and web-based ERP systems such as Costpoint Smart Business Applications [2] and P2plus [3], which uses web services directly from the browser. However, because there are no standards available for the communication model behind previous implementations, all use proprietary extensions." - (unsigned by User:Sleepyhead81 )

  • I do agree that this seems a bit out of scope. There can be criticism based on the existence of the exact technology the term "Ajax" encompasses without needing to reach back to other programming models and languages. I think the first sentence, however, needs to remain. Perhaps the criticism section needs to be rewritten? I would be glad to do it, but considering the large debate already, I'm sure my edits would cause another revert war. Anyone else care to take a stab at it? - Sleepnomore 21:05, August 17, 2005 (UTC)
    • Isn't that sentance already covered in beginning of that section: "..for previously used techniques". I vote for a complete removal of the text above in my first comment. The critiscm section do need to be updated. Go ahead but just make sure it's kept neutral. I'll help. --Sleepyhead 21:14, 17 August 2005 (UTC)
      • I'll give it a whirl when I get home if no one else does first. I may make the updates on a user page or here in talk so everyone can have input before I put it on the page. My writing style is somewhat less formal and obviously needs some tweaking before submission. - Sleepnomore 21:20, August 17, 2005 (UTC)

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
  • 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)

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 Canada 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 Canada 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 Canada 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 Canada 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 Canada 19:42, 27 November 2005 (UTC)

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 Wikipedia: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 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 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)

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:

--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[4]. 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 [5]. It is also the name of a range of cleaning chemicals manufactured in the UK and sold globally[6]. 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[7]. 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 [8], 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...


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???

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)

Ajax without JavaScript

A link to a such article comes back from time to time. Without JavaScript, this is just XMLHttpRequest and maybe it has to be linked from the XMLHttpRequest page, but not from the Ajax page that is here to explain what is Ajax: XMLHttpRequest + JavaScript.
In my mind they have put Ajax in the title just to link from the Ajax page. For me it is a joke.

And so is "example of Ajax website". On the page about Computer, one can link to a page because this page run on a computer. It is a joke, isn't? On the page about HTML, one can link to a page because it is written in HTML. It is a joke, isn't? Linking to a page because it is built using Ajax is a joke also. Alcalazar 11:10, 25 April 2006 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Ajax_(programming)/Archive_1&oldid=1049175344"