Introduction to JavaScript Fall 2010 Class 11
Back to Introduction to JavaScript Fall 2010
Contents
Introduction
If you paid any attention the web development world in the last 5 years, you may have noticed that the term "Ajax" was one of the hottest buzzwords. While some of the buzz was overstated, Ajax does allow you to do some very useful things with JavaScript. This week, you'll see how you can use jQuery and Ajax to make your webpages more dynamic. However, to understand Ajax, you will first need to undertand how the process of requesting and receiving webpage works.
Client/Server
Opening a new webpage in your browser may seem like a pretty easy process. You type in the address, hit enter, and the page loads. However, sending a webpage to your computer is not as simple as it seems. Behind the scenes, your computer is formatting a request. That request is sent out over the Internet and eventually received by another computer. The computer that receives the request must then construct a response to send back to your computer. In the case of a webpage, that response may be some HTML that represents the webpage you requested. The response could also be an image, a JavaScript file or possibly some XML.
For this class, I'll ignore most of the things that happen along the way as a request is sent over the Internet and a response is returned. However, two key elements you'll need to understand when working with Ajax are the client and the server.
The Client
In short, the tool that you use to make a request over the Internet is known as the client. In this class, our client has been a web browser. We've mainly used Mozilla Firefox, so Firefox has been our client. Safari, Chrome, and Internet Explorer are also clients. Chat programs, Twitter clients and email programs are all clients as well. Any program that makes a request over the Internet can be considered a client.
Ajax is a browser specific technology, so I'll focus mainly on web browsers as clients.
The Server
When a browser requests a webpage, it will ideally receive response back. The program that responds to the message by sending a webpage back is known as the server. While the term "server" can refer to an actual computer, in this case I'll use "server" to mean a piece of software running on a computer. Just like a web browser is a program that sends and receives messages over the Internet, a server is also a program that sends and receives messages over the Internet.
There are many types of servers, but one specific type of server is called a web server. A web server is a program that is mainly designed to respond to requests for webpages. Web servers are especially good at talking to clients that are requesting HTML, images, JavaScript files or any other files related to webpages. Additionally, web servers can handle requests for webpages that are built dynamically using languages like PHP, Python, or Ruby.
The Request Response Cycle
As you've seen above, any request for a webpage involves sending a request from a web browser (the client) to a remote computer. The remote computer will be running a special program (the server) that knows how to handle the request and returns a response back to the computer with the web browser running on it. This roundtrip path from the client to the server and back again is known as the request response cycle.
At first glance, it might seem like a simple request for a webpage would involve only one roundtrip of the request response cycle. And, indeed, if you use your browser to request a simple webpage with only text on it the web server will respond with an HTML file, making one complete round of the request response cycle.
However, if instead of being a text only webpage, the page also had one image on it, the client would need to request the HTML file and the image file. The server would also need to respond with the HTML file and the image file. In most cases, the web server can only respond with one type of file at a time, and the web browser can only handle one type of response at a time. Which means that the browser needs to request the HTML file and the image file separately and the server needs to respond with the HTML file and the image file separately. Therefore, requesting a webpage with one image on it would involve two complete round trips of the request response cycle, one trip for the HTML and one trip for the image.
For every other file you add to the webpage, whether it's an image, a stylesheet or a JavaScript file, the request for the webpage will involve another request response cycle. The more complicated a webpage gets, the more requests and responses there will be. While the number of requests and responses might seem like only a technical detail there's an important reason to pay attention to how many requests a page needs to make.
Response Time
As you've probably noticed, webpages don't always load quickly in your browser. Some pages load almost instantly (think about the Google homepage). Other pages can take a long time to load. If a page takes long enough to load you may even give up and go somewhere else. The amount of time it takes for all the associated files for a webpage (the HTML, the css, the images, etc) is the response time for the webpage. When the browser requests a single image or a JavaScript file, the amount of time it takes for that single file to load is also called the response time. Essentially, the longer the response time, the longer is a user is going to have to wait before they can use your webpage.
For individual webpages, the response time will be dependent on how long it takes to load everything that the webpage depends on. A user might be willing to wait 1 second or more for a single webpage to load. However, most sites have multiple pages. Often, they will include forms that allow users to search the site or enter new information. If the response time for each individual page is too long user can quickly become frustrated and may leave the website altogether.
Wouldn't it be nice if you could update a webpage without having to reload everything?
Ajax
In this class you've learned how to use JavaScript to handle user events, to change a page's HTML, and to read the values that a user entered into a form. Taken together, you've got most of what you need to update a webpage without having to reload it. The one thing you dont have yet is the ability to use the client (the browser) to request more information from the server without having to reload the page. This is where Ajax comes in handy.
A Short History
Early browsers had very few built in options for requesting information from the server without reloading the page. Various workarounds were developed for getting around this problem, but it wasn't until the late 1990s that a straightforward solution was developed. In 1999, Microsoft added the ability to make an "XMLHTTP request" to Internet Explorer. In a nutshell, an XMLHTTP request allowed JavaScript to ask for additional information (formatted as XML) from the server without reloading the page. While XMLHTTP request made it easier to write JavaSript that made requests to the server, other browsers didn't immediately add similar functionality. So, any webpages that used XMLHTTP request would only work in Internet Explorer.
Fortunately, by 2005, other popular browsers, like Mozilla Firefox, had added functionality that replicated Internet Explorer's XMLHTTP request. Around the same time, sites like Gmail and Google Maps were released and relied heavily on JavaScript and XMLHTTP request. User experience designer Jesse James Garret coined the acronym AJAX (Asynchronous JavaScript and XML) to descibe the phenomenon of these new JavaScript heavy sites.
Today, every popular browser has added XMLHTTP request functionality. As people have developed sites that use JavaScript to request not only XML from the server, but also data in other formats (like JSON), the X part of the AJAX acronym has become inaccurate, and the acronym AJAX has changed to the broader term Ajax.
Using Ajax
Because Ajax functionality wasn't immediately added to all browsers, building a website that takes advantage of Ajax across all browsers isn't necessarily as straightforward as you might expect. In particular, older versions of Internet Explorer use a form of Ajax that is very different than most modern browsers, including more recent versions of Internet Explorer. It's possible to write your own Ajax JavaScript that works in all browsers, but, in general, it will be much faster and less error prone to choose a JavaScript library that supports Ajax.
Fortunately, the library that we've been using in class, jQuery, has support for Ajax. You can find extensive documentation on jQuery's Ajax functionality here.
