History of AJAX
Long ago, when web development was in its teenage, the World Wide Web was unfortunately not that wide as it is right now. Websites had largely static HTML where to navigate between pages, browsers had to reload the entire page.
This was the case even for pages with almost the same content. A completely new request had to be made to the server and almost all of the similar data had be sent once again for no reason whatsoever.
As you might realise, this can be pretty inefficient, particularly for complex applications - it can add extra latency to the loading and interaction of the site and cause unnecessary loss of cellular data. Not only this, but the browser has to also reparse the entire HTML content into a DOM tree; which doesn't change that much!
The nature of this web surely couldn't fulfill the requirements of the emerging websites being developed, and so popped in a new technique - the
iframe element in use
Formerly known as
<iframe> element was made to allow HTML pages to embed other web pages within them, inside a new window frame, that can interact with the main document in any way they like. This enabled the idea of making requests from the
iframe, while the browser didn't know of any changes happening there, and then processing the response to update parts of the main document likewise.
If you ask what was the significance of this development, well it marked the beginning of asynchronous communication between the client and the server. The user could continue doing on other work on the webpage, while the request in the
iframe was resolved in the background!
Exploring more of the details to this technique, developers actually hid the
iframe from being viewed on the document, by setting its
width attribute to
"0". This prevented the user from realising the fact that whatever is happening on the web page is, in effect, a result of different requests being made in the
iframe. In plain words, the technique didn't have any noticeable visual limitations to it.
The browser's back and forward buttons also didn't lose their purpose i.e pressing either of them caused navigations within the frame and thus subsequent changes to the main document, and so the technique prove to be extremely useful, in its early stages.
However as the complexity of applications grew, it meant that the
iframe technique could no longer meet all their requirements. Developers didn't have any sort of control over setting headers manually in the request, or of getting headers from the response. Sending form data was another tedious job, in addition to rigorous error handling.
These limitations of
iframe were obviously known to browser developers who began to come up with solutions to it.
ActiveXObject() and support for
Thus came into existence the
ActiveXObject() introduced by Microsoft for its browser IE5, with its
MSXML library and support for
XMLHTTP feature was the idea that ultimately led to the development of a web standard as we'll see below.
At the time of its release few people knew of this major advancement and the real potential of it - it was truly an unsung hero of its time. However, a series of events were to follow its development that it soon gained a sudden boost in popularity and came to the knowledge of an even wider developer community, including the W3C!
Major browser vendors saw all this game in action and consequently began enacting the funtionality of
ActiveXObject() and its
XMLHTTP control into their respective web browsers. All of including Chrome, Firefox, Opera and Safari implemented it as the
XMLHttpRequest()was implemented by Internet Explorer too, starting from IE7. Nonetheless the support for
ActiveXObject()was still there in this version of IE and in the ones to follow.
ActiveXObject()from their latest browser Edge, which works entirely on
Although uptil this point, it had not become a global web standard,
XMLHttpRequest() didn't stop from reaching the summit of its traction.
In 2005, Google launched new interfaces for its mailing and geolocationing web applications - Gmail and Google Maps respectively. Both these new developments utilised the idea of
XMLHttpRequest(), providing a high level of user interaction and a sufficiently fluid user experience, using it. To add to this, Google also released a new feature for its search engine, where matching results were displayed, on the go, as the user typed in queries into the search box; known as Google Suggest.
All these events simply yielded points for the popularity of
XMLHttpRequest() and soon it began to be in the discussions of developers and web engineers.
The idea behind the name 'AJAX'
The feature was hot on the market as well as in the talks between many clients and business representatives. The
DOM API had already been released and
XML was also building firm foundations. HTML was obviously the core of all, while CSS was being used to put in stylistic layers over webpages.
As a whole, these technologies started to blend so well together with each other that they began to be used as a single unit for developing web applications, and not just this - they also got a name!
Just like the technologies, the name couldn't also stop from gaining popularity and even more attraction of users and developers.
These enhancements couldn't go past the eyes of many people including those at the World Wide Web Consortium, or W3C. Ultimately in 2006 the committee standardised
XMLHttpRequest() and dispatched its first working draft.
The birth of AJAX was a milestone in the history of the web and one which is present to date in active teaching resources, complex and industry-level applications, and even this course!
What is AJAX?
As we know by now AJAX is simply a convenient name given to the set of technologies that are used in asynchronously communicating with a destination server and then handling the response sent by it.
AJAX allows updates to be made to a webpage without the need to reload it. We call this refresh without a reload. This is what the 'A' in AJAX means i.e asynchronously carry out client-server communications that don't block interaction with the main webpage.
The user only sees live changes happening on the webpage, not realising the fact that there is so much going on behind the scenes of the web browser!
At the most basic level, an AJAX application only needs the following three technologies to work:
- HTML to create a document's structure and semantics, and layout the content of the webpage.
XMLHttpRequest()object to create an AJAX engine.
- HTML DOM to be able to make changes to a document, dynamically on the go.
However, only using these would mean being far behind the advancements of the web we know today. Following are the optional, but near must, technologies an AJAX application can use in addition to ones shown above:
- CSS to style web pages and make it look graphical interactive and appealing to the eye.
- XML to exhange tree-structured data between the client and the server.
As you'll get into AJAX more and more, you'll soon appreciate the fact that all these technologies are equally important and necessary in building AJAX applications of this era - eliminate one and you'll lose all the essence of the app.
So now that we have gained literally a lot of insight into the history of AJAX and a brief overview of what it is, let's elaborate a bit on the details of this course and what we'll accomplish in it starting from the next chapter.
We'll understand the mechanism by which AJAX requests are made and compare that with the conventional request model used by browsers in normal cases. Moving further, since AJAX boils down to HTTP requests and responses, we'll finely examine the structure of both these, and see the different methods to sending out requests including
There are quizes, tasks and a lot more to discover right in this course. If you want to learn AJAX starting from this moment, dive in and embark on the learning journey ahead!