I'm not sure where to direct the thunderhead of frustration I've built up today: at web development in general, or at Internet Explorer in particular.
I am not a web developer — as I have spent the last ten hours proving — and more importantly
the Here API is not a web application. It is, however, a tool which I hope will be extremely useful to web application developers, which is why a Javascript library to access the service was one of our highest priorities and which is why I've wasted the entire day trying to get a demo app up and running.
Or, rather, up and running on Windows. Resources here are a little limited and today was my first chance to spend serious time on the (singular) PC. But not to worry, because the demo app's been doing its thing on both Safari and Firefox under OS X for a couple of weeks now, so there shouldn't be much work that needs doing.
Of course I was wrong. For a start, in Firefox it looked utter arse, buttons and textareas which had been carefully — and tediously — manoeuvred into position via CSS vanishing off the screen. But at least it displayed in Firefox. It took a good half hour of fiddling to get IE to show anything at all. This was partly my fault, having missed the "Microsoft doesn't believe Javascript need
consts" warning in the Mozila docs. Mostly, I blame the Javascript "debugger" in IE, because 1) its error messages call everything a syntax error (boy, I swear I haven't met them since the days of Spectrum BASIC), and 2) when it gives a line number you have to a) guess which included file the error occurred in, and then b) subtract the number of lines down the original HTML page the
<script> tag came from the line number in the error to work out where it was.
And of course when something was displayed it i) didn't work, and ii) looked like total arse.
"Bugger this for a game of soldiers!" thought I, and off I went looking for a nice cross-platform framework to do the hard stuff for me. The demo app as it stands uses
Prototype and
Scriptaculous (the Javascript client libraries at its heart — remember, this is why I'm doing this — has no dependencies), but what I needed was something to do widgets.
Being the Apple drone I am,
Sproutcore was my first port of call. I'd only ever heard it discussed on
MacBreak Weekly, but it had drawn favourable comparisons to the Second Coming so I thought it might be worth a look. And it certainly looked promising, right up to the point where the demo borked under IE. Back to Google. (I don't need to link Google, right?)
The rest of my day was spent dismissing Javascript GUI frameworks.
Qooxdoo (which they tell me is pronounced "[`ku:ksdu:]" — no, honestly, they think that that's helping),
MooTools, the
Yahoo! User Interface library ... none of them had that certain get-this-done-today something that I was looking for. (And what the hell is with this needing an external tool chain to build your Javascript library?) I almost went with
Dojo — I'd played with it in the past, mainly for testing our JSON-RPC servers — but then it hit me that whichever of these I chose my app would end up looking like a Swing e-mail client. My current "design" — you can actually see the air-quotes when you look at it — may look like total arse, but at least it has a little character.
So it's back to my original code. I'm going to have to wait till my go on the PC comes around again and sweat through the code the old-fashioned way. The problem of getting a design to look the same cross-browser must have been solved a thousand times before — so why can't I find a simple solution? (It's at times like these I really wish this blog got some readers so I could get a few suggestions ... oh, well.)