A Brief History of Dynamic Web Content

After spending days coding a site and sending a draft over to the client, the response back is almost immediate. They want the data tables to be sortable by the column headings. This needs to be done dynamically, of course. And the Twitter widget needs to live update any time they send out a new tweet. Thankfully, the ability to do this has become relatively easy and commonplace. To the point that, these days, I start any project with the assumption that some of the content needs to be dynamic and plan for it from the outset.

I plan for it because I know that it is one of the most requested features on any site I work on. There are a lot of good reasons for doing this, particularly from a user experience perspective, and the feature has been fairly standard across the web for a while now, even as the tools for achieving this have changed a lot over the years. I will note from the outset that this article is largely a personal reflection of how I saw things progress. While I did some research to make sure my dates and time lines were mostly in order, this isn't intended to be an exact, detailed account, and there is always the possibility that I am completely wrong in some regard. Feel free to point it out in the comments if you feel so inclined.

As is generally well known, the early days of the internet and the world wide web were not particularly dynamic. While dial-up BBSes and early websites allowed unprecedented access to people around the world, the visual display of that information was not of the highest priority. Bandwidth was at a premium (insert joke about current monopoly telco practices here), so it was generally by necessity that information be presented in a manner that was not overly taxing on download size. While this edict has largely held true over the years, and even in to today, the available bandwidth that visitors have, and the technologies used to get that information to them, have greatly improved and provided us all with wave after wave of exciting new things to discover on the web.

Perhaps one of the earliest examples of dynamic content on the web was the use of Java applets. While ActiveX and Flash both first appeared around the same time in the mid-90's, Java applets were arguably the first to take hold across the web, largely because of the pre-existing adoption of JREs. The early examples were usually quite crude in graphics and capabilities, but it opened the door to a new way of thinking as to what a website could really do. You could find live weather widgets, small playable chess games, and...yeah, I don't really remember much more than playing a bunch of random chess games on other people's sites. Of course, this also lead to some of the early major security vulnerabilities on a lot of websites. Providing direct access to client-run Java code over the web proved to be a major opportunity for those with nefarious purposes. Certainly as time went on this improved greatly, but it left a sour taste for a lot of casual internet-goers towards Java applets. To the point that many people turned them off completely.

ActiveX and Flash didn't help much in closing security vulnerabilities, but they took off in a much bigger way than Java applets ever did. ActiveX suffered from a strong degree of vendor and version tie-in, which is part of what has led to the legacy Internet Explorer versions still hanging around in offices all around the world. But in those early, tentative days of true web-based applications, any serious business was looking at ActiveX. To this day I run in to companies every now and then who are still using old applications written with ActiveX. Incidentally, most of them are facing a whole host of upgrade concerns.

Flash, on the other hand, was the playground. Suddenly there were animations, interactive elements, and sounds popping up everywhere across the web. Sometimes it was just one of those dreaded banner ads. Other sites had whole collections of full featured games coded in Flash. If you were around in those days, chances are good that you had more than a few of those Flash game sites bookmarked. It seemed a whole new world had been opened up. As long as you had the latest version of Flash installed, at least. They probably updated it again in the five minutes you were playing that game. The constant updates to the software, usually tied to some sort of security vulnerability, was one of the biggest complaints towards Flash over the years. But even despite these complaints, the adoption and usage of Flash was unprecedented in terms of web users. While designers and developers could never be totally certain of the Flash capabilities of their visitors, rest assured that the Flash version of their sites got a significant amount more views than the fallback version.

Around 2000, the push towards the usage of Dynamic HTML (or simply DHTML), started to gain a foothold. Rather than relying on Flash for simple interactions and animations, developers were leveraging Javascript and CSS in all sorts of new ways that worked across all systems and all browsers. Well, for the most part. There was still some work to be done in compatibility. Anyone developing sites around that time probably still remembers the appearance of Javascript image rollover scripts seemingly everywhere. The vast majority of them were tied in with that blasted "MM_preloadImages" code that everyone seemed to be using, but few really understood.

DHTML was an important change that helped define the direction dynamic content has headed ever since. Rather than relying on external applications and plugins to achieve dynamic effects, DHTML was using Javascript to directly leverage the DOM of a web page, so that there was no longer any separation of a site's static and dynamic elements. Theoretically, anything on the page could by dynamic, while still being secure (relative, of course, but generally more secure than plugin methods), and maintaining a much lower resource load than any of the plugins could manage. Although the early usage was confined to simple elements like mouseovers and drop down menus, requiring most major interactive sites to still rely on Flash, it laid an important groundwork.

There was one piece left to complete the puzzle that brings us to today's practices. That was Ajax. Microsoft first started using a form of Ajax in the late 90's for some content, although at the time it was still largely tied to ActiveX and iframe usage. It wasn't until the mid '00s that the Ajax name was actually coined, coinciding with a larger developer interest in the technology, primarily driven by the new features in Google's Gmail. The massive change in user experience brought about by the introduction of Gmail sent waves throughout the web. There were already a large number of webmail providers, and all of them tended to float around the same set of principles for design and usage. The introduction of Gmail blew all of that away, and many people for the first time started to see what a true web-based application could do. All of those things that developers had been talking about for years suddenly made sense. Of course, the huge upgrade in free storage space over their webmail competitors certainly helped adoption. Most of the old webmail providers are still struggling to keep up with the new model set out by Gmail, without giving up their identity that was so tied in to their old methods.

The new developments of Ajax usage, along with an added specification from the W3C, unhinged Ajax from any specific platform or plugin, tying in with DHTML to bring a standards-compliant, cross-browser solution to the dynamic content toolkit. It is this basic model that survives today, and is seen all across the web. There are a lot of new tools for achieving these results, all centered around that basic principle of using Ajax calls to receive information from the server, and client-side Javascript to update and manipulate elements on a page. And, thankfully for every web developer out there, pretty much all of the latest Javscript frameworks provide easy ways of managing the XMLHttpRequest and DOM objects without getting tangled up in the details that pure Javascript calls require. Of course, as it always is, this is a double-edged sword to many, who see a lot of developers using these simplified functions without any idea of what's going on. Truth is, this is always the case in matters of simplification, and a much larger debate than I'm willing to engage in here.

This is obviously a vast oversimplification of the history, and even of the current state of things. But maybe, for a change, that's how I wanted to look at the world around me. At least the web world around me. Which, if we're being honest, is a large portion of my world day to day anyways. Maybe I should go outside today.