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
const
s" 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.)
3 comments:
Hi Stuart,
totally understand your frustration with developing cross-browser web apps.
Now that you know how to pronounce qooxdoo, that was probably the hardest part ;-). No seriously, using qooxdoo may not be a no-brainer and single-day job (as with most comprehensive frameworks), but it pays off quickly by letting you concentrate on your app and not being puzzled by any cross-browser quirks or tedious deployment tasks. You don't need to know any HTML, DOM or CSS - particularly the latter becoming a nightmare easily for complex UIs. It's all OO JavaScript.
Of course, qooxdoo is currently still focusing on building RIAs, so for more traditional web pages it may not be one of the favorite solutions today. But with the next versions 0.8+ it's starting to cover the low-level end of web dev as well.
So, if you're rather not interested in pimping up existing web pages, but in creating a widget-based, maybe desktop-like web app, it might be worth a second look (please note, following links are development snapshots of 0.8 alpha):
Demo 1
Demo 2
All demos
Some user apps
BTW, GMX.com is a large-scale qooxdoo app. Try it yourself! ;-)
Hi, Andreas. Thanks for the comment.
qooxdoo is actually one of those projects which made me wish I had a use for it as I was reading through the docs. Unfortunately it couldn't fix the problem I had yesterday - you're right that it wasn't really designed for adding to existing pages, and what I really needed was a little more learning - but I hope to come back and take another look at it when I get the time.
Oh, and in case anyone else is thinking of starting with qooxdoo but is put off by thought of having to install Fink, I think that gettext comes pre-installed on 10.5. (At least it's on my 10.5 machine, and I can't remember ever having installed it.)
Hi Stuart, just a remark regarding platforms and gettext (used for i18n): qooxdoo's gonna get rid of those dependencies. :-)
Starting with the upcoming releases 0.8 and after the platform-independent tool chain will be completely Python based. So for instance no need for Cygwin, etc. under Windows or gettext tools any longer. Just a simple Python installation (if not on the OS already) and people are ready to go...
Post a Comment