In recent years, the promise of HTML5 has driven the rise of JavaScript. Browser vendors have escalated their arms race to create the fastest runtime environment. As a result, JavaScript has become too useful to be considered an optional enhancement. It's an essential component in today's web stack.
What if a web application depends on the canvas element to render graphics? What if it requires websockets to provide real time messaging? For most web pages, these features may be considered optional, but for some web applications they are the very raison d'etre. Like a tripod, the modern web stands tall on three feet: HTML, CSS and JavaScript. Take any one away and it all falls flat.
You must be at least this high to ride
In native applications, and gaming in particular, it's commonplace to list system requirements: the minimum specifications of operating system and hardware that are necessary to run a piece of software. Why should it be any different for web applications?
HTML5 technologies such as canvas and websockets make it possible to build applications in the browser that were previously unimaginable. In such instances, it's reasonable to state that JavaScript is a system requirement. When graphics are generated programmatically they can be animated. They can respond dynamically to events triggered by the user. If we throw websockets into the mix, the graphics could respond to events triggered by other users, somewhere else on the internet. The potential is dizzying.
To provide a dynamic experience such as this requires JavaScript. There's no way that a static page can be expected to provide a satisfactory fallback.
Stop worrying and learn to love the <body/>
Modern JavaScript engines are now so capable that we can demand more from them. We can move HTML template rendering from the server to the client. Instead of using JavaScript to massage data from one part of the DOM to another, we can bind our templates to client-side data stores. Any changes to the data will be reflected instantly in the DOM. A number of MVC libraries use this approach, making it possible to build maintainable large scale JavaScript applications.
Taking the client-side template rendering approach to its extreme, we end up with an .html document that contains one JavaScript, one stylesheet, and a self-closing <body/> tag (in fact, even the <head> and <body> tags are optional!). This may seem barbaric to those schooled in classical progressive enhancement, but it will feel more familiar to anyone with a background in native application development. And let's make one thing clear: web applications are in direct competition with native apps.
The case of Google Maps
Google revolutionised online mapping when they introduced the 'slippy map' interface of GMaps. Today, we can use progressive enhancement to embed a GMap on our own web pages, but it wasn't always so easy. Consider this timeline:
Web developers had already been embedding slippy maps on their web pages for almost three years before Google released the Static Maps API. Up until 2008, if you wanted to embed a GMap using progressive enhancement, you would have to look elsewhere to source a static map image.
Can I get a show of hands from developers who didn't bother? I'm unashamedly guilty.
Google brands the static and slippy GMap APIs as two distinct products, but I consider them to be two faces of the same service. The static maps API is a feature of GMaps. A feature that allows us to provide accessible GMaps to our users without JavaScript.
Accessibility is a feature
The web is composed of documents, mostly the written word. Accessibility comes practically for free, but only because of the intrinsic nature of text, and the accessibility features of the software with which we consume it. Since text documents are so readily accessible, we've come to think that everything else should be too.
Applications and documents are different. Accessibility is not a right; it's a feature. The first features to be implemented are the ones that define an application and determine its success.
Would Google enjoy such dominance in the online mapping space today if they had focussed on accessibility over dynamism? Someone else would have been first to market with a slippy map interface, and today we would know it by another name. GMaps succeeded because Google focussed on solving the problem well, rather than solving it twice.
The sacred cow
You won't find many people boasting that they've abandoned progressive enhancement. After all, nobody wants to be caught desecrating the sacred cow. But people are doing it today.
Consider Trello.com from Fog Creek. Joel Spolsky says:
"The business goal for Trello is to ultimately get to 100million users. That means that our highest priority is removing any obstacles to adoption. Anything that people might use as a reason not to use Trello has to be found and eliminated."
Trello wants to remove all obstacles to adoption. That's interesting, because if you try to use Trello with JavaScript disabled, you'll be served a blank page. Presumably, Mr Spolsky doesn't believe that this will prevent Trello from attracting 100million users. It's a brave new web.
JavaScript is driving change
HTML5 expands the potential of web applications, creating new opportunities for businesses. First movers will have the advantage. I believe that those who insist on putting JavaScript in the passenger seat will fall behind. In this time of change, JavaScript is the driver. That's progress.
Picture of Drew taken by Lena Ganssmann.
Designer and developer Jim Newbery doesn't quite agree with Drew. Read his response, Progressive enhancement is more relevant than ever, and let us know what you think below, in the comments.
