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: , , ,


Anonymous said...

Java... that's your first problem.

You didn't even mention the fact that your finished result is going to run like crap on anything but proprietary hardware.

"Sure it's 'portable', but we didn't say it's 'practical'"

23 May 2007 21:37  
Niche Software said...

You've hit the nail on the head as far as identifying the key pain points. But what's the solution? Actually your problem really stems from using an old framework. You didn't say which version of Struts, but if you're still on Java 1.4 it's probably the older pre-WebWork Struts. Yup, control flow gets quickly out of hand.

The new problem is too many frameworks all trying to solve the same problems. Despite their proliferation there's lots of good options. Spring Web Flow goes a long way toward simplifying the control flow between the forms. If you want encapsulation and reuse switch to a component-based framework like Tapestry or some JSF-based framework like Shale. And you can always dump JSP/JSTL for Velocity, which is easier. Except I hate this alphabet soup crap: too many frameworks to learn, and the biggest are never the best.

I think the next big thing will be moving off this HTML obsession and creating more mid-fat clients. Flex probably has the lead here since their plugins are so widespread. There's also OpenLazlo and some other funky mid-weight frameworks. Sun's trying to re-vitalize Java Web Start and even Applets, but that may take some time. Depends on the app (good for internal apps, bad for public web apps).

23 May 2007 22:23  
Joris Van Looveren said...

@niche: lots of options and too little time to evaluate them all. Also, I'm not the one who decides which technologies I am to use... A common problem I guess, and as you say: the biggest frameworks are never the best, but they are what employers tend to choose.

While I try to do other things in my free time besides computing ;) I'm going to play around some with UnCommon Web, a Lisp-based web app framework that seems rather different from "traditional" frameworks.

24 May 2007 07:10  
Leo said...

Hi Joris,
I think you're absolutely right; the frameworks we use have become too complex to learn and handle, and they obfuscate code more than necessary. I have to work with the same stuff as you do, and boy, sometimes it really sucks. You can alleviate the pain by using a decent IDE, though; I use Eclipse with the (soon to be free) Exadel Studio Pro plugin and that has _really_ improved my productivity. Second, I don't use so-called MVC so much any more because it smears intent all over the project; I'm going back more and more to plain JSPs and do all the form handling and database access in them, occasionally factoring out helper routines to (yuck!) includes. For me that's ok because I'm working on small, additional components that don't have to fit in the overall "architecture" (call the beast by its name!), but it may not be the choice for everyone. It's definitely not my favourite environment as I can only choose the lesser evil.
As niche software said, we're seeing the transition to fatter clients, and that's my choice, too, because of the clear separation of layout, business logic and data it provides you with (the true meaning of MVC, IMHO).

24 May 2007 15:04  
Anonymous said...

Take a look at tapestry, it will solve a lot of these problems.

31 May 2007 23:45  

Post a Comment

<< Home