The GWT and simplification

Web development can be a bit of a beast, at least from the perspective of a programmer who is aware of the limits of his brain.

Back in the good old days, you could build entire desktop applications with one programming language, C++ or whatever that may have been. Whether the code you were working on was for the presentation layer or deep in the business logic, you were dealing with the same syntax, the same debugger and the same paradigms. The advent of large web applications completely destroyed that.

Depending on the language and framework you are using, any reasonable web application typically requires detailed knowledge of no less than four languages. HTML for your content, CSS for presentation, Javascript for any dynamic effects and some other language that you are using to do your server side processing. Technically speaking, two of these are not programming languages (HTML and CSS) as they offer no control structures, but they are still a syntax that you must keep in mind when working with them.

The problem with this is that no matter how good you are at programming, there is some mental overhead associated with the requirement to switch syntaxes in your head as you move from working on one aspect of the project to another. Generally speaking, most languages have their own distinct set of advantages and selecting the correct language for a given project is an important. That said, the more languages a programmer needs to use to work with a given project, the less likely they are to be an expert in all of them. This is an important enough point to note that it is corporate policy at Google to work with one of something like four languages. (Steve Yegge talks a bit about this here)

So I'm going to postulate that keeping the number of distinct languages that are needed to keep a given production application working and maintained to a minimum is an important consideration. If your project is using the aforementioned three web presentation languages, then a mixture of PHP, Java and Perl on the server side, you have dropped a large brick wall in front of any developers new to the system and added additional mental overhead to working on the project even for your top developers.

The grass is greener...

Which brings me to the Google Web Toolkit (GWT). I have used this in a few projects now and am fairly comfortable with the framework. I can safely say that I know it very well from an applications development perspective. When I first started using it, it was like magic. I got to write and debug Java code, which I was very familiar with, but when I was done, I could compile the project and run it in a browser with the same functionality.

The more I used it, the more I began to feel that I was actually more productive with it than by writing straight HTML/CSS/Javascript and tying that to a servlet or JSP based back end. I will emphasize that this was a 'feel' more than any sort of hard numbers, but more on that when I get to the criticism part of this post.

I've rambled before on some of the problems that I have with Java and was looking around to try out a new web application framework. I settled on Ruby on Rails to build Gifti.ca and I do really enjoy working with this framework. It has often been said that there is nothing like moving to a new language to show you deficiencies in the one you usually use, but the opposite is true as well. You see, with Rails, I was back to how I originally worked with web applications, four or five languages. This was when I had my 'ahah!' moment about the GWT and what it was that I really enjoyed about it.

Java, simpler?

In this case, yes, with the GWT, you need to work with two languages, Java and CSS. You can build an entire web application with the GWT and the resulting HTML that you actually put into the page is absolutely minimal. For all intents and purposes, you link to the Javacript file that the GWT generated for you and the entire application merrily builds itself in the web browser. For the most part, the major browsers work fairly interchangeably as well. The generated code is quite fast, better than humans can generate according to the Google propaganda and I have no reason to doubt them.

You do need to keep a handle on the CSS, but even then, a number of the classes have methods which allow you to programatically set various alignment parameters and the like so those can be taken out of the CSS as well. The AJAX functionality they have baked into the framework plugs into a servlet container so beautifully I'd be hard pressed to come up with a simple reason not to use Java on the server side with a GWT front end.

Eliminating two of the languages that you need to keep in mind when working on a project is a huge benefit mentally speaking. Fewer major context switches when going from layout to client side logic to styling meant that I found it easier to stay in the zone. This is why I need to make intelligent arguments with myself when starting up a new project as to why I'm not immediately firing up Eclipse and coding up a GWT project.

But...

I have some concerns about the framework. I feel more productive when I am using it, but I know that I spend longer building the user interface than I would have with a plain old fashioned web application. On the other hand, the UIs I tend to build with the GWT are more sophisticated. It is a balancing act. While I never bothered to keep any statistics, I would be surprised if the GWT was any more productive than anything other web application framework.

There is one very serious problem with the GWT and I have no real idea how to address it at this point, which is why my latest project isn't using it. The GWT makes it easy, very easy to build your entire application with it. If you deploy a website built entirely with the GWT, search engines will not be able to index you. At least, not yet. All of your content will be buried in the compiled Javascript which in turn means that unless the search robot is running a full Javascript engine, you are out of luck.

Worse, if you want to support a version of the site that actually works without Javascript, you are left with writing another front end for the application entirely from scratch. My experience has been that this is painful.

Which also really means that before you jump into using the GWT for a given project, it pays to know your audience. For a general purpose web application that is to be used by a large and diverse group, the GWT is probably not the best choice. This is double so if the web application is geared more towards searchable content such as a blog. If you are building an intranet application or know for a fact that the clients that you are interested in will be running a full featured browser, then the GWT is an excellent technology to choose to go with. It's probably also going to work rather well in an environment where web searchable content isn't terribly important, a mashup with Google Maps or something along those lines.

Anyhow, long and the short of it is that I will continue to use the GWT for projects for the foreseeable future, it's just too powerful for me to ignore. Being able to effectively ignore HTML and Javascript for a certain class of application is highly appealing to me.