I have heard about AJAX for years but I never felt the need or the intrest on learning it, I knew it was a mix of Javascript and XML but I never took the time to actully try to understand it, until now.
This is what I currently understand about AJAX. Ajax is not a language, it is just a combination of existing technologies, basically JavaScript and XML (and possibly HTML and CSS) and uses the XMLHttpRequest to comunicate with the server in the background to update/load only parts of a page instead of reloading the whole page.
Things I don't fully understand.
1- Is there any AJAX documentation or API that I can refer to to see what functions/options AJAX offers?
2- Why every book in Amazon seem to be old? Is this because AJAX this is not a language and doesn't change?
3- I read the tutorial at www.w3schools.com and I was wondering if what is shown in this tutorial is basically all AJAX can do, basically, Request and respoind to a server?
Again, all I'm trying to understand here is basically how much of a learning I still need to go through in order to have a better understanding about AJAX.
Thanks a lot
Long story short: AJAX lets you make calls to the server without submitting a form or navigating the page. That is all it does.
Originally it stood for "Asynchronous Javascript And XML" because the XMLHttpRequest object was designed to receive updates in XML format. Microsoft added the object so that the Outlook Web interface could pop up new mail alerts by polling the server.
Since then, most programmers have eschewed the use of XML as the data exchange protocol and rely on JSON instead. JSON is far easier to parse and work with.
While I could go through some examples of the low level XMLHttpRequest interactions, other sources have that well covered.
Instead, I'm going to give you a bit of advice. Study Javascript and consider learning the jQuery API. JQuery forces functional programming and makes common activities like AJAX calls super-simple to accomplish. You'll learn to be a better Javascript programmer because of it and will hopefully learn to make your sites more interactive thanks to the power that background server requests bring to the table.
Although the 'X' in AJAX stands for XML, applications today are more likely to use JSON encoding over XML as the return data can be evaluated directly by the browsers JavaScript interpreter. The core enabling JavaScript object is XMLHttpRequest which was originally developed as an ActiveX component for IE 5. It has since become a standard object in all web browser implementations. You can read about the core functionality here: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest.
Your best bet would be to research modern JavaScript frameworks such as jQuery. http://www.jquery.com/ for information on how to use AJAX technology within your web applications.
This is a bit of a vague question, and likely to get some down votes, but I think it's specific enough that it does warrant some information.
In a nutshell, AJAX is a why for JavaScript to request information asynchronously. The XML portion is a bit of a misnomer, since you don't have to explicitly deal with XML at all. Frequently, you'll use AJAX requests to read in JSON information (since it's so easy to parse and use).
AJAX isn't really a language, or even a framework. It's a technique. It is made possible by the XMLHttpRequest class, along with some related technologies. Since it isn't 100% consistent across all browsers, it is usually best to use a third-party library. jQuery and most other larger frameworks usually have it built in. You can also find some small AJAX-only libraries, like this XMLHttpRequest project on Github.
Every book on the technique is probably old because nothing has really changed substantially since the technique starting becoming popular. I've been using it for at least the past 3-5 years, and not much has changed (other than a bit more standardization in modern browsers).
The respond and request is basically all AJAX can do. However, that enables a whole world of possibilities. Long story short, it's a way to communicate with the server without having to refresh the page, allowing for much smoother UI and UX.
The simplest way to think about it is that it lets you fetch data without a page reload.
Think about how Google Maps loads in bits of the map as you drag around - it clearly doesn't load the map for the whole world.
In older map sites you clicked a left, right, up or down arrow, the page reloaded and the new data was shown.
AJAX lets you make pages feel much faster and smoother.
Technically JSON is usually used instead of XML as it's more Javascripty than XML.
Most sites likely use it somewhere or other, ranging from loading sidebar widgets after the main content, to the whole app, like Gmail.
Related
I have been attempting to scrape and eventually parse some data(specifically availabilities and price) from hostels.com, for example http://www.hostels.com/hosteldetails.php/HostelNumber.11890. The problem is, once you select the number of nights and select "book now" nothing is passed through the URL string(its all done through Ajax, I belive) I cant go directly to a specific date or time frame.
I have attempted browser emulators such as Selenium, IRobotSoft and FakeApp and although I did get Selenium and Fake to do much of the work capturing the full source, it was ugly and still tedious when having to scrape(and parse with other software) multiple pages a day.
I have also tried HTML DOM Parser, PHP Scriptable Web Browser, HTMLUnit, cScrape.php, Crowbar. Either they couldn't handle the Ajax or I had no luck getting even them to run.
Ideally I would like something that can run from a server, with as few dependencies as possible, but at this point I would just like to get it running.
Now after spending many hours trying to get this working. I still feel I'm not sure where to begin. Can someone just point me in the right direction?. Should I go back and spend more time with HTMLUnit? what would be the best practice for a site like this?
Thanks
I'm really into Node.js atm (server-side javascript, in case you're not familiar), so that's what I'm recommending. What's awesome about using it to scrape sites is you can use jQuery or whatever your favorite JS framework is to do all the work of parsing for the info you want! See the following resources to get started:
http://blog.dtrejo.com/scraping-made-easy-with-jquery-and-selectorga
https://github.com/tmpvar/jsdom
https://github.com/chriso/node.io/wiki/Scraping
https://github.com/joshfire/node-crawler
The page you are referring to does not seem to be using AJAX. Instead what you are referring to as AJAX is a POST request (as opposed to stuff passed in the url, which is a GET request). I suggest you read up on difference between them. Try to understand what going on, it is more important than relying on some third-party tool which might turn out to be very inflexible.
Install Firebug and watch which variables are sent in the POST request.
Now do the same thing in your favourite programming language. Parse the response HTML for the POST request for the necessary information.
Also, +1 for the effort of trying so many different solutions and not giving up.
I've found Celerity (http://celerity.rubyforge.org), a JRuby library that uses HTMLUnit under the hood, to be a very robust solution for "data acquisition via the Web".
Celerity being Ruby, I found, was much faster to develop with in comparison to full blown Java (HTMLUnit). Also, due to Celerity's "wrapping" of HTMLUnit -- I was able to drop down to HTMLUnit as I needed to do some heavier lifting.
I've had success with sites that are rich in DHTML, as well as utilize Ajax; and while I made have used some sleep() calls to wait on the Ajax responses -- everything worked as expected.
Give it a try!
This is based on my full question. I decided to take it in parts and see if I still can't get any help.
What are all the options we've got for client-side frameworks?
I've heard mostly about prototype and jquery, but I know there are way too many options out there beyond those two, and I don't know if they handle async download.
From all of them which one is the fastest, both on the DHTML (interface) and the AJAX (download)? What are the advantages it has over the others?
What is it that you want to do?
DHTML is Dynamic HTML - which gives you the ability to set properties of HTML elements dynamically, at runtime while the page is displayed in a browser. A script can change the content of a div, the src of an <img> tag, the style of a paragraph.
AJAX is Asynchronous Javascript and XML, and as a term was initially coined to describe the practice of using Javascript running in the browser to asynchronously download data formatted in XML, and then do stuff with that data in the execution context of the browser's web page. For example, update a table. The term "Ajax" has now expanded its meaning to encompass the async download of data of any form, not just XML, into the browser. Very often web apps will download data in json format, or csv, or html, or... ? AJAX has very little to do with "graphical frameworks". It can act as a complementary technology. For example, you could download a set of URLs, or a set of image properties, via AJAX.
jQuery is a library of javascript functions that makes it easier to do "DHTML" -type things in a cross-browser environment.
You asked, which is fastest for dealing with images?, but you haven't described what you're really after, what exactly "dealing with images" means. Regardless, I think the answer is mu, because #1, these things are independent of graphical frameworks, and #2, they are not easily comparable. You are asking for a comparison between apples, hammers, and music.
But, maybe you're not really asking about graphical frameworks. The title of your question seems to be completely unrelated to the text you've posted - it suggests you want to download and cache a few images. If that's what you're after, you can do that via DHTML or jQuery. Any modern browser will automatically cache these images for you; you don't need to do anything special. But in all cases you'll be relying on the browser's communication infrastructure to do the download, and so there will be no speed differential. They will download as fast as the browser and the network allows.
Addendum
I think maybe your focus on speed is misplaced. What do you really want to do? Is speed a problem now? Seems like you are just getting started. Seems like what you really want is to learn the landscape a little better, figure out what is possible, rather than what is fast.
For playing videos in a browser, check out flowplayer - a flash video player that can be scripted with javascript/jQuery.
Many years back, I was told that Javascript was harmful, and I remember being annoyed with endless popup when I right-clicked an image to download it.
Now it seems suddenly that Javascript is great, and you can do a lot of things with it to let users have native-like web application experience.
I admit I have missed 6-7 years of Javascript literature, so I hope to start anew with SO kickstarting me to understand the following:
Is Javascript mainly concerned about user interface i.e. smoothen interaction between application and users and not about logic processing, number crunching or form processing etc.?
Can Javascript write to local hard drive (besides cookies)?
Can Javascript web application run with Javascript capabilities in browsers turned off? (I would think outright no, but an article on Adaptive Path said 'maybe')
Is AJAX illegal to use due to Eolas patent claim? Is it worth it spending effort learning it when the future is not secure? (I know AJAX is not Javascript)
Thanks. Hoping for enlightenment.
Yes. JavaSscript is usually used to enhance the user's experience and make the site easier to use. It is also possible to delegate validation tasks and the like to JavaScript, however (though this should never absolve the server of its responsibility to check input).
No.
That depends on how the application is written. If it's done properly, then the JavaScript will merely enhance the interface, and the application will still work without it; this is called progressive enhancement.
Not at all. AJAX is used extensively on this very site!
One reason for the resurgence of popularity for JavaScript lately is the emergence of several frameworks. These make the process of writing JavaScript much, much easier, allowing tasks that would previously have been horribly complex to be implemented with minimal time and effort. The most popular of these is jQuery, which is a good place to start if you're intending to get in on the action.
Overall, JavaScript is a very powerful tool that allows you to create very rich interfaces. Well worth learning.
Yes, Javascript is all about client side processing, but also about AJAX where it calls back to the server asynchronously so that users do not see pages reloading.
No
No, but there are ways to gracefully degrade the experience for non javascript users. It requires carefult planning however.
No, that lawsuit was just about the browser technology that enables it. As a developer you dont have to worry about that.
Can Javascript write to local hard drive (besides cookies)?
Not really. However, as HTML5 support becomes more widespread you'll be able to use things like Web Storage and Web SQL. You won't be able to write arbitrary files on the user's hard drive, but using those two technologies you'll be able to persistently store and access data.
Can Javascript web application run
with Javascript capabilities in
browsers turned off? (I would think
outright no, but an article on
Adaptive Path said 'maybe')
It really depends on how you define "web application." You can write web apps without using Javascript for anything but UI candy, in which case you can degrade gracefully without without it. However, it's also possible to write web apps that rely heavily (entirely, even) on Javascript, which will utterly fail without it.
Is AJAX illegal to use due to Eolas
patent claim? Is it worth it spending
effort learning it when the future is
not secure?
I'm not a lawyer, but I'd agree with the other answers -- you shouldn't worry about it. I'm certainly still writing AJAX stuff :)
Is Javascript mainly concerned about
user interface i.e. smoothen
interaction between application and
users and not about logic processing,
number crunching or form processing
etc.?
It's about both. And more than that.
Javascript has really come into its own in the past few years. Browsers have gotten a lot faster at executing it quickly, and people have been figuring out new ways to use the language itself to its full potential. You can really start using Javascript like a full-out application programming language, and not just to write little scripts that animate something or validate input.
If you're just getting back into the language and haven't read Crockford yet, I would highly recommend it. It's a great starting point to realizing the full potential of Javascript.
Edit: Some good Crockford Links
Javascript: The World's Most Misunderstood Programming Language
Javascript: The Good Parts (This is a presentation. Crockford also wrote a book by the same name that I haven't read myself, but I hear it's quite excellent.)
It's mainly for UI, but it can be used to save server-time on some operations (for example, Mathoverflow uses it to render LaTeX) and it's becoming popular to do so. But when you do this, you need to be respectful of the end-users time, because JavaScript can hold up some browsers, while it runs. But in general, it's a good and interesting idea.
Not without permission
If it's written correctly, it can. It's called "Graceful degredation" (some other variant terms exist, but the idea is the same). The basic idea is that you have it such that the JavaScript fails 'gracefully', and links that would normally get handled via JavaScript (i.e. to do some inline next-paging) will navigate to a 'backup' page that shows the relevant content.
I don't know about that, but AJAX can be implemented in different ways, XMLHTTPRequest is just one of them :) (And the most common, and suitable). Generally you like a library do this for you anyway (jQuery, or otherwise) but you can do it yourself for fun.
Yes, in my experience JavaScript is generally used to create a streamlined interface and relays information from the client to a server application for processing.
Yes, if the browser is configured to allow this (most aren't by default since this can be very dangerous).
No, JavaScript will not run if the browser is configured to have JavaScript disabled.
I wouldn't forgo learning JavaScript for this reason - as for the legality of the whole thing I wouldn't feel comfortable advising you about this. Still I think JavaScript is worth learning in spite of this situation.
The Eolas patent covers the embedding of objects in a HTML document (see US patent 5,838,906 titled "Distributed hypermedia method for automatically invoking external application providing interaction and display of embedded objects within a hypermedia document") ... this scope would not seem to include AJAX as a suite of technologies (being essentially scripting in a document to load content elements).
Partial answers:
I think all the security vulnerabilities associated with javascript have been fixed? IIRC the problems weren't with javascript, they were with particular browser's implementation of javascript.
I wouldn't worry about any patent claims on the AJAX technology. Patent sueing and counter-sueing is common place in the software world and invariably ends up with the affected parties licencing each other's technology. AJAX is not going anywhere :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm building a web application with the Zend Framework. I have wanted to include some AJAX type forms and modal boxes, but I also want my application to be as accessible as possible. I want my application to be enhanced by AJAX, but also fully functional without AJAX.
So as a general guideline...when should I not use AJAX? I mean, should I bother making my application usable without AJAX? Or does everyone have AJAX enabled browsers these days?
If you mean "accessible" in the ADA sense, AJAX is usually a no-no - your site should provide all its content and core functionality using only standard (X)HTML and CSS. Any javascript used should merely extend the core functionality, and your site should be coded to work elegantly in the absence of a javascript-enabled browser.
Examples: if you want a user to click on a thumbnail and get a full-size version of the image as a result, you can make the thumbnail a link. Then, the onclick event will fire a JQuery method that cancels the navigation behavior of the link and pops up a JQuery floating div to show the image on the current page. If the user's browser doesn't support JavaScript, the onclick event will never fire, and the user will be presented the image in a new page. The core functionality is the same with or without scripting.
EDIT: Skeleton example, sans JQuery-specific code.
<html>
<body>
Some URL
</body>
</html>
To cancel the navigation operation, simply make sure that the method invoked by the onclick event returns false at the end.
A neat example of the JQuery image popup I described can be found here.
Use ajax if it adds value for the user.
If the ajax version adds a lot more value than the non-ajax version then it might justify the expense to develop a solution that caters for both clients. Generally i wouldn't recommend doing the extra work (remember.. more code results in more maintenance).
I think one point is missing here: Use Ajax only for content any search engine does not need to know.
98% of users will have AJAX enabled browsers.
A significant percentage of those people won't have it turned on when they first visit your site though (or at all, ever perhaps).
I've seen websites that look like a blank page without javascript on. Don't be one of them. Javascript to fix layout issues is a horrible idea in my opinion. Make sure it loads and looks ok without Javascript. If people can atleast see what they are missing out on, they are likely to switch it on, but if your website looks like it's just broken, then...
I often have noscript block Flash and JavaScript until I make the decision that your site is worthy.
So be sure to tell me what I'm missing if I have JavaScript turned off.
It depends on the complexity of your web application.
If you can, having it functional with javascript disabled is great, because it makes your application usable not only by users on js-disabled browsers but also by robots. The day you decide to write an application to automatically fill your forms, for example, you don't have to write an API from the ground up.
In any case, do not user AJAX for EVERYTHING! I have just inherited a project that basically consists of a single page that is populated by a ton of AJAX calls and I can tell that you just thinking about it gives me physical pain. I guess the original developer didn't like the concept of using the back/forward button in the browser as a mean of navigation.
Unless you are targeting mobile devices or other non-standard web users, you can be fairly sure that the vast majority has Javascript enabled, because most major sites (including SO) rely heavily on it.
I want my application to be as accessible as possible.
You can do things like rendering your modals and forms as a page that can operate standalone.
The AJAX version pulls the template into a modal/container, the standalone version checks if it's an AJAX request and renders the page including the header/footer (this can occur from the same URL if planned well)
The AJAX version intercepts the submit and does AJAX submission then provides an inline thank you, the non-AJAX opens a thank you page. Once again you can likely use the same pages for each of these functions if thought out correctly.
Reusing templates and URL's helps avoid additional maintenance for the AJAX/non-AJAX versions.
I want my application to be enhanced by AJAX, but also fully
functional without AJAX.
Thinking through the structure of your URLs and templates can go a long way towards this, if you make most of your AJAX requests pull in completely rendered templates (as opposed to just data) then you can usually use the same URL to serve both versions. You just serve only the guts of the modal/form to the AJAX request and the entire page to a regular request.
When should I not use AJAX?
You should not use AJAX if doing so will cause a poor experience for a significant portion of your user base (there are of course techniques that can be used to mitigate this)
You should not use AJAX if the development time associated with implementing it will be too significant to justify the improvements in user experience
You should not use AJAX for content which has significant SEO value without implementing an appropriate fallback that allows it to be indexed (Crawlers are improving constantly but it's still a good idea)
I mean, should I bother making my application usable without AJAX? Or
does everyone have AJAX enabled browsers these days?
I'd say a lot of the time it's unnecessary as the vast majority of users will have AJAX enabled browsers, but there are scenarios where it's critical such as SEO optimization or when a large portion of your user base is likely to use browsers that are less likely to support Javascript as well or where they're likely to have Javascript/AJAX disabled.
A few examples of these scenarios:
A website for a company or government that uses an outdated browser as standard
A website where a large portion of the users may be disabled in a manner that may negatively impact their experience such as a website for vision or motor-skill impaired people may be negatively impacted by updating content via AJAX especially if it occurs rapidly.
A site accessed regularly via a less common device or browser that will cause a negative impact to a large portion of users
So what should I do?
Think about who is going to be using the site, how they're going to access it, and what they're going to access it with. Also try to think about not just the present but also the future.
Design the site in a manner that will cater to the majority of these users.
Think who will gain and who will loose based on my decision to use AJAX and if in doubt have a look at your analytics data to help weigh up the decision and if you lack the data it may be worth updating your tracking and obtaining a sample to aid the decision
Think does my decision to use AJAX cause any contradictions with core requirements for this project
Use AJAX to enhance content where possible as opposed to making it mandatory ie the content should work with or without JS/AJAX
Consider the additional development time involved with the use of AJAX (if any)
My experience is, we should use ajax after it works without it. For a couple of reasons.
First, if something breaks in the ajax, and you don't have it working without it, the site simply doesn't work. For example, a product list with pagination. It should work with the links alone, then use ajax when possible.
Second, for site indexing and accessibility. If it works without ajax, it's better.
And it's easier to break something (even if only for a few moments). A bad piece of code, an uncaught exception, an external library not loaded, a blocking browser extension,...
After everything works without ajax, its quite easier to add ajax. Just have the ajax catch the action, add ajax=1 and when returning the result, return only what you need if ajax=1, otherwise return everything.
In the product list example, I would only return the products and pagination html, and add to the correct div. If ajax stops working, the whole page is loaded and the customer sees the second page as it loads.
Ajax adds a lot of value to UX. If done right, the user gets a great feel when using the site, and better data usage because it doesn't load the whole page everytime.
But the question being "when not to use ajax", I would say, you should always count on it to improve UX but not rely on it for the site to work (as other users also mentioned). And nowadays we need both, great code and great user experience.
My practice is to use two main pages, let's say index.py and ajax.py. First one is responsible for generating full website, and is default target of forms. Other one generates only output specific for adequate ajax query. Logic behind both of them is the same, only the method of generating output is a bit different.
In jquery I simply change action parameter when sending a request. It works both with and without ajax, although long time have I not seen someone with disabled js and ajax.
I like the thought of coding your application without JavaScript / Ajax and then adding it in later to enhance the UI without depriving users of functionality just because they don't have JavaScript enabled. I read about this in Pro ASP.NET MVC but I think I've seen it elsewhere in reading about unobtrusive JavaScript.
You should not make your service bloated with web 2.0 effects like accordion, modal/etc forms, image zoomers etc.
Use modern tech smarter (AJAX is one of them) and your users will be happy. Do not fear AJAX -- this is very good thing to make user expirience smooth. But don't do things because you like it - do them because your user need it ;)
When you want to make a website that looks like a website, not a fugly imitation of a desktop app?
You should not use AJAX or JavaScript in cases where:
your system needs to be accessible
your system needs to be search friendly
However, by using a modern JS framework with some solid "unobtrusive" practices, you can progressively enhance pages so that they remain accessible and search-friendly while offering a slick UI to users.
This totally depends on the type of application or feature you're developing. If it is crucial that the application is accessible despite the absence of Javascript, then it would help to have fallback methods (i.e. alternative forms) to allow your user to use said functionality/feature. For that, it will require you to invest some of your time developing methods for collecting information not just using client-side scripts but also on the server-side.
For miscellaneous features that only serves to enhance user experience, it's mostly not worth it to develop fallback methods.
There's no reason to totally not use AJAX. AJAX helps minimize your traffic after all.
You can if you wish always use AJAX and update the history state using Push State or for more compatibility use the hash with none HTML5 compliant browsers.
with this you can have your server load a page then javascript read the document.hash and resume the state of the application base on the state of the hash.
for example i got to /index.html i click into something for example a client to open the view client you can change the hash to #/view/client/{client_id}/ then if a reload or go back using the browser the hash with change and you can use the onhashchanged event to capture it and match the sites state to the new hash then same if a favorite a certain state
A couple of other scenarios where one may be better off NOT using AJAX:
Letting someone to log into the web application. Use traditional form submit instead.
Searching and returning more than a few 100 rows from the database. Either break the process down or let the server side language handle it.
This might be a stupid or obvious question, but our whole site is rendered using XSLT to transform xml which is created on the fly from database queries and other pieces. Im starting to push a lot of ajax into the site to make it more dynamic, is there a good tutorial on xslt and ajax?
Are you using XSLT on the server or in the browsers?
Modern browsers now have support for XML transformations from within the browser, one way is using AJAX to fetch the XML along with its stylesheet. You can then offload the processing of stylesheets to the clients machines. Be sure to cache the stylesheet and perhaps even send compressed XML.
The coding should be straight forward if you already know how to do AJAX. I worked on a system like this 5 years ago and it is a viable way to go.
I would definetly agree with a previous commentor who shuddered at the thought of XSLT doing your heavy lifting. That is not going to be all that performant. Don't get me wrong, I like XSL a lot, but ...
Not as much of a tutorial, but the folks at Mulberry Tech (no idea what they do, or who they are) maintain a series of Quick Reference Guides for XSLT (and plenty others) that I find invaluable.
http://www.mulberrytech.com/quickref/
hope this helps...
I think most of the answers are missing what the OP is asking for. I think the OP is asking if there is a way to get the XSLT generated HTML using AJAX.
I am taking this approach on Umbraco.
Create the XSLT Macro that generates the HTML
Place the XSLT Macro in a blank page
Call page with AJAX
Replace the existing HTML content
our whole site is rendered using XSLT to transform xml
That thought makes me shudder. I've worked on two sites that have used XSLT to do heavy lifting in dynamically producing frequently accessed pages, and in both cases it required more development effort and CPU time per access than it was worth.
Irregardless, www.w3schools.com has plenty of good tutorials on many web technologies. They even have tests.
If you want to do AJAX while maintaining support for multiple web browsers I would strongly recommend that you check out: JQuery, Prototype, and Dojo
I think JQuery is the best but I will leave that determination up to you.
I've used this technique extensively, both on client and server side. My experience has been that it performs adequately in most scenarios (but then I'm contrasting its server-side performance with VBScript in ASP pages).
Where performance is an issue, it's very important to take XML parsing and XSLT compilation out of the operation wherever possible. If you have a client-side method that uses XSLT to dynamically render an element in the page, make sure it's not loading and compiling the XSLT every time it's called. If you're using server-side XSLT, cache the XSLT processor object in whatever collection your server environment supports.
You can get significantly better client-side performance by using Javascript and JSON instead of XML and XSLT. I haven't benchmarked it, but I'd bet that the biggest performance gain comes out of the fact that parsing JSON is much less CPU-intensive than parsing XML.
Try using tox as an example. There isn't a tutorial, but if you take a look at the example provided, it is well commented and includes AJAX.