Once upon a time, I wrote simple client server applications in Visual Basic (VB3!) with an Oracle database back-end. My government client, who dictated requirements to me by reading DOS Clipper code aloud, was mystified by the whole client-server revolution, and impressed at what we could get done by leveraging the desktop computer to do some of the number-crunching required for this system. It turns out that, since everyone had increasing amounts of CPU power on their desktop, this newfangled client-server thing meant reduced costs in owning and maintaining mainframe server assets (which, in most cases, could be pushed off the nearest cliff).
This was the mid 1990s, and the government was finally catching on to this whole client-server thing. But the web revolution was brewing, and the hottest new language, Java was about to change everything. You see, client-server solved a lot of problems, but introduced a new one: version inconsistencies in the client could break your server. This meant paying strict attention to Progressive Enhancement, that paradigm in which each new change is magically backwards-compatible (or, at a minimum, wouldn’t break things for people on older clients).
With Java, though, this didn’t matter: since the applet actually lived on the server and was distributed via the web, each client would download the latest version of the software at the start of every session. But what about the server? In the database, subsequent enhancements to the data model have to be done in a way that prevents corruption or integrity problems in the existing data. So we still had to obey the Gods of Progressive Enhancement, lest the whole thing come crashing down around our heads.
Eventually, the N-tier system won out, and today we have the familiar architecture of browser (view-only client), web server/app server (functional/procedural business logic), and database (data storage and integrity rules), with other services thrown in as needed (server-side observers/notifiers, periodic taskings, etc.). The so-called Services Oriented Architecture can be thought of as a bunch of highly promiscuous application servers existing in a series of XML-over-http-wrapped cocoons. It’s still N-tier, but N is a really high number indeed.
Throughout all of this, the paradigm of Progressive Enhancement remained: there’s always *something* out there relying on your service continuing to meet the contracts you established when you published the service. There’s a reason that features are deprecated long before they are removed. And there’s a reason why languages and platforms are pilloried for breaking older code (I’m looking at you PHP 5.3, and you, Python 3, and I just don’t even want to look at Facebook).
So then there’s this post by Nick Morgan suggesting the end of Progressive Enhancement may be near, at least for JavaScript. Interestingly, it’s occasioned by a bit of history repeating itself; what’s happening now is that JavaScript is increasingly becoming a tool for building an independent client application that just happens to be deployed by the browser. If you don’t believe that’s really happening, then try updating your resume on Monster.com while you have JavaScript turned off. I’m betting you won’t get past the login prompt.
So, with JavaScript, we’re working our way back to the way things were under Java. Everyone gets the latest app! Only, they don’t all have the same runtime environment, so now our applet has to check for browser versions and behave differently in each one … sound familiar? We know how this ended for Java – with a move to well-controlled server VRE (and the slightly less well-controlled Android SDK) and eventual deprecation in the browser by Google (who recently disabled Java by default) and Apple (who gave up maintaining their own Java VRE).
One possible path for JavaScript, which I agree is essential to the current web experience, is that changes to the JavaScript, HTML, CSS and to browsers will make it possible to write your app DRYly, rendering HTML in exactly one spot, while exposing a JSON or JSON-like API for JavaScript clients. And another possibility is that the rise in mobile devices may make JavaScript irrelevant. The web server would then exist as a glorified API, spitting out HTML for web-based apps and JSON (or maybe Objective-C Object Notation, or Python Object Notation?) for use in mobile devices.
