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.
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)
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.
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 vs. jQuery vs. Other RIA Frameworks
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.
And DIV tag where the response will go:
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.
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.
- 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.
- 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 Construction, 25, 59-71. (Accessed: 17 December 2016).
Bhosale, S. H. (2013). AJAX: COMING TO AN APPLICATION NEAR YOU. Compusoft, 2(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).
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).
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).
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).