I have a project which is heavily JavaScript based (e.g. node.js, backbone.js, etc.). I'm using hashbang urls like /#!/about and have read the google ajax crawlable spec. I've done a wee bit of headless UI testing with zombie and can easily conceive of how this could be done by setting a slight delay and returning static content back to the google bot. But I don't really want to implement this from scratch and was hoping there was a pre-existing library that fits in with my stack. Know of one?
EDIT: At time of writing I don't think this exists. However, rendering using backbone (or similar) on server and client is a plausible approach (even if not a direct answer). So I'm going to mark that as answer although there may be better solutions in the future.
Just to chime in, I ran into this issue too (I have very ajax/js heavy site), and I found this which may be of interest:
crawlme
I have yet to try it but it sounds like it will make the whole process a piece of cake if it works as advertised! it's a piece of connect/express middleware that is simply inserted before any calls to pages, and apparently takes care of the rest.
Edit:
Having tried crawlme, I had some success, but the backend headless browser it uses (zombie.js) was failing with some of my javascript content, likely because it works by emulting the DOM and thus won't be perfect.
Sooo, instead I got hold of a full webkit based headless browser, phantomjs, and a set of node linkings for it, like this:
npm install phantomjs node-phantom
I then created my own script similar to crawlme, but using phantomjs instead of zombie.js. This approach seems to work perfectly, and will render every single one of my ajax based pages perfectly. the script I wrote to pull this off can be found here. to use it, simply:
var googlebot = require("./path-to-file");
and then before any other calls to your app (this is using express but should work with just connect too:
app.use(googlebot());
the source is realtively simple minus a couple of regexps, so have a gander :)
Result: AJAX heavy node.js/connect/express based website can be crawled by the googlebot.
There is one implementation using node.js and Backbone.js on the server and browser
https://github.com/Morriz/backbone-everywhere
crawleable nodejs module seems to fit this purpose: https://npmjs.org/package/crawlable and example of such SPA that can be rendered server-side in node https://github.com/trupin/crawlable-todos
Backbone looks interesting:
http://documentcloud.github.com/backbone/
http://lostechies.com/derickbailey/2011/09/26/seo-and-accessibility-with-html5-pushstate-part-1-introducing-pushstate/
Related
When I googled about React.js what I got is: React.js is a Framework that is used to create user interfaces. If a particular part of the website is frequently updated that means we can use react. But I am confused that Ajax has been used for this only. We can update a part of site using Ajax without page refresh. For templating we would be using handlebars and mustache. Could somebody explain me in what ways react is different from Ajax and why we should use it.
In short, React uses AJAX. They are not related in the way you're asking.
Keep reading for a crash course in what React is, what AJAX is, and how they are used to make modern web applications.
This is probably a more simple explanation than you're looking for, but for anyone else who may be confused...
AJAX and Airplanes
Think about an Airplane. The most important part of an airplane is that it flies. But an airplane also has wheels. And the wheels serve a very important purpose, because without them the airplane would never fly or land, and despite all the awesome stuff a plane could do in the air, it wouldn't matter without wheels.
This is the same relationship that React has with AJAX. React is the airplane, and AJAX are the wheels. But, ya know, other things have wheels too. Tractors, cars, even some boats have wheels, and they're all very important, and crippled without wheels. So too is AJAX to other web technologies, but when you're talking about airplanes, its wheels are usually the farthest thing from your mind.
So React is to AJAX, what an Airplane is to Wheels.
But let's talk about AJAX. What is it? Why is it so important? How it is used in websites today. Then I'll show how it's used by React. Then show you what React does that's so impressive, it makes you forget about AJAX - Like an Airplane to its wheels.
Remember Websites in the 90's?
When you clicked anything, a new page would have to load to show the effect of your click - even if it was nothing. Here's an awesome example. Go to that page and click around... See how clicks whisk you away to a completely different page? That is the Internet before AJAX.
Now, take a look at this very page: next to each answer is an Up Arrow... Go ahead and click one of them... Notice the page doesn't reload, but you are given feedback: the arrow turns Orange. This may seem insignificant, but it represents big advancements in web technology: AJAX, or more accurately: the AJAX approach to web development.
The AJAX approach allows that to happen! And this is no big deal now; it's so intrinsic to the web experience, it's difficult to imagine the Internet without it.
AJAX and a Clock Face
A good analogy of the AJAX methodology, and how it changed the web is a simple wrist watch, or a wall clock... Imagine the minute, hour and second hands moving around the clock's face to show time. Now, suppose every movement of the second hand caused the entire clock to be destroyed and rebuilt?
All that effort of destroying and rebuilding just to show a tiny change?! Well, that would be an outrageous waste of resources, and that was the Internet of the 90's. Thankfully, we have AJAX now. Just as a clock seamlessly displays the time, AJAX allows web pages to show changes in data immediately, without the page needing to be refreshed; you click an up arrow, and it turns orange. No page reload needed!
Originally, AJAX was just the name given to using existing technologies together to show simple updates to the user, but it has become so intrinsic to the web experience that unless you know what you're doing, you wouldn't even know you're using it. For instance, fetch is the preferred way to accomplish the AJAX approach since 2015. Before that it was XMLHttpRequest - even though JSON was used to transfer data more often because it's less verbose. JQuery is the only web technology that actually says AJAX ($.ajax()) to my knowledge, but you typically wouldn't (and shouldn't unless you really know what you're doing) use JQuery with a react application.
And AJAX works just like webpages:
The user performs an action (like pressing an up arrow)
A client (A Web Browser like Firefox) requests data from a server (like the Stack Overflow (SO) Server).
The server processes the request (updates the database to record the upvote).
The server sends a response back to the client that says if the action was successful or not.
Finally, some of the code already loaded into the web page, decides how to process this new information (in our example, javascript would add a class to the up-arrow and CSS rules would dictate that elements with that class are orange).
The user only sees that the arrow is orange. All the other steps are hidden so it seems like one seamless, responsive action.
Single-Page Applications
Since we're not rebuilding the entire page with every click, you can keep information about the site stored in the browser. This can be used throughout your entire visit and future visits.
The first time you visit Stack Overflow, all of the CSS, JS, and HTML is loaded. These three languages define the style (CSS), behavior (JS), and structure (HTML) of the data sent back and forth from the server. And guess how that data is sent! AJAX.
This is how most of the web works now. Google, Facebook, Amazon, Youtube, Reddit, every site built with WordPress and WIX, even Stack Overflow - they all use this basic paradigm for delivering their sites to users efficiently. The difference comes in how the Single-page application is built and managed...
React.js
React is a javascript library for building and maintaining Single-Page Applications.
But that's not even that big of a deal. The big deal about React is how it allows you to build applications...
Basically, you build things separately, then put them together: Components come together to form an Application. So take a look at this totally plausible but fake code for all the answers on this page:
answerArray.map(a => <Answer answerData={a}></Answer>)
This is one line that shows most of the information on this page. That is a big deal. The developers at Stack Overflow created their own component, called "Answer" and its only job is to show an Answer. You run that in a loop, and bam, all the intricacies of all the answers are abstracted, hidden in the Answer Component, which is completely separate from other components.
Now take a look at this:
<App>
<Header />
<LeftSidebar />
<Question>
{ answerArray.map(a => <Answer answerData={a} /> )}
</Question>
<RightSidebar />
<Footer/>
</App>
This is the whole Stack Overflow site.
Each tag (Header, Question, Answer, etc.) is a component. These components are completely separate and have self-contained code, but here they are used together to build the more complex application.
Composition
An important concept of React is composition, and we just defined it above. "Composition allows you to build more complex functionality by combining small and focused functions" (flaviocopes). Our Application is composed of smaller components.
It's also important to note that each component contains its own functionality. That means if the user clicks a button and a warning appears, the button and the code that makes the warning appear are in the same component.
Functional Programming
Surprise, we already defined this too. Functional programming, for our purposes, means 1. objects; and 2. how they behave; are in the same place. Like the button example above. Click a button, get a warning. And that's all in the same file.
This is different than pre-React development where all the buttons would be in one file, and all effects of the buttons would be in another. And this isn't necessarily a wrong way to do things, but for web development, it is easier to think in terms of self-contained building blocks, rather than widely dispersed tools that don't work by themselves.
Why you shouldn't care about Moustache and Handlebars
These two technologies have been cannibalized by React. Similar to how React uses AJAX but makes it easier, Moustache and Handlebars are already inside React, and you're using them all the time without even knowing it. And to me, that's ok. There are arguments to the contrary, and knowledge is never a bad thing, so investigate further if you want, but this is already long enough, so that's all I'll say about that.
Instead, I will tell you about 3 technologies you should care about.
What you should care about instead...
Node
The main point of Node.js is that it executes JavaScript outside a browser. Big whoop, right? Well, it turns out this is one of the most influential advancements for web developers ever. In fact, downloading Node is often done before downloading React.
Node is important for 2 huge reasons:
It lets you download other stuff
It lets you process JavaScript before sending it to a browser
I could write pages and pages about Node, but your takeaway from this should be "Node is important, I should be on the lookout for more knowledge about Node and how it relates to React and web development."
NPM
NPM does not stand for "Node Package Manager", but it should, because that's exactly what it does. React, SASS, Angular, Vue, pretty much everything mentioned here you will probably use npm to install and keep updated.
Webpack
Webpack is a "module bundler". It takes all your js and css files and writes them to one file so you only have to worry about writing one <script> tag.
Each React component will have at least one js file associated with it. Each component should have its own file too. Keeping track of all those files is very demanding. Webpack does it for you, it just makes life easier, so learn about it early and don't shy away from it.
This is something so inherent to React Apps that most of the time it will just be working and you won't even know it. For instance, create-react-app installs it automatically, and does not require you to do anything - same with Babel...
Babel
Translates all your code to ECMA5 so it can be read by most browsers and most versions of those browsers.
Again, this can be installed with npm, or if you just want to play around with React and not get too bogged down with the minutia like this, you can run create-react-app, and this will just work with automatic settings and will be out of your hair while you learn.
They make stuff easier
NPM, Webpack, Babel, and many other Node packages are only there to make your life easier. Building web apps require a lot of maintenance - or small, non-programming annoyances that typically you don't even need to think about.
Try not to be intimidated by new packages because wielding their power can mean countless hours devoted to more interesting things.
Conclusion
Hopefully, this post has helped you learn the difference between React, AJAX, and the ongoing nature of web application development. React and AJAX are not comparable, but React uses AJAX, or rather you - the developer - use AJAX in React to get data without the page needing to reload.
AJAX and other technologies were monumental to the advancement of web applications, but because of how absolutely essential they were to applications, they were assimilated into new technologies so much so that you don't even have to know about them to reap their benefits.
My goal was to correct some misconceptions on your path of learning; explain the "why" of the current state of web dev; and introduce technologies you didn't mention but should know about: Node, npm, Babel.
If you want to continue learning, I highly recommend doing a tutorial in React. I have done some at platform.ui.dev/, and enjoy their approach to learning and their payment structure (I haven't been paid to say this). Good luck out there, and I hope this was helpful.
Ajax is used to refresh a web page without having to reload it : it sends a request to the server, but typically the response is processed by the javascript that displays dynamically a new element on the browser without having to reload the entire page.
React is a javascript library that dynamically update the page with inferface components. The components are calculated either by javascript interactions or by an ajax request that go through the server. So ReactJS can also use Ajax requests to update the page.
Mustache and Handlebars are a bit different from ReactJS as the main goal is to transform a template in a component that will be displayed in a page. It can also use Ajax to get data (for getting templates or json datas).
Ajax
We are using Ajax to send http requests. And we can't re-render a particular area of the page(DOM) by using Ajax alone. We need jQuery to re-render the page after an ajax call came up with the response. Actually comparing jQuery + HTML and React.js is far better than comparing ajax and React.js.
React.js
The role of the react.js is dividing page(DOM) into small pieces (Components). ex:- Profile image area, Main Navigation, Sidebar, Textfield, Button. etc. from Big pieces to small pieces. Most importantly we can bind functionalities into these components. Example:- Let's assume users need a popup to upload a profile image by clicking on above "Profile image area". We can write a function to open a popup. And also we can write another function to upload profile image to the database. In this way we can use ajax inside the React.js
Please follow this tutorial.
To simply put, React is a JavaScript library built by Facebook. It is commonly looked as a framework because of its many extensions but the official docs label it as a library for building user interfaces. Ajax on the other hand is not a library or a framework or a language at all. Ajax is a technique used by programmers to call web APIs without having the flow of your code be interrupted at all. At the end of that day, your JavaScript code is run synchronously line by line and Ajax is run asynchronously within your synchronous code but in a way in which it will never pause your code from and have it wait for the API call to be sent and received. With Ajax, sending and receiving data is all done in the background so you won't have to worry about the delay that it takes to get that data. You can actually use Ajax in your React code. Ajax uses something called Fetch to actually call an API and you can use a variety of methods to handle the data that you receive from the API such as .then and .catch or Async/Await. You also aren't required to use Fetch at all, there are other third party ways of calling an API with Ajax such as by using Axios. I'd advise you to watch a video on how to use these different tools because when you figure out how they all work, you'll find that React and Ajax can be used together to build a great application. Hope this helped, please vote however way you felt about this answer. I'm pretty new to this website.
If you've scrolled down to this point you probably have this feeling of missing something in these answers which are great though. For me, it was hard to grasp what AJAX is. I had to look it up on Wikipedia. You can find a very good explanation there. I also read Jesse James Garrett archived article from 2005 where he coined this term (AJAX) and described it as a new approach to web applications. To dig deeper you can visit MDN.
Asynchronous requests are so obvious today in web development that it's hard to imagine there were websites without them. That's the key to understanding AJAX. At that time XMLHttpRequest API was something new. Now we have Fetch API in JavaScript or we could use Axios.
Google Maps approach was revolutionary in 2005. You could zoom in, grab a map, and scroll around. This instant response you had without page reloading was a result of the approach called AJAX. It consisted of a set of technologies like XMLHttpRequest, DOM, html & css, javascript.
As you can see AJAX is an old term to describe an approach in web development that makes applications more responsive (more than 20 years ago). Thus no matter what framework you use (Vue, Angular) or a library like React you use AJAX approach whenever your calls to API are asynchronous and they don't stop the user from interacting with your app which is a standard approach today.
BTW React is a library because it doesn't have a built-in state management tool, or routing tool in contrast to Ember.js, Angular, or Vue. We often talk about React stack, a set of separate tools for building react apps (Redux, Zustand, context api, react-router).
Facebook is doing Ajax History (Back and Forward button) and Bookmark using #! instead of just # in the URL. Is it always a good idea to do that, because I was thinking that a usual anchor could interfere with the Ajax History mechanism to trigger it into processing a normal anchor.
So, the Ajax History function will only process a hash portion only when it sees #! instead of just #.
And is using ! compatible with major browsers? If Facebook is using !, a guess is that it may be fairly well supported.
See Google's Making AJAX Applications Crawlable
for a possible use case (don't know if this is why Facebook used this fragment).
Update: This answer has been superseeded by this article. It discusses the issues with the Hashbang (#!), Hashes (#) and the HTML5 History API (pushState, popState) and the solutions.
In regards to usability on your website, it doesn't matter and you can use anything you like.
In regards to search engine optimization, having it and not having it both provide different avenues to go down.
For instance, Facebook uses the ! according to the Google Proposal for Making Ajax Applications Crawlable. Adding the ! will tell google that it should listen in on that ajax request and add that url to search engine results. This is great for websites which have already implemented ajax, as all you need to do is add the !.
The downside of this is that it only solves the problem of making your ajax crawlable. It does not solve the problems of:
Keeping the URLs clean and consistent for Ajax and Non-Ajax users. Eg. you could end up with www.facebook.com/profile.php?pid=123#!profile.php?pid=123
Keeping the website accessible by Non-Ajax users.
Keeping the URLs the same for both Ajax and Non-Ajax users.
Requires some severely complicated server side changes for escaping and translation of states in regards to query strings.
It is not compatible with the new HTML5 PopState functionality which is designed to truly solve these problems.
For websites which don't currently use ajax for everything, due to the problems above it is far better NOT using the Google Proposal as it is only workaround for sites like facebook which went ajax crazy and needed a desperate solution to SEO. There are alternatives which solve more of these problems (and with the HTML5 PopState now available can solve all the problems). One such alternative is jQuery Ajaxy (as seen on balupton.com) which works by simply upgrading your website into a ajax application, while keeping the experience for a Ajax-Enabled rich and interactive and continuing to work perfectly for Ajax-Disabled users.
I have no idea about AJAX programming features. I just know that it is Asynchronous Javascript and XML.
Please help me in knowing about this language.
I have gone through many AJAX tutorials. But none of the programs are running. Why I don't know.
Do we save the file with .HTML extension?
Read:
AJAX Tutorial by W3Schools.
AJAX Programming by Google Code University
To start coding you can get the Ajax Control Toolkit by Microsoft. You should read Ajax Control Toolkit Tutorials to get a grasp of it.
You can use the free Microsoft Visual Web Developer 2010 Express Edition as your IDE.
Aside from the correct responses that the others gave you, judging from your question I think you first need to learn about client-side and server-side code.
Do we save the file with .HTML extension?
Yes and no. You will have an HTML frontend, that for instance contains a button. This will be interpreted from the client's (=user) browser. In fact it may be rendered differently depending on the browser/OS/etc.
Now, you attach some Javascript code to this button. This also runs on the client's browser, and creates a XMLHttpRequest object, either directly or through the use of a library (JQuery & Co.). Note that a library is not necessary to do an AJAX request. It will make your life easier if you do a lot of AJAX calls, but it is not essential.
And here's where the magic happens: the XMLHttpRequest object will call asynchronously (i.e.: without reloading the page) a server-side page. This may be a PHP, ASP, Perl etc etc file that does something on the server, for instance queries a database. This part of the operation is absolutely independent from the client. The user can close the browser before the server-side code finishes to load and the server will not know about it.
Once the server-side code has finished executing it returns to the client with some response data (e.g. a piece of XML, JSON, HTML or whatever you like). Finally the client executes (or not) some other Javascript code in response to this, for example to write on the screen, again with no reloading of the page, something based on what the server has returned.
Maybe I can help you understand AJAX by clarifying the concepts a bit.
Please help me in knowing about this language.
AJAX is not a language, it is a way of using existing techniques to improve the user experience of a web site. The language is Javascript in the browser but you can use any server side technique that you feel comfortable with (ASP.NET, Java, PHP, Ruby etc.)
Do we save the file with .HTML extension?
Well, that is not really the point. What you have to grasp here is that there is a server and a browser that interact with each other. Yes, you can use static HTML files for your pages (and save them as .html files), but you'll need a server to respond to the requests of the browser. This may be why your sample code is not working; you need to set up a server that works with your pages.
The whole idea behind AJAX is to improve the user experience by not reloading the entire page when a user interacts with it. You request the data you need and update the page by using Javascript to update the HTML. This is called an out-of-band or asynchronous request.
I just know that it is Asynchronous Javascript and XML.
That is what the acronym stands for but it doesn't quite cover what the technique is for, nor is it accurate any more. In the beginning XML was used to transfer data from the server to the client. People found that XML is not really that easy to work with in Javascript so now it's more common to use JSON. JSON is a snippet of javascript that can be evaluated in the browser. The snippet creates javascript object(s) that represent the data.
If you use a Javascript library, like others have suggested here, you won't have to worry about many of the details though.
Before you get into AJAX you should make sure that you understand:
HTML and CSS
Javascript
how to modify HTML with Javascript
how a browser requests information from a server
how to handle requests on the server
If you are not comfortable with all of these concepts, stick with 'regular' web pages and try to improve your knowledge step by step.
Once you get the basic knowledge from W3school, I suggest you use a framework. Usually developers do not use XMLHttpRequest at all. Instead, javascript frameworks like ExtJS, jQuery and other frameworks make your work simple. I suggest you learn bit of javascript as well. check out jQuery.
Just to add that AJAX is rarely used in its pure form with XMLHttpRequest. You will often use it as a part of AJAX UI libraries which make your life easier. If you are from the Java world - such an AJAX library is Richfaces.
Instead of worrying about how to do AJAX, use something that allows you to forget about it. Frameworks like NOLOH do AJAX (and Comet) for you automatically without you having to do a thing. Just concentrate on your application, and business logic and it does the rest.
Really, everything is done via AJAX if available, automatically. No work on your part. If you're don't want to spend much time researching it, check out this short video that was demonstrated at Confoo PHP Conference this past March http://www.youtube.com/phpframework#p/u/11/cdD9hSuq7aw.
For all those worried about, well, if it's all AJAX, what about search engines? No need to worry, http://dev.noloh.com/#/articles/Search-Engine-Friendly/.
So instead of having to worry about all these different technologies, or the client-server relationship, you can sit down, code and have your website/WebApp working in no time.
You can read about NOLOH is this month's cover story of php|architect magazine, http://www.phparch.com/magazine/2010/may/.
Enjoy.
Disclaimer: I'm a co-founder of NOLOH.
It is easy one. Ajax getting data from server side by client side execution. We have to do use XMLHttpRequest to get the result.
I am trying to find the optimal architecture for an ajax-heavy Django application I'm currently building. I'd like to keep a consistent way of doing forms, validation, fetching data, JSON message format but find it exceedingly hard to find a solution that can be used consistently.
Can someone point me in the right direction or share their view on best practice?
I make everything as normal views which display normally in the browser. That includes all the replies to AJAX requests (sub pages).
When I want to make bits of the site more dynamic I then use jQuery to do the AJAX, or in this case AJAH and just load the contents of one of the divs in the sub page into the requesting page.
This technique works really well - it is very easy to debug the sub pages as they are just normal pages, and jQuery makes your life very easy using these as part of an AJA[XH]ed page.
For all the answers to this, I can't believe no one's mentioned django-piston yet. It's mainly promoted for use in building REST APIs, but it can output JSON (which jQuery, among others, can consume) and works just like views in that you can do anything with a request, making it a great option for implementing AJAX interactions (or AJAJ [JSON], AJAH, etc whatever). It also supports form validation.
I can't think of any standard way to insert ajax into a Django application, but you can have a look to this tutorial.
You will also find more details on django's page about Ajax
Two weeks ago I made a write up how I implement sub-templates to use them in "normal" and "ajax" request (for Django it is the same). Maybe it is helpful for you.
+1 to Nick for pages displaying normally in the browser. That seems to be the best starting point.
The problem with the simplest AJAX approaches, such as Nick and vikingosegundo propose, is that you'll have to rely on the innerHTML property in your Javascript. This is the only way to dump the new HTML sent in the JSON. Some would consider this a Bad Thing.
Unfortunately I'm not aware of a standard way to replicate the display of forms using Javascript that matches the Django rendering. My approach (that I'm still working on) is to subclass the Django Form class so it outputs bits of Javascript along with the HTML from as_p() etc. These then replicate the form my manipulating the DOM.
From experience I know that managing an application where you generate the HTML on the server side and just "insert" it into your pages, becomes a nightmare. It is also impossible to test using the Django test framework. If you're using Selenium or a similar tool, it's ok, but you need to wait for the ajax request to go return so you need tons of sleeps in your test script, which may slow down your test suite.
If the purpose of using the Ajax technique is to create a good user interface, I would recommend going all in, like the GMail interface, and doing everything in the browser with JavaScript. I have written several apps like this using nothing but jQuery, state machines for managing UI state and JSON with ReST on the backend. Django, IMHO, is a perfect match for the backend in this case. There are even third party software for generating a ReST-interface to your models, which I've never used myself, but as far as I know they are great at the simple things, but you of course still need to do your own business logic.
With this approach, you do run into the problem of duplicating code in the JS and in your backend, such as form handling, validation, etc. I have been thinking about solving this with generating structured information about the forms and validation logic which I can use in JS. This could be compiled at deploy-time and be loaded as any other JS file.
Also, avoid XML. The browsers are slow at parsing it, it is a pain to generate and a pain to work with in the browser. Use JSON.
Im currently testing:
jQuery & backbone.js client-side
django-piston (intermediate layer)
Will write later my findings on my blog http://blog.sserrano.com
From http://en.wikipedia.org/wiki/AJAX, I get a fairly good grasp of what AJAX is. However, it looks like in order to learn it, I'd have to delve into multiple technologies at the same time to get any benefit out of it. So two questions:
What are resources that can help me understand/use AJAX?
What sort of website would benefit from AJAX?
If you aren't interested in the nitty gritty, you could use a higher-level library like JQuery or Prototype to create the underlying Javascript for you. The main benefit is a vastly more responsive user interface for web-based applications.
There are many libraries out there that can help you get benefit out of AJAX without learning about implementing callbacks, etc.
Are you using .NET? Look at http://ajax.asp.net. If you're not, then take a look at tools like qcodo for PHP, and learn about prototype.js, jquery, etc.
As far as websites that would benefit: Every web application ever. :) Anything you interact with by exchanging information, not just by clicking a link and reading an article.
Every website can benefit from AJAX, but in my opinion the biggest benefit to AJAX comes in data entry sections - forms basically. I have done entire sites where the front end - the part the user sees had almost no AJAX functionality in it. All the AJAX stuff was in the administration control panel for assisting in (correct!) data entry.
There is nothing worse than submitting a form and getting back an error, using AJAX you can pretty much prevent this for everything but file uploads.
I find it easiest to just stay away from all the frameworks and other helpers and just do basic Javascript. This not only lets you understand what's going on under the covers, it also lets you do it in the simplest way possible. There's really not much to it. User the JS XML DOM objects to create an xml document client side. Sent it to the server with XMLHTTPRequest, and then process the result, again using the JS XML DOM objects. Start with something simple. Just try sending one piece of information to the server, and getting a small piece of information back.
The Mozilla documentation is good. Sites that benefit from it the most are ones that behave almost like a desktop application and need high interactivity. You can usually improve usability on almost any site by using it, however.
Ajax should be thought of as a means to alter some content on a page without reloading the entire page.
So when do you need to do this? Really only when you have some user interactions or form information that you want to keep intact while you change some content on the page.