Toolin' around with web applications

I'm currently on holidays. My job around the house for yesterday was to replace the hinges on the pool fence that had rusted. According to Laurie Lawrence, pool fences should be auto closing - Kids alive do the five!

Anyway I spent almost two hours on this task over two separate days trying to install the hinges. The problem was, I was trying to use the screws that came with the hinges which were clearly not designed for use with a metal gate.

My toolkit looked like this:
- Wood screws
- Cordless drill
- Drill bits
- Screwdrivers

But I still had a lot of trouble getting these darned screws to go in. So instead I tracked down an extension cord and pulled out a corded drill, thinking that the underpowered cordless drill wasn't do me any favours.

The added power of the corded drill certainly made things faster, but ultimately didn't help me succeed. I would either destroy the threads on the screws or end up drilling a hole that was too big for the screws.

Finally I got hold of some screws designed for metal, and the whole job was done properly in literally less than five minutes.

The lesson that was reinforced to me is that using a whole bunch of good tools doesn't come anywhere near the efficiency of choosing the one correct tool for the job.

I get this feeling when writing web applications too. For a basic Java Enterprise Web App, I typically choose a set of technologies like this:

- A templating language (e.g. Freemarker, Velocity)
- Javascript
- HTML
- A Javascript framework (e.g. jQuery, Prototype)
- Some sort of Widget Library (e.g. jQueryUI, Scriptaculous)
- CSS
- Spring MVC

This list is extremely abbreviated of course, as anyone involved with Java Web Development will know. The entire list of technologies is probably triple or quadruple that length.

But these are the core technologies used to display a web page. What bothers me is that the first FIVE of these end up in one file! I end up using 5 tools to accomplish the single goal of displaying the web page.

This is incredibly difficult to read and understand, especially considering that the technologies are fundamentally different. Some of the code is evaluated on the server side, and some on the client side, some before the page loads and some after the page loads, and yet the code is all mashed up together. Code generating code that generates code that generates code for multiple browsera to interpret.

Even though this approach works, it still feels like I'm trying to use woodscrews in a metal gate.

Server side templating seems like the wrong way to do things. I think we need to focus more on client side development toolkits - RESTful services and some better Javascript and Ajax Tools could completely replace our current web frameworks, but I just don't think the tools exist yet. Maybe the entire MVC model could be pushed down into javascript on the client side. Or maybe we could have some better abstractions or DSLs for browser control beyond HTML and javascript.