The Bad Old Days
One of the first web development tasks that moved beyond serving simple, static HTML [12] pages was the technique of building pages dynamically on the web server using data from a back-end data store.
Back in the "bad old days" of web development, the only way to create this dynamic, database-driven content was to construct the entire page on the server side, using either a CGI script (most likely written in Perl [13]), or some server component that could interpret a scripting language (such as Microsoft's Active Server Pages). Even a single change to that page necessitated a round trip from browser to server -- only then could the new content be presented to the user.
In those days, the normal model for a web application's user interface was a web form that the user would fill out and submit to the server. The server would process the submitted form, and send an entirely new page back to the browser for display as a result. So, for example, the completion of a multi-step, web-based "wizard" would require the user to submit a form -- thereby prompting a round-trip between the browser and the server -- for each step.
Granted, this was a huge advance on static web pages, but it was still a far cry from presenting a true "application" experience to end-users.
Prehistoric AJAX
Early web developers immediately began to look for tricks to extend the capabilities of that simple forms-based model, as they strove to create web applications that were more responsive and interactive. These hacks, while fairly ad hoc and crude, were the first steps web developers took toward the kind of interactivity we see in today's AJAX applications. But, while these tricks and workarounds often provided serviceable, working solutions, the resulting code was not a pretty sight.
Nesting Framesets
One way to get around the problem of having to reload the entire page in order to display even the smallest change to its content was the hideous hack of nesting framesets within other framesets, often several levels deep. This technique allowed developers to update only selected areas of the screen, and even to mimic the behavior of tab-style navigation interfaces in which users' clicking on tabs in one part of the screen changed content in another area.
This technique resulted in horrible, unmaintainable code with profusions of pages that had names like EmployeeEditWizardMiddleLowerRight.asp [14].
The Hidden iframe
The addition of the iframe in browsers like Internet Explorer 4 made things much less painful. The ability to hide the iframe completely led to the development of another neat hack: developers would make HTTP requests to the server using a hidden iframe, then insert the content into the page using JavaScript and DHTML [15]. This provided much of the same functionality that's available through modern AJAX, including the ability to submit data from forms without reloading the page -- a feat that was achieved by having the form submit to the hidden iframe. The result was returned by the server to the iframe, where the page's JavaScript could access it.
The big drawback of this approach (beyond the fact that it was, after all, a hack) was the annoying burden of passing data back and forth between the main document and the document in the iframe.
Remote Scripting
Another early AJAX-like technique, usually referred to as remote scripting, involved setting the src attribute of a <script> tag to load pages that contained dynamically generated JavaScript.
This had the advantage of being much cleaner than the hidden iframe hack, as the JavaScript generated on the server would load right into the main document. However, only simple GET requests were possible using this technique.
Share and Enjoy:
