Talk:Ajax (web technology)

Article overbroad

I have to object to this article, just as with AJAX frameworks. I think that the use of the word "AJAX" is over-broad, and we should try hard to restrict it, perhaps even avoid it. It's become a marketing buzzword. It refers to techniques where one updates part of a page with content without updating the whole page. Which is fine, it's part of developing web applications. I think we should do as following:

• have a page on practices in web application development, perhaps something like web applications
• have a page on JavaScript, which links to pages on XMLHttpRequest and Ajax
• have a page on JavaScript frameworks, not "AJAX frameworks"
• not call Ruby on Rails and similar server-side technologies "AJAX frameworks" - they aren't. You can build applications with Rails and other similar back-end frameworks that don't use Ajax or JavaScript, and indeed, it's probably a good idea to mentally separate out building the application from adding the Ajax - it should be the last thing one adds, following the principle of unobtrusive JavaScript (graceful degradation/progressive enhancement) for accessibility and browser compatibility
• stick closely to the technical component. For instance, in the article as it currently reads, it describes Ajax as "an emerging web technology that enhances the end users' web browsing experience". XMLHttpRequest (and JavaScript more generally) can enhance the experience of web users, but it can also make it worse.

I think we need to do some fairly fundamental butchering of this set of articles to make them even close to approval quality. --Tom Morris 18:17, 10 August 2008 (CDT)

Tom, thanks for the comments. In response, I agree that we need to narrow the definition of Ajax, not to "changing part of a page with Javascript" but more specifically to, "using an XMLHTTPRequest object to fetch information from a server in the background in order to update a part of a page with Javascript". Or something. Incidentally before we "butcher" this rather new article, please note that several students are rushing against a deadline to pack in as much as they can by next Sunday midnight (and will be "graded" for their effort up to that point). And certainly, we can all continue to evolve the article further thereafter, hopefully satisfying your concerns. Thanks for devoting attention to it.Pat Palmer 09:28, 12 August 2008 (CDT)

Yep, I've been holding off any significant butchering to give the Eduzendiums a chance to improve it. Once the Eduzendium deadline is over, I'm going to have a go at significantly reworking it. --Tom Morris 13:53, 12 August 2008 (CDT)

Please do not "butcher" this article without first justifying to me and the community of editors in Computers why there is a need to do so. I welcome your continuing comments on and authoring of it, but I don't particularly welcome what seems like a threat to replace the whole thing with a creation of your own without significant further discussion.Pat Palmer 17:50, 12 August 2008 (CDT)

The reason I am planning to rework it is that I'm fundamentally unhappy with the direction it is going in. I think that the sections on Benefits and Drawbacks should probably be changed to one on the design decisions involved in designing websites that use Ajax. The "back button" issue is a solveable one, and is also not Ajax-specific (any kind of complex interactive design element on the web can suffer these problems). I think that usability problems and the many solutions that developers have come up with should probably be a section. The 'Components' section is a mess and needs to be fixed up. I think that the edit I did the other day where I refactored a significant chunk of the body text helped readability significantly. By "butcher", I don't mean re-write or anything in any way obnoxious. I'm holding off serious editing - and putting the article before my peers (a number of close friends and acquaintances are commercial front-end developers who build web apps on a daily basis, and a number of those have books published on JavaScript and Ajax) until the Eduzendium participants have finished. I am not planning any kind of rewrite, but I do think that the article in it's current form needs significant refactoring. --Tom Morris 18:36, 12 August 2008 (CDT)

Tom, I see that we are actually in agreement then. The article as it now stands is, well, sloppy about many details, and further, it contains (or contained--I haven't read it all yet) numerous misconceptions or downright errors. We need not wait to make corrections and improvements of this sort. Please go to it at any point you feel ready. For example, earlier today there were misconceptions about XML being required, and about which DOM is involved, and even the definition at the top of the article was initially not precise (I tried to make it more so). So, no problem, have a go at fixing the stuff that needs fixing. I want students to experience the collaborative process.Pat Palmer 19:17, 12 August 2008 (CDT)

Tom, I see you are 'bugged' by the term Ajax. Please re-read the tone and content of your first three sentences and then read the rest of your very helpful organizational suggestions. The tone of your first 3 sentences is borderline obnoxious. Content-wise your first three sentences not only contribute nothing but they detract from well-thought out points that follow. I understand that Ajax is a buzzword. However it is not a 'marketing' buzzword. It is a term that has grown in usage because it describes a phenomenon that was previously unnamed. That phenomenon is the synergistic effects of the technologies described by they now dead buzzword DHTML with the Javascript XMLHttpRequest. Ajax is simply a nice short term to describe this phenomena. So yes, I have taken your flamebait, Ajax IS an important current term. It has gained much wider acceptance than the previous DHTML buzzword and precisely because it is so widely used it is important that any "citizens" resource provide users with an explanation of how the sum is more greater than the parts. Michael Bonanno 23:37, 15 August 2008 (EDT)

DOM, XHTML and XML confusion

The DOM involved in Ajax is the one for XHTML documents, not the one for XML documents. There are several DOM's in the programming world: Microsoft Word has one, just for example. AJAX is a difficult topic, because the things it does are going on behind the scenes and are not easy to visualize. Thus, we're going to need to be extra precise in our use of language in this article. Despite its being included in the acronym AJAX, XML is not at all necessary for using AJAX programming; the "wire format" between Javascript in the local browser and the web server need not be XML; it could be proprietary text, JSON, SOAP, XML, or yet others.Pat Palmer 18:20, 12 August 2008 (CDT)

archiving a statement; not sure it belongs

The statement I've removed is:

AJAX encompasses best practices in developing web applications, with clear separation of concerns, progressive enhancement, graceful degradation and adherence to Web standards..

Although I don't doubt that someone wrote the above, but there is no reason I can imagine that the mere fact that a page uses Ajax guarantees ANY of these things: progressive enhancement, graceful degradation and adherence to Web standards. So I'm leaving this here until I get a chance to discuss it with you (in class, I hope).Pat Palmer 19:06, 12 August 2008 (CDT)

Oh yeah, and Ajax cures world hunger too.Pat Palmer 19:49, 12 August 2008 (CDT)

AJAX or Ajax? need consistency

I personally don't care which, but please pick either AJAX or Ajax and stick with it throughout the article (after mentioning initially that both may be used).Pat Palmer 19:20, 12 August 2008 (CDT)

It has been taken care of. Dhawal Sehgal

Me router person. Push packets. Ugh

Actually, I had to remember that IPSec has a DOI, not a DOM. I don't know whether the security people were having an in-joke there, because DOI-100, which had nothing to do with IPSec Domain of Interpretation, was a long-obsolete message header format for special security traffic that was an overlay on a network that doesn't exist any more.

So, I have no ego on being corrected about anything in the Web and related areas. With routing, it might be "this is the most powerful router in the world. I can't remember if I have a slot left in the crossbar fabric. Feeling lucky, punk?" :-)

There is an idea rattling around in the upper layers of my lower layers brain, and perhaps it might help here. As a guess, what might be closer to a visual metaphor for AJAX might be some of the levels of abstraction in multiple, nested "network management" frameworks. There were multiple mappings, in different abstract and real notations, at different places in the network, depending on one's viewpoint. There were nestings for what the end user saw delivered in quality of service, what the provider to the customer saw inbetween his side of the delivery interfaces, and what we saw as both per-hop-behavior and per-internal-network behavior inside the cloud.

I wish we had an electronic whiteboard or some other visual collaboration technique; I've yet to find a mindmap program that was remotely as powerful. Would it be useful, Pat, to start out with a drawing -- I might just sketch and scan -- that broke out the pieces without naming them? This is an area to be cautious, because one of the things that doomed OSI was being too compulsive about layering, and, especially, not understanding that thee were parallel channels for management and control as well as for user data flow. My naive sense is that AJAX might be graphically be represented by a set of "stacks" in parallel, or perhaps drawing separately the server, wire/network, and client.

From my limited knowledge of AJAX, my sense is that there indeed might to be a modeling of parallel flows, and possibly both different reference interfaces AND abstract notations involved. I'm wondering if it would help to have a diagram of deliberately unlabeled boxes and connectors, simply to establish what is happening in the background, foreground, and middleground. That is the only way we sometimes could explain interprovider networks, with multiple nested instances of address spaces and protocol states.

Howard C. Berkowitz 19:28, 12 August 2008 (CDT)

Howard, specifically, it's Javascript in a web page, making HTTP GET or POST requests, and providing a callback function which gets called back by the web server 4 times until (the last time), the response is ready for processing. At that point, the Javascript callback function can parse the answer out of the string sent back from the web server and then can update some part of the web page with the new information. Try a diagram if you like; it might help!Pat Palmer 19:48, 12 August 2008 (CDT)

On components

"I am only an egg", which is an admittedly dated reference that I hope someone will get, but my suspicion is that with the collisions in terminology, it would be wise for some Old One to put a citation on each component: the reference specification for that particular thing. Obviously, the XHTML and XML DOMs aren't going to be the same specification (consciously avoiding the overloaded words "document" and "object").

As a writing convention, I'd like to suggest that we go overboard, if need be, to be sure each new reference to a term ties to a citation, even if it is just <ref>W3C foo specification for bar</ref>, repeated many times. Howard C. Berkowitz 19:36, 12 August 2008 (CDT)

Troubleshooting

I agree that there's a conceptual benefit to

Ajax also separates the functionality of web pages by combining different elements in different ways. For example, JavaScript on the client-side browser is combined with XMLHttp to enable communication between client and server browsers. Then any server-side program or scripting language allows the programmer to quickly respond to client requests in a language and format they are familiar with

If there is a problem, and there are different languages and infrastructure at both ends, what is the troubleshooting procedure if the programmers at both ends are not familiar with one another's environment? Down in the network layer, I can put Wireshark on the line and get a packet trace that gives me an idea of the exchanges. Is there an equivalent debugger for Ajax? Howard C. Berkowitz 15:21, 15 August 2008 (CDT)