Tuesday, April 06, 2010

blog.repurpose() again + Js rant

It's not like I got tired of blogging about breaking things. I've written before about the Heisenberg effect -- am I deliberately breaking things just to write about them? I don't think it's really that either. And coincidentally I've not really broken anything recently either -- well apart from putting a kitchen knife through my limited edition boxed copy of Tara Busch's Pilfershire Lane when I couldn't get its jiffy bag open. If there was any collector's value in that, there isn't any any more.

I think the main deal is that as a programmer and mobile human I see so many things that are broken every day, and I don't see why I shouldn't write about them just because I didn't do the breaking. So the new title is "It Was Broken When I Got Here", with due respect to the Crucible fire experts' motto of "It Was On Fire When We Got Here, Honest".

First up for the treatment, though by no means the first, last, or only, is the "new" HTML 5 Web Database API. Now in general I think HTML 5 is great smashing super. canvas is proving to be a real graphics workhorse, geo can't hurt, and video will hopefully mean a web video standard finally (Apple, please get out of the way, thanks). Together they will spell the death of Flash, and really how could that be a bad thing?

Unfortunately however someone left the design of the web database package in the hands of someone who has never seen a database API before and thinks that one should write one's Javascript application onion-style, as a series of concentric closures. I presume they did this in an attempt to make code as unreadable and unportable as possible in order to prove how smart they are. Not to mention how stupid it is to implement classes in Js so why would we bother? Hey dickhead, take a look at John Resig's Class.js.

The problem is that the entire API is asynchronous. You heard me right, a *database* API is asynchronous. How long does "create table" take? Or even the most complex retarded SQL query? An hour? No, more like a few milliseconds. In other words, much shorter than your average Ajax call. Because, you see, Captain Closure, database calls are *local*, *CPU bound*, and in general the application needs the data it got back in order to proceed. So making the whole thing asynchronous kinda indicates that you thought you were writing something networky or I/O bound, and someone bolted on some database shit at the last minute.

Yes, yes, shut up, I know there is a synchronous API too. Be nice if anyone implemented it. Safari and Chrome don't. Largely because it came along quite recently. This should be setting alarm bells off in any *real* programmer's head by now. Wait, they didn't implement the async API on top of the sync one? Or rather expose the sync API so if you *really* wanted to do your database sync, you could roll your own? Nope. That kind of stupid traditional talk doesn't make any sense in Js, also known as AnyExcuseNotToImplementRealLanguageFeaturesScript.

No problem, says the real programmer, we've been building sync APIs on top of async APIs for ages. Just reset your flag, spin and yield waiting for the flag to get set by the async task. Easy. Well apart from one thing. Js really isn't a real environment, as despite kinda having thread, it has no yield().

Because, once again, dear readers, the authors of Js and the HTML 5 web database API didn't bother thinking about it, they just started writing code. This is agile development, we don't need design! We can just iterate! Never mind that 8 million developers around the globe will adhere to a crap standard and will create 8 million hacky workarounds for a problem which would have taken 5 minutes to prevent had someone - anyone - not taken a bong hit before ratifying the standard! Who cares? We make money from incompatibility! This is the web! Code should be free! It's open source, everything is fine!

tl;dr -- the HTML 5 web database API is a pile of shit designed by someone who had no clue what they were doing.

No comments: