For enterprise app dev, and to support a following blog entry, I’d like to recap some technology choices that have previously used since the advent of the web.

Also see the following blog entry that is about enterprise web-app technology choices for 2012, and new challenges for where the object model is running.

What’s the synopsis of this blog-entry?

Over the years, logic is progressively migrating from a web-server tier into the browser. Pattens, practices and responsibilities were established in the web-server tier, and were starting to be defined in the web page.

1993

Web applications were still tightly bound to the server hosting them. Java, Python, PHP and Ruby were a few years from becoming realities for web development. Perl perhaps was a possibility for web development, but you were most likely a C++ developer if you were making web-apps. If Awk were viable then, I can’t glean that from the wikipedia page for it. JavaScript was a year away, and wouldn’t be called JavaScript for another two. If you submitted a form and hit the back button, you had little hope of anything useful happening.

Beyond the declarative nature of HTML programming, and the understanding of the contracts behind URLs, there was no functionality in any turing-complete manner present in web pages.

Web application development in 1993, 2000 and 2006.

2000

In the year 2000, Sun’s Java Servlets or Java Server Pages (JSP) apps were a possibility with Model-View-Controller (MVC) being the recommended pattern. Microsoft had recovered from the mistake of ignoring the web in 1995, and had made Active Server Pages (ASP) the most popular enterprise solution. Indeed they had their fork of Java (google for “Project COOL”) .Net ready for enterprise app dev (see later). PHP had come from nowhere as a CGI solution, and Apache with that mechanism of linkage was the most popular web server. You might have even seen /cgi-bin/ in the URLs of web applications, though rewrites were possible. Allaire’s Cold Fusion (an independent IIS data-binding solution) had by then been snubbed when Microsoft didn’t buy the 90% of the company they didn’t already own and launched ASP instead. ASP apps followed the data-binding solution that fatter MS-Access solutions had pioneered for years. ASP.Net was still two years away though. Python and Ruby may have been used in CGI mode, but Rails (in 2003 I foolishly told DHH it wouldn’t scale in the enterprise) was still three years away, and Django two more. Microsoft had pioneered AJAX style functionality in ActiveX controls, and you might have encountered applications that used them. Similarly Sun could still make a claim that Java Applets were a reality on the web at large. Macromedia’s Shockwave/Flash was a viable platform that competed with, and would ultimately beat both ActiveX & Java Applets.

Cookies are in every app by now (thanks to Netscape and Microsoft’s subsequent adoption of them). JavaScript if used, was mostly for simpler validation concepts within pages, before allowing the POST to go through.

2006

AJAX was the big thing. Between them Microsoft, Netscape and Google had made it popular. Most enterprise teams were building apps that were somewhere between Web 1.0 and Web 2.0. Roy Fielding’s REST is big but it required some decoding for the layman. Ruby on Rails had been a significant productivity force for a year or two. The .Net offerings for the web were solid 2.0 a year before and before the end of the year 3.0 would be released. Model-View-Presenter (MVP) was the paradigm, and Martin talked about it after some initial ThoughtWorks projects with .Net. Microsoft’s patterns and practices group would later talk about it too. That’s not to say that MVC is dead - most of the non-.Net frameworks are coded in accordance with it. All web-app best practitioners were now doing POST-redirect-GET (PRG) and you finally hit the back button after posting a form - take that Tim Berners-Lee. ThoughtWorks had a year or two before pushed out Selenium for web-testing (and was one of the early pioneers of Comet as a result), then Sahi for another go at the same idea, with WebDriver (now Selenium2) to come a year later. Web applications were now beautifully decomposed solutions, illustrating Separation of Concerns, Inversion of Control, if not Dependency Injection in particular.

JavaScript usage is quite sophisticated now. Applications might issue AJAX operations to the back end to help with adaptive parts of the page, or individual controls. Libraries exist to allow developers to economize and standardize on idioms. These were YUI, Prototype, script.aculo.us, Dojo, and Mootools, but would see future “winner” of the genus, JQuery, arrive by the years end. Early adopters would try out (in order of revolutionary zeal) ExtJs, and Google Web Toolkit, but the industry remained divided as to whether devs should embrace JavaScript or avoid it completely in the browser. Cappuccino (even more revolutionary) would come a couple of years later, and suffer the same question.

For the purposes of the following article, the take away is that Model-View-Controller in the web-server tier (as delivered by web frameworks) is a big thing in 2006.