Talk:Ajax (web technology): Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Pat Palmer
(archived statement and an explanation)
imported>Pat Palmer
m (OK, we actually agree that this article needs a LOT of improvement; no need to wait at all!)
Line 19: Line 19:


::::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. --[[User:Tom Morris|Tom Morris]] 18:36, 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. --[[User:Tom Morris|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.[[User:Pat Palmer|Pat Palmer]] 19:17, 12 August 2008 (CDT)


==DOM, XHTML and XML confusion==
==DOM, XHTML and XML confusion==

Revision as of 19:17, 12 August 2008

This article is developing and not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
To learn how to update the categories for this article, see here. To update categories, edit the metadata template.
 Definition JavaScript programming technique to communicate with the server without reloading the webpage. [d] [e]
Checklist and Archives
 Workgroup category Computers [Categories OK]
 Talk Archive none  English language variant British English

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)

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.[1].

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)

  1. Zucker, Daniel F. (September + October 2007)), "Fresh: nuts and bolts: What does AJAX mean for you?", interactions 14 (5)