Lipstick on CGI
Lipstick on CGI
Join the DZone community and get the full member experience.Join For Free
Learn how error monitoring with Sentry closes the gap between the product team and your customers. With Sentry, you can focus on what you do best: building and scaling software that makes your users’ lives better.
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.
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
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.
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.
Opinions expressed by DZone contributors are their own.