Skip to main content

Rethinking web development, or "Will I be spending the rest of my life writing JavaScript"?

Posted by wiverson on July 11, 2005 at 5:55 PM PDT

I remember when I first started doing Java development, and the first time I saw a servlet in action - I thought it was awfully cool that the HTTP protocols were so seamlessly wrapped up. Wow.

A lot of folks noticed that writing HTML by hand in servlets was pretty nasty, and so the idea of "flipping the code" was born. Instead of writing nasty HTML in Java code, we would write nasty bits of Java in our now even nastier HTML.

This more or less worked pretty well for a long time. I had to teach a lot of newbie web designers how to find generated Java source files and figure out how line numbers mapped to the originating JSP files. Tools like Dreamweaver MX were helpful for wrangling the HTML, and this model seems to be the inspiration behind Java Studio Creator.

But... and this is a big but... all of this has gotten a bit out of hand, and it's well on the way toward turning into an absolute nightmare with Ajax. The underlying theory here is that there is a "web designer" who does a bit of futzing with JavaScript, and there is a server-side developer that does the "hard stuff."

Let's conduct a little experiment. Go to and view the source. Now, let's check out the Ajax examples for J2EE from the Blueprints group. There is a lot of JavaScript code there, stuff that needs to work on multiple browsers, on multiple platforms. Portability across browser platforms is still a bit of nightmare.

How do you think they test Google Maps?

Is the newbie web designer supposed to be the guy writing and/or tweaking all of this complexity? All of the JavaScript? All of the custom JSP and JSF tags in the monstrous XHTML file?

The answer, I think, is to stop viewing web applications as "tweakable" lumps of DHTML or XHTML, the same way that we don't really view class files as "tweakable" lumps of bytes to be edited by hand. If I handed you a class file and told you that you could "tweak it" if you had any problems, only the very, very, very geeky among you would think that was a good idea.

Instead, think of a web application as an application like any other, but it happens to render (under the scenes) to DHTML & JavaScript, instead of a native graphics toolkit. For the vast majority of applications, it's a much, much more efficient model for building an application (it also happens to be much easier to debug). For a very interesting example of this, check out the programming model underlying Echo.

That's all for now, but I do want to follow up with one last thing - we are looking to hire good Java developers here at work. If you live in the Seattle, WA area (on the Eastside, for those of you keeping track), and are interested in working in an agile environment with a really, really great team of Java developers on a long term basis, please drop me a line at wiverson AT gmail DOT com. We're doing a mix of web applications, web services, Swing... all sorts of interesting things.

Related Topics >>