AJAX model, good or bad?

In this article I’ll outline my position on AJAX application model and try to provide an answer the following questions:

  • Is AJAX just another fad, or will it continue to promote the development of Web-based software?
  • Can an application model ever actually be taken seriously when it does not normally allow information storage on the local client or when certain users prefer working in an offline mode?

I’ll also explain whether I think that AJAX will continue to encourage the development of Web-based software or if we should use other technologies instead.




History of Ajax

In this article, I’ll analyze the advantages and disadvantages of AJAX and assess the AJAX model in relation to classic web application model and also other modern software designs; and talk about its pros and cons.

But to start, let’s first explain a little bit about the history of Ajax and what the technology is all about.

The term Ajax was coined in 2005 by Jesse James Garrett, an information architect and co-founder of a consulting firm Adaptive Path based in San Francisco, California. As the story goes, this happened “when Mr. Garrett was presenting the previously unnamed technology to a client of Adaptive Path” (Deitel, P., 2009). Apparently, the reason why Mr. Garrett invented the term Ajax, was in his own words due to following: “I needed something shorter than “Asynchronous JavaScript+CSS+DOM+XMLHttpRequest” to use when discussing this approach with clients.” (Garrett, J.J., 2005).

This already hints, that Ajax really brought together an entire set of technologies, that can exchange information with a server, and update sections of a web page, all possible without reloading the whole page. As Mr. Garret summarized it: “Ajax isn’t a technology. It’s several technologies, each flourishing in its own right, coming together in powerful new ways.” (Garrett, J.J., 2005)

For us it’s crucial to know, that handling of asynchronous requests wasn’t a new concept in 2005 when Mr. Garrett used the term Ajax to describe the asynchronous communication. As a matter of fact, asynchronous requests were available to browsers ever since the invention of LiveScript (which later became JavaScript), in fact, it goes as far back as the late 1990s when Microsoft created the XMLHttpRequest object to manage such needs.

Some of us may immediately ask. So, is Ajax just another name for XMLHttpRequest? No, it isn’t. XMLHttpRequest is only part of the Ajax that enables the asynchronous communication with the server. Ajax is the name for the approach which does not rely only on XMLHttpRequest but also uses other technologies. That said, it’s the technologies such as HTML, JavaScript, Document Object Model, XML and XMLHttpRequest that make up Ajax bundle, as we know it today. These technologies were there the entire time, all of them available well before the year 2005, so the name Ajax primarily talks about using these technologies as one to achieve server side communications without a refresh of a webpage.


Classic vs. Ajax Web Application Model

Many of the advantages and disadvantages of Ajax can easily be derived from the following image (© Jesse James Garrett) that perfectly describes a difference between the classic and Ajax web application model.

Ajax Overview 1


Classic Web Application Model

As we can see, the traditional web application model is very simple. Let’s say we have a form on the page, which sends the data to the back-end (server-side). What typically happens is that clicking on the submit button will trigger an HTTP request, which goes to the web server, which after it has done some processing (talk to DB, etc.) will return an HTML page back to the client. This process will either take the user to entirely new page, or it’ll trigger a page refresh. And every time there is such a server-side communication, the user needs to wait.


Ajax Application Model

Ajax model is much better, even though looking at the above image may suggest otherwise mainly due to perceived complexity of communication. So, why is Ajax better than classic web application model?

Well, firstly, an Ajax application doesn’t need to communicate in the start-stop synchronous way that standard web applications do, it is instead leveraging an Ajax engine which sits between the user and the web server. “This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously -independent of communication with the server. So, the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.” (Bhosale, S. H., 2013).

The benefit of asynchronous communication can be easily realized by looking at the following image; that outlines the difference in which two of the models communicate. Ajax allows us to work without interruptions, whereas classic web operates in a stop-start-stop-start fashion that is taking a lot from the user experience.

Ajax Overview 2

Ajax vs. jQuery vs. Other RIA Frameworks

jQuery is a library that makes working with AJAX, and other JavaScript tasks a bit simpler and easier. Jquery in a sense takes the pain out of writing standard JavaScript routines. “Part of the functionality of jQuery implements a high-level interface to do AJAX requests. jQuery implements this interface abstractly, shielding the developer from the complexity of multi-browser support in making the request.” (Ajax and jQuery, 2016).

Let me explain this on an example. Let’s say we want to use Ajax to grab content from service.php file sitting in the backend and then show the response in a DIV tag with id=divResponse.


As simple as In Ajax, we’d need to do created a button, which executes the JavaScript function:

And DIV tag where the response will go:

And a JavaScript that does the asynchronous call to back end and later populates our DIV tag.


In jQuery we can do all of that with a simple jQuery ajax() method, which allows us to perform an AJAX (asynchronous HTTP) request in a very simple way:

As we can see, this is a much easier way to work with Ajax and clearly points to the benefit of using jQuery.

jQuery’s Ajax method implementation provides additional properties which we’d have to code if we went ahead without jQuery. Properties such as ‘async’ which indicates whether the demand should be handled asynchronous or not, or options for caching during requests, selection for the data type that is expected to arrive from the server response. It also has the possibility to use passwords in an HTTP access authentication request, which should make jQuery right out of the box a bit more secure. Another advantage is that out of the box, jQuery’s Ajax call will be supported by a majority of browsers, which cannot be said about pure JavaScript version in our earlier example.

Other Frameworks

We shouldn’t forget, that everything that happens in the browser is using HTML and JavaScript, which means, that all other JavaScript and Non-JavaScript web development frameworks for creating Rich Internet Applications (RIA) are doing the same thing we’ve seen in the jQuery example above. They create a simpler to write functions with additional options, which boiled down to its essence means that they simplify and extend what at the end of the day all boils down to a complex Ajax code.

Could WebSockets be considered to be AJAX replacement and are there any advantages and disadvantages in utilizing HTML5 WebSockets technology?
In my view, there is a place for both techniques. I don’t think we will see Ajax being retired anytime soon, because it’s a valid approach for a one-off action driven communication, such as in cases where the user clicks on a button, and we need to retrieve information from a server-side (data from the database, etc.).
WebSockets on the other hand, offer bidirectional communication, which is more useful in the situations where browser to server-side communication requires a full-duplex communication channel that is expected to be heavily utilized, such as in the active media streams, interactive games or specific IoT devices (home monitoring, etc.). This is where Ajax would not be a sufficient solution.
That said, each of the solutions could be used to communicate with the server side, but I am not sure I agree with the following statement that “developers should adopt real-time communication protocol – web sockets as a new development paradigm (Missal, 2013).”. I firmly believe, that each of these two methods can co-exist and be used for what they are better suited for.
Also, it’s important to note, that Ajax has been around for a longer time, since 2005, whereas the WebSocket protocol was only standardized in 2011 by the IETF as RFC 6455 (note: the W3C is standardizing the WebSocket API in Web IDL). It means, that regarding support WebSocket protocol communication may not be available to all browsers and thus the software applications that use WebSocket protocol may also not work on all devices. However, there is a lot of progress on that front, because, in this media driven age, almost all the main browser brands do realize the importance of supporting WebSockets. This is the current level of assistance by each of the modern browsers (WebSockets, 2016):

As we can see the browser support is already there, but for this technology to fully catch for IoT devices, we’ll also need to see an increase in support amongst transparent proxies, reverse proxies and also load balancers.
As I mentioned earlier, the WebSocket is a communication protocol and the primary interface for connecting to a WebSocket server. As a matter of fact, the server side support is crucial for WebSocket communication to work, because it enables the client to server communication as well as sending and receiving data on the connection.
The WebSocket Server is a TCP application that takes care of handling the WebSocket connections, launching your programs to handle the WebSockets, and passing messages between applications and web browser. There are a variety of options when it comes to creating the Websocket server. For those who don’t feel comfortable creating a custom server, there are options such as websocketd server (http://websocketd.com) which is a server that can be easily installed on any Unix computer. But a simple WebSocket server can be programmatically created on any platform without much of an effort.  WebSocket protocol is defined by using a ws:// and wss://, which means that whenever we see one of above prefixes, they indicate that it’s either a WebSocket (ws://) or a WebSocket Secure connection (wss://).
There is a variety of tools available to WebSockets, the following are some of the examples:
– µWebSockets: Highly scalable WebSocket server and client implementation for C++11 and Node.js.
– Socket.IO: A long polling/WebSocket based third party transfer protocol for Node.js.
– WebSocket-Node: A WebSocket server API implementation for Node.js.
– Total.js: Web application framework for Node.js (Example: WebSocket chat)
– Faye: A WebSocket (two-ways connections) and EventSource (one-way connections) for Node.js Server and Client.
– SignalR: SignalR will use WebSockets under the covers when it’s available, and gracefully fallback to other techniques and technologies when it isn’t, while your application code stays the same.

What about Webhooks? Could the use of Webhooks provide the ultimate solution?
Webhooks are for the server to server communication. They work by one server telling another server that it wants data sent to a certain URL when something happens. It’s a very flexible technology which promotes open architecture, similar to Unix pipes.
“For the uninitiated, webhooks are simply a pattern for an evented web. All they are is a promise by an application or API: “when this thing happens, I’ll send this HTTP request with this data.” That simple promise opens up a lot of opportunities, though. It enables the web to start being aware of events, to respond to things without user interaction. It makes the web capable of pushing information to its users, instead of waiting for users to ask for information.” (Webhooks, 2013)
Webhooks can be used for any communication where servers need to communicate and respond to individual events and trigger other events. That can be particularly useful when handling the text messages, emails, respond to changes in code, processing payments, respond to changes on the web, respond to changes happening on the server, etc.


Advantages and Disadvantages of Ajax

As with any other technology, AJAX comes with its specific benefits and shortcomings.


  • Rich & Interactive – As hinted above, Ajax’s main strength comes from the ability to show the dynamic web content without a need to refresh the web page. It’s, as we’ve learned due to leveraging the asynchronous requests, which indeed makes our web applications a way more compelling. It’s a usual method of development today, primarily because of a fact that Ajax allows us to create web apps that feel more like the desktop applications we’re using every day. And that’s a significant advantage. This is pretty much the most attractive benefit and also why some developers are switching to AJAX for their sites. AJAX makes development easier and makes for faster interaction between users and websites. The pages don’t need to be reloaded for content to be displayed. “Ajax applications separate client-side user interaction and server communication and run them in parallel, making the delays of server-side processing more transparent to the user. Modern applications like Flickr, Google’s Gmail and Google Maps use the XMLHttpRequest object
  • to update pages dynamically.” (Deitel P. , 2015)
  • Structured Data – When transferring structured data between the server and the client using XMLHttpRequest, Ajax application can leverage the XML which is easy to generate and parse.
  • Reduced Traffic – Another benefit of Ajax emanates from the reduced traffic between the client and server, which makes up for a much faster response times when working with the web page.
  • Improved Navigation – This benefit comes from the fundamental nature of Ajax. There is no longer need to create the traditional back and forward buttons; we can simply bring web components in and out of a view, and use the similar techniques for communicating with server side using asynchronous calls.
  • Popularity and Reputation – Ajax is very popular and heavily supported by the open source community which continues to release many open-source JavaScript libraries, which provide additional assistance to Ajax. “Another assuring reason to use AJAX on your websites is the fact that several complex web applications are handled using AJAX, Google Maps is the most impressive and obvious example, other powerful, popular scripts such as the vBulletin forum software has also incorporated AJAX into their latest version.” (Developing a site with JavaScript, 2016)
  • Compactness – Multiple components of web applications, as well as and functions can be managed by using a single web page. Ajax opened the door to Single Page Application (SPA) design and architecture.


  • Complexity – There are some downsides to using Ajax, mainly in the area of complexity and difficulty to use. Ajax code for asynchronous communication may differ between browsers, so the developers seeking multi-browser support must create different versions of their code, to assure that it’ll work on various browsers. This all increases the overall development time as well as the time spent on quality assurance.
  • Redundant Back, Forward and Refresh browser buttons – As AJAX is loading the content dynamically, it creates the environment in user may live on a single page, that never changes the URL. This renders back and forward buttons of the browser, as well as the refresh button completely useless. It means, that clicking the back, forward or refresh button would not guarantee that application will take you to a page you want to visit. Which is one of the drawbacks of AJAX. Fortunately, there are ways around this issue, but they’re not the simple workaround. Browsers store the browsing history, to load the pages quickly when the user presses these buttons. Ajax pages need to recreate this functionality.
  • Does not work without JavaScript – As some users do not trust JavaScript, they tend to disable JavaScript functionality in their browsers. It makes the browser more secure, but it renders any Ajax application completely useless. The only way around this drawback is to developer a parallel non-JavaScript version of the web page, which is a not only a hassle but also costlier and such version of the website tends to be less dynamic which in turn makes for the worst user experience.
  • Security – Ajax is not known for its security, and even that by default XMLHttpRequest object prohibits a web application to request resources from other domains than the one that serves the web application, several know issues can still impact Ajax applications. One of them is Cross-Site Scripting, which occurs when users input is not sanitized. Cross domain issues do have proxy workarounds that undermine the security of Ajax. And other safety issues are related to Data leakage in Ajax or JSON Hijacking, Cross Site Request Forgery (CSRF). However, it’s important to note here, that most of the issues that affect Ajax are similar in nature to those that impact other traditional web applications, which means they can also be mitigated in very much the same way.
  • Hard to index and not SEO ready – because AJAX content is created dynamically by the browser, it is inherently invisible not only to Google, as well as to all other web bots and crawlers. What user sees is many times not the same thing that crawler sees, and while there are methods to dealing with these issues, neither of them are very convenient.


I believe that even though Ajax does not allow information storage on the local client or readily work without live/online Internet connection, Ajax’s application model should still be taken very seriously. People love Ajax applications to such a point that many of them are ready to use Ajax based apps instead of their desktop counterparts. Thus we see a lot of progress in the way Ajax technology can communicate with services. Ajax can leverage HTML5 local storage, use caching API’s, or even use offline databases such as Apache Derby that can reside and store data in an encrypted form directly on the client-side. So, while this is certainly an issue, it hasn’t been a significant deterrent. As approximately forty percent of the world’s population is connected to Internet today and the number of internet users have increased tenfold from 1999 to 2013, we should see more users inclining to use web based, and Ajax powered apps.

Considering everything said in this paper, I don’t believe that AJAX is just another fad. Ajax comes to us in many forms, and it remains a cornerstone of all Rich Internet Application frameworks. It’s still one of the hottest approaches in web development, mainly because Ajax takes regular Internet applications to a whole new level, where Ajax based apps challenge the domain of desktop applications. This process promotes the development of Web-based software in general.

I am very confident that Ajax is here to stay and I very much agree with the following statement of Jesse James Garrett once, who said:

“Ajax is an important development for Web applications, and its importance is only going to grow”



Deitel P. (2015). Internet and World Wide Web: How To Program 5th Edition. (Accessed: 17 December 2016).

Lin, Z., Wu, J., Zhang, Q., & Zhou, H. (2008, December). Research on web applications using ajax new technologies. In MultiMedia and Information Technology, 2008. MMIT’08. International Conference on (pp. 139-142). IEEE. (Accessed: 17 December 2016).

Isikdag, U. (2012). Design patterns for BIM-based service-oriented architectures. Automation in Construction25, 59-71. (Accessed: 17 December 2016).

Bhosale, S. H. (2013). AJAX: COMING TO AN APPLICATION NEAR YOU. Compusoft2(6), 164. (Accessed: 17 December 2016).

Powell, T. (2008). Ajax: the complete reference. McGraw-Hill, Inc. (Accessed: 20 December 2016).

Paulson, L. D. (2005). Building rich web applications with Ajax. Computer, 38(10), 14-17. (Accessed: 17 December 2016).

Quote by Jesse James Garrett (2016) Available at: http://www.quoteopia.com/quote.php?quote=257280 (Accessed: 18 December 2016).

Eichorn, J. (2006). Understanding AJAX: Using JavaScript to create rich internet applications. Prentice Hall PTR. (Accessed: 18 December 2016).

Garrett, J.J. (2005) Ajax: A new approach to web applications. Available at: http://adaptivepath.org/ideas/ajax-new-approach-web-applications/ (Accessed: 18 December 2016).

O’reilly, T. (2007). What is Web 2.0: Design patterns and business models for the next generation of software. Communications & strategies, (1), 17. (Accessed: 18 December 2016).

Ajax and jQuery (2016) Available at: http://stackoverflow.com/questions/931908/what-is-the-difference-between-ajax-and-jquery-and-which-one-is-better (Accessed: 18 December 2016).

JQuery ajax() method (2016) Available at: http://www.w3schools.com/jquery/ajax_ajax.asp (Accessed: 18 December 2016).

Deitel, P. (2009) JavaScript for programmers. Available at: https://books.google.ca/books?id=HdOW3luqHZwC (Accessed: 18 December 2016).

Developing a site with JavaScript (2016) Available at: http://www.jscripters.com/ajax-disadvantages-and-advantages/ (Accessed: 18 December 2016).

InternetLiveStats (2014) Number of Internet users (2016). Available at: http://www.internetlivestats.com/internet-users/ (Accessed: 20 December 2016).

2016, I.R. (2016) Ajax security issues. Available at: http://resources.infosecinstitute.com/ajax-security-issues/ (Accessed: 20 December 2016).

Galpin, M., architect, S. and eBay (2008) Offline Ajax with Apache derby. Available at: http://www.ibm.com/developerworks/library/os-ad-offline-ajax/ (Accessed: 20 December 2016).

Lium, G. (2016) Where to store JWTs – cookies vs HTML5 web storage. Available at: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage (Accessed: 20 December 2016).

Negrino, T., & Smith, D. (2008). JavaScript and Ajax for the Web: Visual QuickStart Guide. Peachpit Press. (Accessed: 20 December 2016).

Missal, C. (2013) Browser wars: Websockets vs. AJAX. Available at: https://lostechies.com/chrismissal/2013/08/06/browser-wars-websockets-vs-ajax/ (Accessed: 22 Dec 2016)

WebSockets (2016) Available at: http://caniuse.com/#feat=websockets (Accessed: 23 December 2016).

Why use AJAX when WebSockets is available? (2016) Available at: http://stackoverflow.com/questions/10377384/why-use-ajax-when-websockets-is-available (Accessed: 23 December 2016).

Differences between webhook and websocket (2016) Available at: http://stackoverflow.com/questions/23172760/differences-between-webhook-and-websocket (Accessed: 23 December 2016).

Webhooks (2013) 7 reasons Webhooks are magic. Available at: https://www.iron.io/7-reasons-webhooks-are-magic/ (Accessed: 23 December 2016).