Wednesday, 23 May 2007

Lawn Mowing with Scissors

Ever since I started developing applications for the web, which is about one and a half year ago, I've been feeling uneasy when I had to start developing the user interface. Invariably, turning a user interface from mock-up screens into a working one is somewhat of a trial-and-error affair, but web interfaces are about ten times worse than fat-client interfaces. There are several reasons for this, and they all have to do with me having to do a lot more, and very repetitive, work than should be necessary; in fact, they make me feel like a gardener being forced to mow a lawn with only a pair of scissors. I should add that I work in Java, using JSP and Struts, although I think my observations are valid for most web application frameworks.

Some of the reasons, for me, are the following:

  • Lack of encapsulation of components. If I want to reuse a "JSP form"-"action form"-"action" combo somewhere else in my code, or in another project, my only option is "copy and rename". Of course, I could use applets, but that involves launching a JVM on the client and lots of security restrictions. Ideally, I'd like to be able to parametrise the components, and reuse them in another place or project with one "function" call with instantiates all necessary items dynamically. Maybe an on-line pre-compiler in the style of the JSP compiler could handle this type of thing.

  • Impossibility of creating a full MVC setup. Updating fields that depend on other fields has to be done through case-specific Javascript (or AJAX nowadays), or by refreshing the full page through a round trip to the server. Values needed in several places usually end up in the request object, or (even worse) in the session object, where you must conscientiously remove them lest they stay put as long as the session lasts. "Push" updates to a page would alleviate this, but alas, in HTTP all initiative comes from the client.

  • Field-testing changes in action code requires a redeploy of the application. Changes in the layout are (thankfully) handled by on-the-fly JSP recompilation, but nevertheless this eats time like nothing else.

  • The recent trend of programming by configuration requires, for a single functionality in your program, to get configuration exactly right in many places. This greatly increases the probability of errors when you need to change something in your program. At least when your brain works more or less like mine. Spring and Hibernate configurations are manageable because they tend to be stable, but maintaining a Struts configuration is a nightmare when your application is not a simple one-page-to-the-next application. And there's so much of it!

  • Struts configuration gets an extra mention, because it is so easy to lose track of how all pages reference each other. The return of "goto"! I thought we got rid of that for good after Dijkstra's ACM article, but here it rears its head again... Its so easy to end up with incomprehensible spaghetti.

Being a relative novice in development for the web, I may miss a number of best practices in my development toolbox. Also, my employer is still on Java 1.4.2, so I haven't had the opportunity to play with annotation-enabled frameworks such as EJB3. And don't get me wrong, I think JSP and Struts are great frameworks that do a fantastic job of allowing me to write dynamic web applications. But even so, I cannot help but feeling that the abstractions provided by JSP and Struts focus too much on providing as many ways as possible to the developer to do something (Action, DispatchAction, LookupDispatchAction, ActionForm, DynaActionForm,...), rather than trying to take work off the hands of the developer.

Using a C/C++ analogy, I realize that there will always developers that prefer to handle memory management themselves, but I'll take a garbage collector any day; I prefer increased developer efficiency to increased program efficiency. I'd like to get increased developer efficiency from JSP and Struts too, but for me the mental load seems to increase more than it decreases. Oh well, probably this is simply the Lisp programmer in me longing for the good ol' days of yore...

Labels: , , ,