Origins

When HTML was first dreamed up, its original intention was "to use and share documents" across single or multiple networks. Tim Berners-Lee was the man who wrote the simple tags which defined the structure of how HTML presents a document. With the rapid growth of the interconnected networks (Internet), HTML quickly became the default option when providing a document for viewing across networks.

Server-Side Scripting

Enter: Capitalism. Once people realized the potential of being able to provide content to anyone around the world, ideas began to manifest themselves at break-neck speed, and HTML was the main vessel for this craze. Sites began to pop up offering different services, all based on HTML. The first adaptation of HTML occurred when scripts that ran on the HTML server were used to determine what to show on the HTML document and to whom. There are a plethora of server-side scripting languages and frameworks. To name a few: ASP.NET, PHP, Ruby, Perl, Python... the list goes on. Each are very unique and require a lot of expertise to successfully deliver.

JavaScript

Since HTML was already being stretched to do things it wasn't meant to, the need arose for it to do even more. Instead of modifying the standard itself, a single hero created a band-aid solution to give HTML a more dynamic user experience. Brendan Eich implemented a browser-based scripting language which later became known as "JavaScript" for Netscape's 2.0 release in 1995. This band-aid was quickly adopted across browsers to allow web developers to give their content a more dynamic feel. Each browser interpreting the script as they saw fit, and adding/removing support for specific features at will.

AJAX

JavaScript became very popular, and quickly caused businesses to move on to the next level, which is to provide web users a dynamic-data driven experience. Since the only way to change what was on a web page was to make a full web request to the server, the need arose for something to make a "mini-request" which could then be used to update specific elements on a page, or perform other lucrative functions for web-based businesses. Another band-aid was created by Microsoft when Internet Explorer 5 implemented an ActiveX plugin for dynamically refreshing content via a protocol known as AJAX (Asynchronous Javascript and XML). The other browsers quickly adopted and refined this concept by adding this functionality to their JavaScript support. This allowed web developers to make requests and change the HTML on a page, without refreshing the entire page.

Javascript Libraries

With the skyrocketing demand for websites that provided dynamic content for HTML based web clients, developers find themselves scrambling to build websites that deliver the desired functionality across all browsing platforms. The next problem that arose is that browsers tend to interpret JavaScript in different ways, causing massive headache and testing overhead for web developers. Groups of frustrated developers have banded together to try to create a solution for this problem in the form of JavaScript Libraries, which expose common methods that behave identically in every browser. The most popular of these are jQuery, Dojo and MooTools.

You are here

Present day. Web developers consecutively use dozens of tools to build custom/dynamic web experiences for businesses. Since HTML was not intended to do such nonsense, we constantly trip around the many band-aids used to make the web experience what it is today. Realizing this problem, a handful of proprietary solutions have been invented, and have seen various levels of adoption, but none as widely adopted as HTML itself. Some of these solutions are Flash, Silverlight and Java Applets, which claim to provide a rich, global user experience across browsers and platforms. 

Why don't those proprietary solutions work? They're proprietary, that's why. Granted, they have their bonuses of being able to control things in a closed environment, they do not have the adoption necessary or the standards behind them to reach 100% of users. So what's the best solution for getting around all these band-aids in a universally acceptable way?

Solution

Scrap HTML, and create something that addresses all of these issues from scratch. People want to see cool things. They want to interact with cool things. Can we make a standard that uniformly addresses those two issues? I think we can.

Html 5

HTML 5 attempts to do just that. It is a drastic leap forward in the HTML standard, which has evovled slowly over the years. HTML 5 incorporates all the of current display needs of the web, and combines them into a single standard, which has already seen global adoption. Does this solve the problem? Nope. HTML 5 is still a static display syntax which is dynamically altered with JavaScript, and you still have HTML 5 documents being constructed and delivered based on the logic of server-side scripting.

But we're moving in the right direction. With the various display capabilities of HTML 5, including some dynamic behaviors, HTML is aiming to standardize the way things are viewed and interacted with today on the web. Maybe in HTML 6 or 7, a full library definition will be created for providing dynamic behavor on the client. Leaving the last issue to be resolved: server-side scripting.

Notes:

A couple ideas to look out for, which might end up providing the ultimate solution:
- Opa: A single-source scripting language for creating dynamic and data-driven applications on the web.
- Node.js: A server-side framework for building websites using JavaScript (uniting the syntax between dynamic client and dynamic server behavior)