h1ghlevelb1ts

I have had the questionable fortune to code a bit of web using Java technologies the last months. Not my choice of tech obviously but nevertheless interesting. Much has happened in the Java space since the days of Struts - I remember doing stuff on an early beta back in 2001. It was much better than coding servlets directly. We have gone a long way since then and these days Java or the microsoft techs are not the obvious choice anymore. People are being much more productive with Ruby, Python, Groovy, Scala and even Smalltalk these days. A much better world for us developers!

Anyway - this new phase started with a bit of Vaadin. It is built using the same technology as in GWT but more backendish. You code in Java and markup, scripts and styling just appear magically in your browser. It works fine as long as you stick to the box. I was lucky to work with Magnus Axelqvist - also a proponent of test driving and we really tried hard to do black boxing of our app using Fitnesse (as well as the fair amount of “normal” unit tests). And now dark clouds started to appear. Everything in Vaadin becomes embedded in a multitude of div elements and only some of them get an appropriate css id. What is worse though is that it is hard if not impossible to set the id yourself. The default implementation of common form widgets keeps state somewhere in the javascript engine and not visible from the outside making it impossible to get the value of a drop. We had to use a “native” implementation to get around it. A positive on the other hand is that it is very easy to write unit tests for the Java code. Although it doesn’t test the Java->HTML transformation it gives you enough security when TDDing your application. Vaadin is probably a good choice when your developer group is skilled in Java but not in web but a lot of flexibility is given away to the framework. I would not consider it for end user apps but it may work well for in house administrative stuff where functionality is more important than looks.

After the Vaadin experience it was nice to get introduced to Wicket - a framework with a kind of templates (actually plain HTML files spiced up with wicket:id attributes) and most of the coding still done in Java. A bit of Ajax generated in the background but still possible to hook in your own javascripts when necessary. Although it is painful to write web applications in Java, Wicket is an option where you still have lots of control over your markup.

This trip made me realize that the core of the web is in the markup. HTML, Javascript and CSS is what matters in the browser. Please try to learn it instead of hiding behind a framework that takes away your markup ownership. If you are to build smashing applications for the web you need to control your markup.

Photos by flickr users f-l-e-x and wonderlane.