Blogger: Chris Haddad
In the near past, Java Servlets, ASP-Classic, and Perl scripts were the truth for web application development. Developers were beholden to HTTP name/value pairs and generated HTML pages via page templates. In 1996, I had a meeting in Redmond with a Microsoft lead Program Manager for ASP Classic. I mentioned that ASP Classic did not enforce a correct separation of concerns between page layout, actions, and business logic. I was thrown out the door and exiled from Redmond for ten years. During my exile, I built intranets with various technologies including ASP Classic and COM, ASP.NET and C#, Apache Struts and Java Server Pages (JSP), in-house developed widget libraries, and DHTML and JavaScript. During my journey out in the cold, I found a sense of elegance missing from all solutions.
Over the years, best practices morphed from tightly coupled page templating to use of a Model-View-Controller pattern. But MVC-oriented web applications have glaring limitations. The frameworks subvert the Web model (for example, Universal Resource Locators [URLs] are no longer valid) and convoluted ‘switch’ statements are often used to route client requests to back end transactions. Additionally, the browser container hailed in the late nineties as the ultimate application host has enslaved application development and balkanized the runtime landscape. A disconnect between client and server capabilities existing in the frameworks, supported languages, and domain models. Client tier development has remained on a starvation diet for the last eleven years, and the backlash against the gaunt, thin clients is on the rise.
While presentation frameworks have experimented with event models and added buzzwords to their ‘features list’ (AJAX, Web 2.0, Service Oriented Architecture [SOA], and Rich Internet Applications [RIA]), a Redpill is needed to break out of the MVC Matrix and enable creation of ‘fit clients’. Vendors such as Adobe, Appcelerator, and Lazlo Systems enforce loose coupling between client pages and server-side application logic by injecting a service layer. A message-oriented interaction instead of a page-oriented interaction will enable developers to experience a new perspective on application interactivity, decouple client-side technologies from server-side technologies, and break down traditional application silo boundaries.
Comments