Sunday, February 24, 2008

Why I dumped GWT

I've used GWT for over half a year now on koopjeszoeker.be. Two weeks ago I decided to stop development with GWT and go with plain HTML and mootools for the autocompleter. I've used mootools already a lot and I'm really getting the hang of it.

Why? Why did I spend all this time developing in GWT and why did I decided to stop?

First of all, GWT is a fantastic framework for doing web development. I think it's the best tool at the moment if you want to build the next GMail or an intranet application. For all those slow and lousy web interfaces (for timesheets, CMS, ...), GWT could come to the rescue. But my site is completely different.

Some of the reasons below are not really related to GWT, but more to using ajax in general. It is my opinion however, that these problems are easier to solve with 'standard' javascript libraries like mootools, prototype, dwr or scriptaculous since these have a nice way to add some ajax to certain DOM elements. For example, in GWT I had to subclass the autocompleter textbox so I could attach it to an input field that already existed in the HTML. Maybe all of this could by solved if GWT had constructors that accept a DOM id too.

SEO


I'm entering in a highly competitive segment where SEO is really important. Since most of the html is build with GWT, you end up with a pretty empty page for Google. I added some noscript tags, but this was not really helpful.

Adsense


Another problem were my adsense banners. Since I didn't have a lot of content on the page, the banners were sometimes off topic. An even bigger problem was that the banners stayed the same when people searched for different keywords (since the ajax refresh didn't trigger an adsense refresh). I solved this by doing the search with a page refresh instead of an ajax call. The ajax part of the site was limited to sorting, faceting, i18n and displaying tips.

Google Analytics


I'm also using Google Analytics. Although no real evidence exists, it would be naive to think that Google isn't using this data. But because of the ajax calls, I don't get as many pageviews as a static version of competing sites. Every visitor is seen as doing 1 page visit, while he may have browsed several pages. This makes my bounce rate in Google Analytics really high. This can't be good for my Google rankings.
In Belgium we have CIM Metriweb, a kind of archaic tracking system that is used when marketeers look for sites that have many hits. I'm not currently using this, but this thing depends on pageviews if you want the big guys to donate to your site.

What now?


I wanted a fully functional HTML version, where GWT was injected in some places to replace the full page loads with ajax calls. However, I couldn't find an easy way to do this. And once I succeeded, I found that I had almost no code left in GWT that was worth using it instead of mootools. So now, after a lot of research and experimenting, I decided that I'll go for the plain-old html way and spiced up some parts with ajax (like the "so 2007" textbox autocompleter).

I discovered the Blueprint CSS framework (version 0.7 now has semantic classes) and CSS sprites. I've used Kuler and read a lot about CSS tips and tricks. I even read a bit about usability.

And since I spend 3 hours a day on the train, I have time to redesign the site. Using blueprint, it really was easy and the result is a much better looking, stable, fast site. Check the homepage: it only has 1 css, 1 javascript, 1 gif and 1 jpeg, but there are 25 images! Ah, the magic of blueprint, sprites and jawr...


Update: please see GWT follow-up

Labels: , , ,

Monday, February 18, 2008

Compress Javascript and CSS with Jawr

Today I used the nice Jawr taglib which compresses javascript and css files. There's enough information on the Jawr website about how to configure everything, so I won't write about this.

Things to remember are:

  • Better structuring / versioning of your development javascript and css versions while still publishing them as 1 file

  • Gzip support for compliant browsers

  • Give the css and js files cache headers 'until the sun explodes'

  • When you deploy a new version of your site, a new css and js version will be downloaded by the browser

Net result: our YSlow score went from 49 to 69!

Labels: , ,

Sunday, February 17, 2008

2 Things I want in CSS 3

I've done some html/css restyling lately and there are some things I would like to see added to CSS 3. The process to request some changes to be incorporated into CSS 3 is a bit overwhelming to me, so I just post them here and hope they will be picked up by someone.

CSS variables


CSS variables would be nice. I want a way so I can easily change all colors in my CSS with one adjustment, not by searching for the color in the file and replacing it with the new value. I also think this would increase readability of the file.
This would allow to define recurring parts of the layout in the CSS file like this:

var backgroundcolor : #FFFFFF;
var border: 1px solid #CCCCCC;

.container {
background-color: $backgroundcolor;
border: $border;
}

.navbar{
border: $border;
}


Path variables


If I could rename a path selector to a variable, I could remove a lot of classes from the html and still be able to easily change the css.
Take this example:

.navbar ul li a {
text-decoration: none;
}

.navbar ul li a:hover {
text-decoration: underline;
}

This would become:

var listItem: .navbar ul li;

$listItem a {
text-decoration: none;
}

$listItem a:hover {
text-decoration: underline;
}


These examples look simple, but my experience is that a lot of the same values can be found in many CSS files. Wouldn't it be nice if we have a block of variable definitions at the top so we only have to specify once that the color of all borders should be changed?

This would also make it easier to let users (on a blog for example) override the colors with their own stylesheet, which overrides the variables with their settings.

The only way I know off to achieve this at the moment is by generating the CSS with a templating framework like JSP or Velocity (or why not PHP), but this seems like overkill to me.

So, anyone with the power to move the W3C board, go on (and let me know of the results)!

Labels: ,