Yesterday our group participated in a rather special hack day at the local.ch offices. The topic was JavaScript, and all engineers that were already fairly knowledgeable in it picked a topic and presented it in 15 minutes. Additionally, they created a "mission", which was a short exercise that should be solved in pair programming and that required using the techniques that were presented.

We developers that are working with the local.ch team each did a short presentation:

• JavaScript Tools - Tricks and Tipps by Patrick Jezek
• JavaScript the right way by Joël Bez
• Functional programming in JavaScript by Michael Käser
• Modular JavaScript by Marco Bohler

At the end of the day I finished with a much shorter version of my talk about node.js from the last webtuesday. For the mission, I tried to create something that is easy, fun, and highlights the ideas behind node well.

The task was creating a small asynchronous web application where engineers can register themselves for Foosball, and then get immediately alerted when there are enough players. I provided a skeleton that already does nearly everything and only needs about 10 lines of code to be finished - but these lines require you to think a bit about asynchronous programming, events, closures and the concepts behind node.js.

If you are interested, you can download the mission for yourself here and give it a try. It includes the skeleton and a manual explaining everything. More information about it can be found on my personal blog, where I can also be contacted in case of open questions.

Today, Hannes and me were talking about html5 at the aptly named Brasserie Lipp for the Internet Briefing TechTalk series. There were quite a few people and it went pretty well (IMHO :)), maybe a little bit too long. Sorry about that and the hungry people.

The slides are available on slides.liip.ch, and if you want more information about html5's spread, there's more in this older blog post about the html5 feature comparison table by me.

Last Thursday I gave a techtalk [1] at Liip Zurich about which html 5 features are supported by what (modern) browser, incl. my personal recommendation what's worth following and what maybe not yet.
The result is this spreadsheet and these slides (but they are basically just the spreadsheet spread across many pages :))

The table needs some explanation. The first few columns (the browsers) should be clear, gears hopefully, too. The "Flash/JS Fallback" states, if there is a possible and feasible Fallback in Flash or Javascript.

The "Usable with latest?" column summarizes, if that feature is available in Firefox 3.5, Safari 4 and Internet Explorer 8 (sorry, no Opera here). This is under the assumption, that if this feature is supported by those three browsers, that it will actually have some market share in a few years (...). Anything else (basically meaning anything which is not supported by IE8 now) will have a hard time in the "shorter" term.

WIth "Useable with decent degration?" I wanted to state, if you could use that feature for people with modern browsers, but still support people without (maybe with less features). Without having to go through hoops in your code, eg. Native JSON is pretty easy to support.

The last column "Recommended in a 'controlled' environment (IMHO)" is just my humble opinion. It rates each feature, if it is worth to develop for/with, if you can somehow control (or know) your environment. This column assumes, that your audience is either using a modern browser or is able to install Google Gears. Still, to get a "green" by me, there has to be a decent fallback, even if that fallback is just to properly *not* support it (meaning that it doesn't hinder people using the interface without having the support for that feature).

As I said, the last 2-3 columns are my personal opinion (either the content or how I assembled it), which may differ from yours. So I'm really interested in getting feedback. I still hope it may be useful for you, I certainly was dearly missing such an overview and getting all the facts together was quite a task. I will also apply new findings to the table in the future

[1] Techtalks are a weekly institution at Liip, where a Liipie (or someone else) talks about something interesting for half an hour just before lunch.

You may remember the problems we had with Firefox 3.0.0 and the encoding in XMLHttpRequest back in June. The Firefox team now tried to fix it (Issue 431701 in their Bugzilla), but failed miserably, they made the problem worse (unintentially, of course :)). While it was technically correct before, now it's not even that, as it still sends ISO-8859-1 encoded content, while it claims it's UTF-8 under some circumstances. The bug reports claim, that it only happens on non-US versions of firefox, but that doesn't help us much. This new regression is tracked at #464958, is already fixed and should be in Firefox 3.0.5, which is due around mid-December. With the auto-update feature of Firefox, a lot of our users will have updated to 3.0.4 and can't really wait until mid-December, so we had to find a workaround...

As it is really a bug this time and not just a different implementation of the problem, a correct and beautiful solution can't be done, so we had to fall back to some ugly trickery. When the DOM Parser can't read the XML string due to malformed UTF-8, we check, if it could be an ISO-8859-1 string and convert that to UTF-8. If it then still doesn't work, we just tell the parser to disregard all invalid UTF-8 characters as a last resort (The patch).

I currently see no other decent way to tackle this problem. "If it's not UTF-8, even if it claims to be, assume that it could be ISO-8859-1 and try with that" seems to be an ok-ish idea here in the Western Europe Alphabet World. Anyone else should maybe really wait with the upgrade until Firefox 3.0.5 is ready.

In Firefox 3.0.0 there is a "strange" regression issue regarding the encoding of XMLHttpRequest requests. It's not a bug per se, it's just different behavior, which we ran into (and no other browser does it this way)

What we basically do on the client side in JavaScript:

this.data = new XMLHttpRequest();   
this.data.open('POST', dataURI);   
this.data.send(xml); 

where "xml" is a DOMDocument Object.

In Firefox 2.0 this request came with a

Content-Type: application/xml

and the xml in the POST body was encoded in UTF-8 (no encoding information in the XML declaration)

IE7 does:

text/xml; charset=UTF-8,

But Firefox 3.0.0 sends this as

Content-Type: application/xml; charset=ISO-8859-1

and the xml in the body is actually ISO-8859-1 encoded, but there is no encoding information in the XML declaration (eg. no <?xml encoding="ISO-8859-1"?>) and of course our XML loader fall flat on its nose, when it had non-ASCII characters in it...

While having the encoding information only in the HTTP header and not also in the XML declaration is (as far as I can remember, didn't look up any specs) correct from a technical point of view, it was pretty annoying to find this "bug". And now I have to check on the backend, how the request is encoded on that request on not just rely on "it's UTF-8 nowadays anyway or at least written in the XML declaration, so the XML parser can take care of it" (which was maybe naive from the beginning :))

Here's the code-snippet for the PHP server side:

function transformFromContentTypeToUTF8($str) {
    
    if (isset($_SERVER['CONTENT_TYPE']) && preg_match('#charset=([^/s^;]+)#',$_SERVER['CONTENT_TYPE'],$matches)) {
        if ($matches[1] == 'UTF-8') {
            return $str;
        }
        if ($matches[1] == "ISO-8859-1") {
            return utf8_encode($str);
        }
        return iconv($matches[1],"UTF-8",$str);
    } 
    //if no charset, then return as it came
    return $str;
}

function fixXMLEncodingFromHTTP($xml) {
    if (!preg_match("#<?xml[^>]+encoding=#",$xml)) {
        return transformFromContentTypeToUTF8($xml);   
}
return $xml;
}

$rawpost = fixXMLEncodingFromHTTP(file_get_contents('php://input'));    

// create a new DOM document out of the posted string
$xmlData = new DOMDocument();
$xmlData->loadXML($rawpost);

BTW, for non-ISO-8859-1 characters, FF 3 does transform them to numeric entities, welcome web 1.0 :)

And there's already a report of that issue on bugzilla, of course. But no idea, if they change that back soon

Google Maps is a powerful API for including interactive maps on your website (but who didn't know that :)). But with features comes complexity and with complexity come larger startup times (at least in JavaScript land). But there are ways to improve the user experience for your visitors. To test the possibilities, I wrote a (very) little app, which displays POI-markers for the three Liip offices.

Prerequisite: I used some YUI components to make it easier, especially for displaying some time measurements. All common components are loaded before timing started, so that is not really an issue here:

<link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/2.5.1/build/logger/assets/skins/sam/logger.css" />
<link rel="stylesheet" type="text/css" href="masync.css"/>
<script type="text/javascript" src="http://yui.yahooapis.com/2.5.1/build/yahoo-dom-event/yahoo-dom-event.js"></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.5.1/build/logger/logger-min.js"></script>

The JavaScript files should actually be at the bottom of the html, if possible, but we don't obey that rule here.

Here the 4 ways I tested, click on the title to see the implementations in action (If you have firebug enabled, turn it off, otherwise it takes ages on firefox):

1) "no lazy load top" approach - the usual way

For the first attempt, I took the "usual" way. Putting the inclusion of the google map JavaScript file into the <head> element. But when a JS file is loaded, the browser won't load anything else, until that one is finished and therefore won't for example load and display the little icon I put on the page. The important load times are:

Time until image loaded: 327ms
Time until domready fires: 316ms
Time until window.onload fires: 390ms
Time until map.load fires: 274ms

It takes pretty long, until something appears on the webpage, as loading and parsing the google javascript takes precedence.

2) "no lazy load bottom" approach - a more recommended way

Instead of putting the big google map javscript file in the head, we put it at the end of the </body> part. That improves response for the visitor a lot.

Time until image loaded: 11ms
Time until domready fires: 331ms
Time until window.onload fires: 461ms
Time until map.load fires: 290ms

While domready and onload are not sooner than in the first approach (even take longer), the image from the content part is loaded much faster and loaded almost immediately. Your user will see the whole page, just has to wait for the map a little bit longer. The effect is the more noticeable the slower your connection is, since the image loading part doesn't have to wait until the file from google is loaded.

3) "direct lazy load" approach - using the Google AJAX API

With the Google AJAX API, you can load the whole google maps code on demand. For this third approach I just did this, after the window.onload event fires. This leads to the following times:

Time until image loaded: 11ms
Time until domready fires: 41ms
Time until window.onload fires: 47ms
Time until map.load fires: 352ms

As you can imagine, the domready and window.onload events now fire much much sooner, but the total time until the map is ready takes a little bit longer. If your page relies on having domready and/or window.onload ready as soon as possible (for other components than the map), this could be a way to improve the end user experience. They don't have to wait until the map is loaded for other dynamic components to appear.

4) "on demand lazy load" approach - using Google Static Maps API

The last approach is not loading the google maps javascript by default, but only on demand. With the help of the Google Static Maps API you can even show a map, without having to execute lots of javascript code (but unfortunately only street maps currently and no satellite). As some user may nevertheless wish to zoom and pan into the map, we load the whole interactive code as soon as the user moves the mouse over the map. On a decent internet connection, this should be fast enough and not really noticeable (except that the street maps are not exactly the same :)). This gives you the responsiveness of a fast static website plus the interactivity of a google maps based site, if the user wishes so. Of course, this later-on-demand loading isn't really what you want, if the map is the central part of your site :)

Time until image loaded: 16ms
Time until domready fires: 52ms
Time until window.onload fires: 61ms
Time until map.load fires: n/a

domready et al. take a little bit longer, because the static image from google has to be loaded, which the first three approaches don't.

For everyone who missed my first Google Gears presentation back in September, there's a second chance tomorrow at January's Webtuesday at Google (approporiate place for a Gears talk :) ). It starts at 19:30, but you have to be there earlier, due to the legal stuff needed by Google (giving them your first born son and all that :) ). See the webtuesday page for more details.

Hope to see you there

My yesterday's demo for my little Google Gears application didn't work out as expected (Murphy's law :) ), so I created a little screencast to show, how it was supposed to work. It's available here (H.264, 4.2 MB, 1:29 long).