Lipstick on CGI

It was 1997 and 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 an e-commerce company 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. Technology advanced and I followed with SSI, then servlets, then ASP, then JSP, then taglibs, then struts, then JSF, etc.

However, I never really questioned the basic premise that web applications are essentially a simple 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).

Building web applications has become much more complex than necessary and the the development community has responded with simplification efforts (think 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.

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 HTML on the server-side. Write rich web applications as standalone clients based on open standards such as HTML, CSS, and JavaScript. Call it Client-Server 2.0 if you like, but without the baggage of software distribution, version management, and platform dependencies. While JavaScript was the foundation of this revolution it was the introduction of CSS, DOM manipulation, and finally AJAX that allowed us to build truly standalone web clients.

So how do you go about building true web clients? Until recently it was actually rather painful to do so. You had to be a JavaScript guru and even then you typically were weaving together multiple 3rd party JavaScript libraries and frameworks to provide the necessary event handling, DOM manipulation, parsing, etc. Appcelerator was designed specifically to simplify the development of web clients so that mere mortals can develop them (not just the PhDs @ Google). Yes, you can use all of the Appcelerator widgets and even leverage the client messaging bus without giving up your HTML generation scripts (and many people do). But once you've experienced the elegant simplicity of developing true standalone web clients that invoke services for business logic & data access, you will never go back.

The shift is already underway. 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 webapps as standalone web clients?

(cross-posted from Appcelerant)