A Hot Way History
The early world wide web was composed of interlinking documents. The browser as a medium primarily delivered HTML documents that were concerned mostly with text. The web platform was an incredible way to share and consume information in the form of hypertext delivered over HTTP. Functionality on the other hand, things like games, communication applications like email, office software such as spreadsheets, still lived on the PC platform. If you wanted a program, you had to install it onto your PC.
Web developers tried to break the browser free of the confines of documents and into the world of applications but it didn’t work. Interactions were slow, and not just because we didn’t have easy access to blazing broadband options, but because every time you wanted to do something in the browser, the entire browser would need to be reloaded with a new HTTP round trip. During this loading time, the interface was locked and you couldn’t do anything. That means every link click, every form submission, had to happen synchronously, you could do one thing, but then you had to wait for the browser to make a request and the server to respond.
AJAX and the Birth of Web Applications
Desktop applications have a richness and responsiveness that has seemed out of reach on the Web. The same simplicity that enabled the Web’s rapid proliferation also creates a gap between the experiences we can provide and the experiences users can get from a desktop application. Jesse James Garrett, February 18 2005
Despite early failures, developers continued trying to push the boundaries of the browser medium. After all, the browser and the web held a lot of promise as an application platform. The web browser application had become ubiquitous with nearly every PC regardless of operating system having an installed browser. The proposition to be able to deliver application functionality through the browser and via HTTP was very compelling. Early attempts at this relied on Macromedia Flash and Java Applets running within the browser through plugins. The Flash and Applet environments allowed for the dynamic and rich interactions demanded by applications. However, for a variety of reasons, those in-browser platforms failed to achieve the adoption of common web browser document experiences. The most popular web destinations remained as HTML document with limited and slow interactivity.
And then in February 2004, things began changing. Apple added something developed by Microsoft for Internet Explorer, the
XMLHttpRequest was originally part of Microsoft’s MSXML and ActiveX browser extensions. The
By using the
XMLHttpRequest object, developers could ferry data back and forth from the browser to the server without locking the browser in a full reload. This allowed web developers to deliver rich, dynamic, interfaces and experiences previously locked to the desktop. The web as a true platform was born and “web sites” evolved into “web applications.”
XML and JSON
- The server responds with JSON.
pjax and HTML
pjax works by fetching HTML from your server via ajax and replacing the content of a container element on your page with the loaded HTML. It then updates the current URL in the browser using pushState. This results in faster page navigation for two reasons:
No page resources (JS, CSS) get re-executed or re-applied;
If the server is configured for pjax, it can render only partial page contents and thus avoid the potentially costly full layout render.
Consider first the functionality required to build a file browser interface. Every folder and file in a tree would need at leasts the following:
- A click event to request the data, most likely in JSON, from the server for the next tree of files.
- Build new HTML for the file tree using the JSON from the server.
- Replace the stale file tree with the newly constructed HTML.
- Maintain an accurate URL of the current working path using pushState.
Rather than implement such custom logic for a common pattern of updating a part of a page with new HTML based on data from the server, defunkt chose to abstract this into the pjax pattern. With pjax, instead of requesting only structured JSON data from the server and then having to teach the client what to do with that raw data, the client would simply request HTML from the server and inject it back into the page in the correct location. This approach is simpler for a few reasons:
- The backend can remain client-agnostic and send back HTML for the file tree without the need to implement both an initial page load of HTML response and a JSON API response for the client-side AJAX requests.
- The pattern is re-usable and abstract, you do not need to build specific client-side code for common page updates.
The Hot Way
pjax was quickly adopted by the Rails community and eventually became the basis for the
turbolinks pattern. The majority of page loads in a Rails application could make the request using AJAX, get the HTML for the next page asynchronously, and replace the entire
body of the current view with the
body from the AJAX request, while maintaining an accurate URL using pushState. Of course, if pjax was the predecessor pattern for turbolinks, it is at the heart of the Turbo pattern and the Hot Way of building web applications.