November 7, 2013

AJAX, States, and Pushstate()

AJAX stands for Asynchronous Javascript and XML. Many popular websites make use of AJAX, for example Google and Twitter. To understand why it's being used, we have to understand how the traditional World Wide Web was meant to be built. The web was intended to work like this: you use a web browser application (eg. Internet Explorer, Chrome, Firefox, Safari) on your computer to visit a web page, by giving the browser that page's URL address (eg. http://www.google.com). The browser, or client, connects to a web server via the internet and requests that web page, which is merely a text file, specifically an HTML file. That server serves that file back to the client browser, and the browser displays that page, also requesting any additional files such as images needed to completely display that page. You can then click on a hyperlink to visit another web page, and your browser goes and connects to whatever web server is that file is stored on to get that page. But as the web has matured, websites have gotten more complicated, bigger, and more visual, and the basic HTML web model has become obsolete. We moved from mostly text-based pages to websites consisting of many web pages, all with consistent visual elements (eg. logo in the top left, a navigational menu along the top or side, a footer) which are there to make the web more user friendly. We've also developed new technologies, like CSS, Javascript, and PHP, to supplement our basic HTML websites, and one of these technologies is AJAX.


Here's what AJAX does: it takes the old web model, which is completely static, and makes it dynamic. In the traditional web client-server model, the client browser requests a page, gets it and displays it, and that's the end of the session. To visit another web page, even if it's a page that's still part of the same website stored on the same web server, the browser would have to contact the server again, and even if the pages were mostly identical outside of a block of text (say, the first one was an “about us” page and the other was a “contact us” page), that page would have to be completely re-loaded and re-displayed. Each page request is a discrete and independent transaction. What AJAX allows the browser to do is display the first page, and when you click on that link to the “contact us” page, instead of going through all that trouble, you stay on the “about us” page, but the browser uses AJAX to request the “contact us” block of text, and after the server serves the page back, then only that block of text changes. Basically, AJAX allows us to request data from a server and display it, without having to re-load or refresh the current page. When you type into a Google search, and suggestions pop up, that's AJAX working (Google loves AJAX; it's found in Gmail and Google Maps too). AJAX's primary benefit is to decrease loading times and make moving between pages a smoother experience, but with more clever utilization like with Google, it can also allow for the creation of much more extensive and robust web applications.

There are some drawbacks to using AJAX on your website, though. First and foremost is that it's reliant on Javascript being enabled in the user's web browser. If it's disabled, then AJAX will not work, so fallbacks will be needed if you want to replicate that functionality. Another issue comes with the rising importance of SEO (Search Engine Optimization). Search engines such as Google and Bing use “web crawlers” to scour the web and to figure out what is contained on each web page. But with AJAX, that content isn't static; it may change depending on what gets clicked. Some older or more obscure web crawlers don't have any Javascript functionality whatsoever, so AJAX content might not register for them at all. Google has been trying to work out the best way for their web crawlers to scan websites that use AJAX, but it's still a work in progress. If you click an AJAX hyperlink, to the user it's as if you may have gone from an “about us” page to a “contact us” page, but to the browser, you're still on the same page, so does Google treat that like one page or two? This is related to another issue. Vanilla HTML is inherently a “stateless” protocol (ignoring cookies and other workarounds for the moment), which means that the server doesn't keep track of any data across page requests (say, between the “about us” page and the “contact us” page), but on the client side, the state of a static HTML web page can be bookmarked and returned to later, via that page's URL. But with AJAX, the content on a page can change without any change in the URL, which means that the user has no way to return to the state of that web page then. One solution? Pushstates.


Pushstates were recently introduced in the latest HTML5 specification. What that basically means is that only the newest versions of internet browsers will support it. Still, it's a solution to the problem of tracking changing AJAX content on the client end. A prior Google suggested solution for this was known as the hashbang, which used “#!” in the URL, which was difficult to implement and caused its own problems, but pushstate is a lot more straightforward. Basically, you can use the new History.pushstate() Javascript function to change the URL displayed in the client browser, so that once you've dynamically changed the initial “about us” page to the “contact us” content, you change the URL in the address baras well. It does this by simply adding (“pushing”) another URL (eg. http://www.example.com/?page=contact) onto the browser history “stack” (which is the list of URLs you've visited), so that when the user tries to bookmark the page he's currently seeing, it doesn't bookmark the “about us” page instead. Using this method does then require a way for the server to deal with these new URLs, to serve the appropriate content if the user visits the pushed state URL directly. And it's important to remember that older browsers won't support this. But with this combination of AJAX and Pushstate(), developers can create more dynamic, user friendly, and search engine friendly websites and web applications.

No comments:

Post a Comment