Practical options for building Web 2.0 applications

by Dafydd Rees

The backlash against large, complex web development tools has been building up for a number of years. In the last year or so we've seen substantial adoption of more concise web development frameworks written by small groups of open source developers. These frameworks promise to be simpler for developers to use and require less code be written. This article explains this new direction in web development and why it matters.

The Problem with J2EE and .Net

Unfortunately both the J2EE and the .Net approach often involve many layers of code, infrastruc-ture and complex configuration. For example a developer building a web application using J2EE might start a web project deciding which existing frameworks to use to handle these concerns:

• Mapping rows in the database to objects in the code
• Managing which piece of code runs in response to each web request
• Deciding which templating system or builder framework to use to generate the web page to be sent back to the web browser.
• User authentication and account management

Just choosing and configuring the minimal number of layers needed for the first release of a project could take a few days time! Although the situation is a little better for Microsoft developers there are many "alternative" frameworks in the Microsoft world that developers can choose to simplify or customise different aspects of their work.

It's no longer the case that a developer can say "I'm a Java developer". Now we have an industry in which people are interested in whether you're a "Java developer that uses Spring MVC and Hibernate" or a "Java developer that uses webwork and toplink". This leads to a lot of politics and ridiculous levels of specialisation.

Web applications often have large numbers of configuration files tying each layer together, and it's often the case that the same concept is described in three or four different places in the same application. For example there might be a customer database table, a customer mapping file describing how to turn a row in the database into an object in memory. In many cases, the developer ends up describing the fact that "a customer has a name and an email address" in three different places. This often makes for a verbose, bloated codebase in which developers are constantly wading through verbose definitions, worrying about consistency rather than describing the unique, new behaviour that warranted writing the application in the first place.

There are a number of popular explanations for this state of affairs:

• Fear-based selling - This occurs when a tool vendor conjures up possible scenarios where the business misses an opportunity because some feature wasn't present from the start or because the infrastructure didn't scale up to meet demand. This pressurises developers (and often their non-technical managers) to carry infrastructure that they may never need.
• The framework makers aren't the users - Many developers point out that there's often a differ-ence in approach between making a tool for someone else to use and making it for yourself. For ex-ample, the Java and C# programming languages go to considerable lengths to prevent you from do-ing certain things. This can mean adding an entire new library that provides an alternative way of doing something because you're not allowed to change the built-in way of doing something.
• Compiled Languages and Code Generation - Having to stop every so often compile code means that you can't get immediate feedback from changing some aspect of your web application. Code generation is especially bad because you usually get error messages that are one step removed from the original files used to generate the running application.

What users now expect from your site

• AJAX - The use of Javascript to make the user experience more interactive. This is usually done to update part of a page rather than reloading the whole thing.
• RSS - This is a feature that allows users to subscribe to a "feed" of changes from a website. Now that both Internet Explorer 7 under Windows and Safari on the Mac support RSS subscriptions this technology is mainstream.
• A developer "API" - It's becoming increasingly common for websites to provide an "application programming interface" for third-party software and websites. For example, many users of social networking websites are coming to expect to use data from one site on another. This requires that websites publish official, supported ways for third-party software to interact with their site.

Web Frameworks Based on Dynamic Languages

The three best known of these new frameworks is "Ruby on Rails", "Django" and "Turbogears". The "Ruby on Rails" framework is written in Ruby whereas "Django" and "Turbogears" are both written in Python.

It's worth considering what these frameworks have in common:

• A whole system - All three frameworks provide web-page templating, control routing web requests to code, running a behaviour in response to a request and mapping data from the database into an object model in the programming language. The normal procedure is to create a project by running a command that generates a skeleton project.
• An opinionated approach - A framework can be considered a working system with "blanks" that are to be filled in by the application programmer, whereas a library is typically a collection of re-usable code that can be plugged together in an ad-hoc fashion. Learning Rails, Django or Tur-boGears is a matter of learning how to describe your problem in terms of additions to the existing framework. Django for example, was created by developers in the newspaper industry, hence it pro-vides considerable automated support for "administration screens" so that the developers can con-centrate on the public-facing website.
• Convention over Configuration - Rather than adopt the approach common with J2EE and .Net where each framework requires a lengthy set of configuration settings, there are many conventions. For example, Rails uses a set of naming conventions to infer relationships between classes in ruby and tables in the database. This means that it's only necessary to configure the framework where the conventions are ambiguous and where you need to deviate from the framework convention. (For example, if you're developing a new intranet site within a company using a legacy database, you'd have to configure Rails so that it knows which tables to use for each class.) This is about minimis-ing the amount of code written and encouraging a standard approach.
• Model-View-Controller Architecture - Django, Rails and Turbogears all have the same three, ma-jor kinds of objects: "models", "views" and "controllers". Models represent things held in the data-base, controllers handle requests from the web and build a response whereas views are usually tem-plated HTML pages built based on the response from a controller.

Ruby on Rails is the best-known of the three frameworks and has seen enormous growth in the last two years. This is clear from the explosion in the number of Ruby and Ruby on Rails books, courses and conferences. Rails has extensive support for test-driven development, separating out unit, functional and integration tests. It should be noted though that Rails developers often test their applications differently from Java and C# developers. "Unit testing" in Rails almost always means testing individual "model" classes, and "functional testing" almost always means testing a "controller". It's worth mentioning that Rails, like many ruby applications tends to build objects use them briefly and discard them. Programmers used to Java and Smalltalk will find this disconcerting and can it make Rails difficult to trace.

The biggest decision here is between Rails, the market leader and either of the Python-based alter-natives. Ruby has few high-profile uses beyond Rails whereas there are many well-known Python projects. If you already know Python it's tempting to try Django or Turbogears. A year or so ago, there were noticable differences between the Django and Turbogears feature-sets, although now they are fairly equal. Some people recommend Django over Rails for applications that are are close to being a straight "content management system". Perhaps this isn't surprising since Django evolved in a media environment.

There's still lots of good money to be made writing C# and Java applications although these new frameworks illustrate that there far faster and simpler approaches than the standard Java or .Net way to build a web application. In this article we just considered three of the better known frameworks.

Links:
Ruby on Rails: www.rubyonrails.org
The TurboGears framework: www.turbogears.org
Django: www.djangoproject.com
Sean Kelly, "Better Web Application Development", video.google.com/videoplay?docid=6297126166376226181. A good demonstration of the problems of J2EE and how frameworks based on dynamic languages can help. (Note that the feature sets mentioned for Django and Turbogears are out of date.)

About the author:
Dafydd Rees is a software developer specialising in object-technology and agile methods. He welcomes feedback on this article at www.dafydd.net/feedback.php

Send a comment about this article to editor@itwales.com.