Lipstick on CGI

The Perversion of CGI

It was 1997 and while I was enamored with the web as an information portal, I hadn't really embraced the web yet as a programmer. While I had played with HTML, I was convinced that real developers wrote in C/C++ and PL-SQL. HTML was for sissies. One of my co-workers was building an online search engine for one of the original e-commerce retailers and he introduced me to CGI programming. The idea of redirecting the incoming HTTP request to a script that generated HTML on the fly instead of regurgitating the contents of a file seemed immensely cool to me at the time. As the technology continued to build on this basic concept we gained modularization with SSI (server-side includes), embeddable scripts with ASP/JSP, abstraction with tag-libraries, MVC with Struts, inversion of control with AOP (aspect-oriented programming), web conversations with JBoss Seam, etc.

However, I never really questioned the basic premise that web applications are essentially a collection of scripts which dynamically generate HTML documents and share a server-side context (http session). Afterall, all of the server-side web technologies I had used were based on the same fundamental concept that CGI had introduced back in 1995. Most innovations in this area were just further abstractions built on top of this concept (e.g. JSP custom taglibs). But abstraction is a double-edged sword. It eliminates the need to understand everything going on under the covers. However, each abstraction layer typically includes its own configuration (struts XML hell), quirks, and conventions. Which results in the need for someone to define "best practices" based on their personal pain of figuring out where the friction points are between the layers of abstraction that live just above and just below it (e.g. ValueObjects/DataTransferObjects).

As a result of these abstractions building stable maintainable scalable web applications has become much more complex than necessary. The software community responded to this complexity with a renewed focus on simplification such as Ruby on Rails, annotations, configuration by exception, etc.). Each of these efforts were a significant evolution of web application development, but none were revolutionary. While undeniably valuable, they were still just lipstick on CGI.

The Lessons of Client-Server

When the web tidal wave hit in the mid-1990s, client-server programming was almost completely forgotten. However, for those programmers who were never exposed to client-server there are some truly valuable lessons that can be leveraged in web programming.

First, the idea that my GUI should be completely independent of the technology choices for the business logic. In a web application the View is actually the HTML & JavaScript residing in the browser. However, since the view must be generated by your server-side scripting language it means that if you want to change your business logic from Java to C# you do not get to keep your View. The GUI is therefore tightly coupled with the server-side technology choice.

The second interesting concept from client-server is that transient state was held within the client so that all of my invocations of business logic or persistence were essentially stateless. When we first built web applications we had no means of storing this client state within the browser (cookies are too expensive) so we relocated client state to the server! Of course, we renamed client state to session state so that we could live in denial of this awkward and unnatural separation. Of course, the implications of this architecture are most obvious when you observe the computational gymnastics that vendors must endur to support fault-tolerance and failover (e.g. in-memory session replication, sticky sessions, auto-persistence of inherantly transient state). Why can't I just store my client state in the browser?

Enter True Web Clients

There is an opportunity today that really hasn't existed until recently (outside of building GUIs completely inside a proprietary player like Flash). Stop generating your GUI from server-side scripts. Write rich web applications as standalone clients based on open standards such as HTML, CSS, and JavaScript that interact with the server-side purely through web-services (XML/HTTP, SOAP, JSON, REST, etc.). Call it Client-Server 2.0 if you like, but without the baggage of software distribution, version management, and platform dependencies (granted, we replace this with browser dependencies). While JavaScript was the foundation of this revolution it was the introduction of CSS (cascading style sheets), DOM (document object model) manipulation, and finally Ajax (asynchronous JavaScript and XML) that allowed us to build truly standalone web clients.

So how do you go about building true web clients? Until recently this was a fairly daunting task that required you to be a JavaScript ninja. You had to choose one or more widget libraries (e.g. ExtJS, Yahoo! YUI, Google GWT), maybe an effects library (e.g. scriptaculous), a communications mechanism (e.g. DWR, Comet), and maybe a general JavaScript framework like Prototype or JQuery for DOM manipulation and other miscellaneous timesavers. Now just weave all of those together, learn all of the APIs, test that the versions are compatible and you are ready to rock! At least until one of them releases a new version.

We need mere mortals (not just Google PhDs) to be capable of developing rich web applications as standalone clients. A simple web programming model which decouples the GUI from the server, provides a consistent widget model (regardless of the widget library chosen), declaratively defines the user interface (remember HTML?), provides a simple yet powerful distributed communication mechanism, and generally simplifies the effort necessary to build pure web clients.

Several efforts are underway to address this challenge, but a clear winner has yet to emerge. Maybe HTML version 5 will address enough of this to make the issue moot. But how long will it be before everyone is running HTML5 compliant browsers? (You wouldn't believe how much IE6 is still out there.) Some of the JavaScript libraries and frameworks I've mentioned in this article are trying to expand their focus to address the larger picture. Dojo is a good example.

Appcelerator

The most elegant solution I've found is called Appcelerator. The basic aim of the Appcelerator platform is to provide simple yet powerful means of developing rich internet applications (RIAs) that are based on established web standards. And because the user interface is not generated by the server-side (interaction is through simple JSON-based services) your server-side can be written in Java/JEE, .Net, PHP, Ruby, Python, or Perl. This decoupling means that I can finally create a division of labor where my GUI developer can focus purely on HTML, CSS, and JavaScript and my middleware developers can write business logic, build services, manage transactions, and provide data access.

Whether Appcelerator becomes the dominant RIA platform or not, the shift to the client-side for web applications is undeniable. The client operating system IS the browser. See the rise of offline, single-site-browsers, and desktop web integration. The clients call services and re-render themselves accordingly. The only question remaining is… how long before you starting writing your webapps as standalone true web clients?

DISLAIMER: I was so impressed by the Appcelerator technology that in February of 2008 I joined the company.