Bikes and Code

It seems that everyone who writes about programming topics in a blog format eventually writes an article on what books they feel are important to read to improve professionally. This shouldn’t be surprising really. Generally speaking if someone is going through the trouble of actually writing an article on a topic, it’s probably safe to say that they enjoy reading about the topic. Write what you know, etc.

The difficulty is that there are only so many programming books that are truly classics. While I appreciate and enjoy learning from well written Hibernate or book on the Google Web Toolkit, ultimately, any software book that starts to discuss a specific framework will quickly become obsolete. As one of my personal definitions of classic is a book that does not grow old with time, this means that a huge percentage of mass market “Learn how to gidazzle with widget fooxily” types of books will never reach the classic status.

Unfortunately, it seems that the dominant type of programming book that is on the shelf in your local bookstore are exactly the ones that will be out of date in a couple of years. This makes me somewhat sad as if the market is for books that quickly go obsolete, the number of people that will write books that go on to be classics will be smaller simply on a basis of supply and demand. I’m not sure where this leaves us. I like buying technology of the month books as well, so I help this. All in all, it’s likely not a problem I suppose. I guess I just wish I could actually find Peopleware or the Mythical Man Month in print on a shelf somewhere.

So now I reach the real crux of the matter. If you are reading this, then you probably read other blogs by various guys in the software industry and they already have pretty much written about the books that you absolutely should read. More, most of you have probably read some of the books that Joel or Jeff have suggested in the past. So I’d simply be duplicating content listing the exact same classic books and suggesting that a serious programmer should read them.

So this has all been a debate as to whether or not to do that. You see, I actually enjoy reading reading lists, especially if there is a little blurb about why the book is good. Every once in a while a wholly new book turns up and I will add it to my ‘to read’ list and I am the wiser for it. Still, I think I can stand up to it and avoid actually creating a reading list of some form.

That about wraps it up for today, this was more of a random ramble than anything else. Back to actual geek topics soon enough.

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.

Once upon a time, the world wide web was invented. I’m not really going to talk about that. Later, something called the Hypertext Markup Language (HTML) was developed. It let you share nicely laid out documents over the web. And it was Awesome.

HTML had some limitations though, it was kind of verbose and you had to mix up your content, paragraphs and such, with code that was used to show how the thing should be laid out and look. At more or less the same time, there were two new pushes to make HTML better. Javascript (1995) was developed to allow a web site designer to make things change on a page. No longer would a web page be a simple static document like a magazine or newspaper article. Cascading Style Sheets (CSS – 1995-1996ish) was created to help a web designer keep the content, the article, online store, etc. distinct and in a different place from the stuff that was responsible for how that content actually looked on the page.

And this was Awesome, except, it wasn’t. At the time that these developments were happening, the First Browser War was underway. Netscape put some Javascript and CSS stuff into their browser. Microsoft put different things into theirs. Bit players in the browser wars did other things. The end result was that if you wanted to make a sufficiently sophisticated web page, you had to create two or three versions of the thing so that it actually worked in multiple browsers. Now, for a long while, this did not actually matter as Internet Explorer 6 held so much market share that you could target IE6 only and get away with it.

That is no longer the case. Arguably, it was never the case, but there were lots of so called ‘web developers’ who happily wrote sites that worked in IE6 and IE6 alone. There are several major browsers now. More importantly, there are several major devices now. Blackberries, cell phones and game consoles all have limited support for browsing the web in various forms. It’s probably a good idea to try to write your web code in such a way it works in as many platforms as possible. More specifically, at least the major platforms that your clients are using.

Approaches

Inevitably, however, some of the fancy dynamic content, crazy layouts or Javascript dancing puppies will not work on some platform that at least some of your customers are using. There are a couple of different strategies for dealing with this scenario: Progressive Enhancement and Graceful Degradation. Effectively, the end result of either of these strategies is the same thing. A website that functions properly under just about every browser platform. There is overlap between the two strategies, in that you can safely say a website built via a progressive enhancement strategy will degrade gracefully. That said, there is definitely a difference in the development process when building a web application in either of these manners.

Having worked on projects that focused on graceful degradation, I can offer my opinion that it is a route fraught with problems. My gut feeling is that if you are going this route, you’re almost better off writing off customers who don’t have your minimum supported browser.

Progressive Enhancement and HIJAX

I’m mostly going to talk about progressive enhancement now as my current project has gone that route. I mainly went that way as I was concerned with the smell of the code that I had written or worked on in the past that went the other way around. Taking a full featured, beautiful Web 2.0 application and trying to hack in static HTML support was difficult and led to some fragile functionality in places. Progressive enhancement seemed to solve that problem in that you started with a functional, solid HTML version and then began to add the flashy enhancements.

Google for HIJAX and read some of the blog posts you find, all are pretty short and give you an overview of the approach I am making with this particular application. There isn’t really a definitive definition of HIJAX, suffice it to say, the point of the thing is what I outlined above. Normal, old fashioned site first, then start writing the flash. The basic philosophy is “Plan for AJAX from the start. Implement AJAX at the end.”

Of course, there is no silver bullet.

While I truly do like the development process that follows with HIJAX, I cannot help but feel I have traded one type of code smell with another. Well, in this case, it isn’t really code smell, it’s more of a project management smell. The single biggest problem I have with the simple HIJAX philosophy is how simply it discounts the nature of web applications.

Implement AJAX at the end.

This is where it all falls apart. Anyone who has built web application that goes beyond the trivial knows that there is no end. Paul Graham talks about the advantages to web development in The Other Road Ahead. He has an entire section dedicated to releases and notes that in a web application, you really don’t have releases. You have features that you deploy one or two at a time.

So if there is no end, implementing AJAX at the end isn’t really possible. So the HIJAX philosophy migrates more into a “Plan for AJAX from the start. Implement AJAX in chunks as you go along.” This is notably still different from “Implement AJAX from the start”, but must be pointed out. The majority of articles and essays on this topic that I have read thus far do not take a high level perspective. They deal with specific implementation issues and provide an outline that works at the feature level. The naive philosophy will not work when applied to an entire project.

This is not to say that it is a lost cause and we should get back to writing rich applications that only work in specific versions of Firefox. Progressive enhancement is the way to go for a general purpose application on the Internet where you do not want to drive away any customers. HIJAX, on the other hand, is a nice buzzword for a simplified philosophy that I think will die out quickly as it becomes apparant that it is just a bit too simple.