How to Architect Next-Generation Web Applications

Do you remember the first time you used Google Maps? I do. I remember being stunned by the usability and then thinking, "If this has always been possible in a browser, why did it take 10 years before someone did it?"

The reality is that Google Maps is a feat of engineering that consists of almost 10,000 lines of JavaScript code executing within the browser. You can see much of this code by clicking on “View Source” from within your Web browser. However, this is not the standard JavaScript that is used to validate fields of a Web form or provide drop-down menus. Many JavaScript veterans would struggle to follow the source code because it is so complex. 

So, is it possible for mere mortals to build RIAs (Rich Internet Applications), or does it require a development team like Google’s, composed of PhD-carrying JavaScript ninjas? Increasingly, the answer is “Yes, it is possible.” Many tools and libraries have been created (both commercial and open source) to reduce the complexity of building RIAs.

An interesting, related trend is the movement of more and more logic off the server and into the client's browser. Fueled by the ubiquity of broadband connectivity, the increased processing power of PCs and improvements in browser support for JavaScript, the amount of JavaScript code embedded in a Web page has jumped significantly in the past few years. While users may not understand the technology underneath, they do notice that fewer of their clicks require a complete page refresh (that is, rating an article by clicking on a number of stars). As the migration of user interface logic off the server and into the client accelerates, the obvious question becomes, "Why do ANY UI logic on the server?" Answer: Because change is hard, so people naturally resist it.

Since the first CGI (Common Gateway Interface) program in 1995 generated HTML dynamically in response to a Web request, we have continuously built on this concept of server-side, dynamic HTML generation. Innovations in Web development were often just abstractions built on top of this concept. But abstraction is a double-edged sword. It eliminates the need to understand everything going on under the hood. However, each abstraction layer typically includes its own configuration, quirks and conventions. The result is that Web development has become unnecessarily complex (for example, Java Platform, Enterprise Edition 5).

One of the main reasons for this complexity is that Web application architectures are still an evolution of the CGI model from 1995. But, at the time CGI was invented, a different programming model dominated the software development landscape. It was known as “client-server.” The client-server years are likely the single most productive era in software application development. But when the tidal wave of the Web hit, there was no turning back.

One of the most compelling concepts of client-server computing was the idea that the UI should be independent of the technology chosen for the business logic and data persistence. In today's Web programming model, if you decide to change your middle tier from Java to Ruby, you rewrite your entire UI, generating HTML from .rb scripts instead of .jsp scripts.  The UI is tightly coupled with the server-side technology choice.

An opportunity exists today that hasn't existed until recently (outside of building UIs completely inside a proprietary player such as Flash). Stop generating your UIs from server-side scripts. Write rich Web applications as standalone clients based on open standards such as HTML, CSS (Cascading Style Sheets) and JavaScript that interact with the server-side purely through Web services. Call it “client-server” 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 (Document Object Model) manipulation, and finally, AJAX (Asynchronous JavaScript and XML) that allowed us to build truly standalone Web clients. 

An interesting result of this model is the division of labor created by isolating the technology skills to the specific layer of the architecture. You can have UI developers who know only HTML, CSS and JavaScript, instead of paying a Java 2 Platform, Enterprise Edition (J2EE) architect lots of money to write Web pages. Likewise, your server-side developers can focus on providing service-oriented business logic and persistence rather than adding bold tags to Web pages. 

The Web is morphing into a delivery platform for client applications that consume external services from one or many sources, as well as a platform that provides a rich user experience with minimal page turns. This is the future of Web development. The client operating system IS the browser. Need proof? See the rise of offline, SSBs (Single Site Browsers) and desktop Web integration. 

Welcome to client-server 2.0. The only question left is: How long before you starting writing your Web applications as standalone, true Web clients?

 Matthew Quinlan is vice president of community development at Appcelerator, an open source-rich, Internet application company. He leads the company's brand awareness, community development and demand generation programs. He has been programming continually since 1981. He has focused on Web technologies since 1997, when he became chief architect of ValueAmerica.com, one of the first online retailers.

As a professional consultant, Quinlan provided guidance on Web development, architecture and content management to Motorola, UPS, Sprint, Vanguard, Intel and dozens of other companies. He has taught courses on Java and Java 2 Platform, Enterprise Edition (J2EE). He was a founding member of the JBoss evangelist team, where he spoke about open-source software, Java/J2EE and Web application development at industry events and user groups around the country.