If hypermedia is meant to be the engine of application state (HATEOAS) and we can think of that engine being driven by a browser then what role does Javascript play? Javascript (in the browser) should depend upon hypermedia to provide a richer user experience. However, hypermedia and Javascript should not be co-dependent.

Javascript is not hypermedia. A resource’s representation should contain information describing possible states. A user’s ability to choose her next state should not depend on Javascript to facilitate that change. Javascript should be used to enhance these state changes rather than define them.

Ridiculous Car Analogy

Tightly coupling a web application to Javascript would be like a car manufacturer installing a giant LCD screen in place of a windshield. This “video windshield” may provide a better driving experience, but if it fails or is buggy then that could seriously limit the driver’s ability to use the car. Someday manufacturers may choose to add such a device to cars. If that day ever comes I imagine it will function first as a windshield and second as a HUD. And the former is not likely to be dependent upon the latter. Of course, one could always assume that users are okay with (or even prefer!) driving around like Ace Ventura. The fact is, the “video windshield” has nothing to do with driving just as Javascript has nothing to do with the web. A rich user experience through client-side scripting has to do with the client (read: browser).

I imagine I could be lectured on the finer points of how this analogy falls apart, but if you would like to further discuss the minutia of analogies then I would like to introduce you to the keyboard shortcut (cmd|ctrl)+w.

The User’s Hierarchy of Needs

Understanding the importance of decoupling highlights why Progressive Enhancement is so important to creating a quality user experience on the web. Progressive Enhancement is not only a recipe for accessibility it is also a natural driver of Minimum Viable Products. By relying on standards to create the user experience it is possible to provide a baseline of functionality. There is a hierarchy of needs involved in any user interaction:

The goal should be delighting users, and that goal is reached by correctly addressing their needs. Users will inevitably disprove assumptions, and adapting quickly to new knowledge about users’ expectations is easier in loosely coupled systems. Most users will value a working system over a beautiful, broken system. The lesson is:

1. Build the simplest, working system.
2. Then make it efficient.
3. Then make it a pleasure to use.

I want to clarify, however, that these steps are iterative and should be refined as more knowledge is gained. The real challenge in product development is finding the line where these separate. Fortunately, in the case of web development we have Progressive Enhancement to give us some simple guidelines. HTML is the engine. Stylesheets put things in the right place. Javascript provides a more engaging experience. If functionality can only be had with all of the above then there will be very serious issues for the user and the developer..

The Future of Javascript as Hypermedia (or How I Learned to Separate Concerns and Love the JSON)

I’ve shown that separation of concern in web development is important, but what does that have to do with Javascript not being hypermedia? I believe that Douglas Crockford is right when he says Javascript is a misunderstood language. In order to facilitate an understanding of what Javascript (read: ECMAScript) is it is firstly important that web developers see Javascript as separate from the web. Once it is understood separately it is easier to see that Javascript can be many different things—even hypermedia. Specifically, JSON has shown some promise toward becoming a form of hypermedia but it lacks standards. I think that is a hurdle JSON can overcome as people rally around it. It is much easier to parse than XML both technically and visually (see Mike Amundsen’s post on JSON hypermedia for an example of what this could look like).

I look forward to the day when more people recognize the ubiquity of Javascript. It is already being used for map-reduce functions in non-relational databases, REST-like APIs, writing highly concurrent servers, and building rich, interactive client-side applications powered by hypermedia. Javascript has a bright future; something many would’ve said was unlikely ten years ago. And I, for one, welcome our new functional, dynamically-typed language overlords brethren.