Wikipedia:Articles for deletion/AJAST (programming) Source: en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/AJAST_(programming)

The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.

The result was delete. BJ^Talk 03:42, 14 July 2009 (UTC)[reply]

AJAST (programming) (edit | talk | history | protect | delete | links | watch | logs | views) (delete) – (View log)

Not at all notable. The term was coined in a blog post by a random web developer, and doesn't even have any mainstream use. Also, seems to be just another variation of Ajax, which already has its own article (in which this very technique is mentioned). If anything, the technique should be further discussed in the Ajax article, but it doesn't need its own. — ^FatalError 20:38, 6 July 2009 (UTC)[reply]

• Delete - does not appear to be a widely used term. Possibly the technique of inserting script tags should be discussed in the AJAX article, if it is not already. Artw (talk) 23:02, 6 July 2009 (UTC)[reply]
• Note: This debate has been included in the list of Software-related deletion discussions. -- TexasAndroid (talk) 12:07, 7 July 2009 (UTC)[reply]
• Rename to Script tag injection, JSON injection or another relevant name. While the term AJAST is itself not widespread, the described technique is, and its different to AJAX so it should get its own detailed article.Diego (talk) 12:46, 7 July 2009 (UTC)[reply]
  • Comment: First of all, the very fact that the term is not widespread is reason enough to have it deleted. And second, it is Ajax. The very section that you linked to says dynamic script tags is one method of retrieving data. Either way, I think it just needs to be discussed more in the Ajax article; it doesn't need its own article. — ^FatalError 21:00, 7 July 2009 (UTC)[reply]

• Delete unless someone creates an article for AJAIF (Asynchronous JavaScript and I-Frames), AJAD (Asynchronous JavaScript and Document.load), AJAF (Asynchronous JavaScript and Flash files)... --Quilokos (talk) 01:09, 11 July 2009 (UTC)[reply]
• I'll take the minority opinion and say Weak Keep. A google search shows that the term has been used in several places, including several sources that appear to be very reliable. Also keep as the concept is worthy of an article, even if the name is not. Gosox5555 (talk) 03:24, 11 July 2009 (UTC)[reply]
  • I would like to argue about going by Google on this one. The first 7 hits on Google seem to be the only ones pertaining to this article; one being an error report of one of the library's users, one being the main site for the library, one being a blog on the person that coined AJAST, and the other four being the Wikipedia article. The rest of the 1,009,993 hits on Google seem to pertain to a foreign name/word, a Java app, and various other one time uses. This article seems to be blatant advertisement for a library, worded in a way to make it sound like it's about a web development technique.
  • Alexa comes up with the AJAST.org site ranked 7 millionth on the web with an average of 2 hits in the last three months. (http://www.alexa.com/siteinfo/ajast.org)
  • This article was created 3 months ago by a new user with no previous edits. The article's content has been added by anonymous users with no other contributions.
  • The article states, "Like Ajax, AJAST is used to create interactive web applications or rich Internet applications in cases where data access is needed from a remote host which violates the same origin policy of Ajax." AJAX doesn't have a same origin policy; XMLHttpRequest did because of Microsoft. The level 2 W3C specs of XMLHttpRequest doesn't require the same origin policy. FireFox added support for this in 3.5. Microsoft IE8 has the XDomainRequest object instead of supporting the level 2 specs.
  • Saying the AJAST technique deserves its own article is saying the JavaScript/I-Frames technique deserves one (I could write a lot on this considering not many user agents support file uploads via XMLHttpRequest yet), the JavaScript/Document.load technique deserves one, the JavaScript/Flash technique deserves one (look at SWFUpload), and all the other methods.
  • I suggest its content be moved to the AJAX article. And if AJAX isn't suppose to be the catch all phrase for the single concept of creating Internet protocol requests through client-side scripting, then I suggest a main article be made about that instead of all the possible ways to do such a thing. --Quilokos (talk) 06:50, 11 July 2009 (UTC)[reply]
• Delete - 'marketing acronym hell' generated largely for marketing purposes. Or merge someplace. Wikipedia-wise: Wikipedia:NOTDICTIONARY & WP:NOTMANUAL. Web-business-wise, AJAX, and so on are meant to look sexier than 'javascript solution for servers and browsers talking over http'. But in the end it is just javascript and HTTP, or just something sold under 'AJAblah'. These could perhaps collected as mentions under http://en.wikipedia.orghttps://demo.azizisearch.com/lite/wikipedia/page/Ajax_(programming) or someplace. Indeed it seems there is a lot of noise with these pseudo-technique acronyms flying about. Casimirpo (talk) 20:40, 12 July 2009 (UTC)[reply]

I noticed the following articles also exist: AXAH (0 bytes), AHAH (32), AxsJAX (0), Ajax.NET (0), xajax (0), Sajax (1,575). They're all libraries relating to AJAX derivatives.

Based on the final say on this article, should all of these articles be nominated for deletion, too, if this one goes? They're even less notable than AJAST. --Quilokos (talk) 13:38, 11 July 2009 (UTC)[reply]

Good find. Yes, I'd say they should. I don't see why not. If this article is deleted, those (even less notable) articles should go as well. — ^FatalError 20:09, 11 July 2009 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.