
Goodbye Prototype, hello jQuery. Spent all weekend learning it For Realz™ and sorting out the various tricks needed to make it play nicely with Rails – looking forward to doing a lot more JS from now on.

Goodbye Prototype, hello jQuery. Spent all weekend learning it For Realz™ and sorting out the various tricks needed to make it play nicely with Rails – looking forward to doing a lot more JS from now on.
That’s it! I have had enough. I have had enough of DateTime, time strings, datetime strings, Time.parse(), MySQL time, JSON time, CouchDB time, Ruby time, system time and all the rest of it.
I have come to realise that there is one, and only one, appropriate way to store time so everything can understand it without endless string conversion problems, and that is in a numeric format of milliseconds since Epoch UTC.
The only appropriate time to convert from milliseconds into a human-readable string is upon presentation to an actual human – ie, in the View. Or, if you like, store a second time field in any records you save or pass around – just make sure your program doesn’t care about those.
This revelation comes from YET ANOTHER journey into ISO document land as I realised that not only do I have no idea how to store milliseconds in a JSON date/time string, but neither does anyone else. RIGHT!! THAT IS IT! From now on, dates are an integer.
Maybe.
Anyway, here’s some notes on getting millisecond-precision time references in and out of Ruby and JS, both of whose time classes I am no fan of, more for me than anything else..
Ruby example:
# Getting milliseconds since Epoch out of Ruby: time_float = Time.now.to_f time_ms = (1000* time_float).to_i #writing >> t = Time.now.utc => Thu Nov 20 23:01:32 UTC 2008 >> time_float = t.to_f => 1227222092.50133 >> time_ms = (1000* time_float).to_i => 1227222092501 #reading >> n = Time.at(time_ms / 1000.0).utc => Thu Nov 20 23:01:32 UTC 2008 >> t => Thu Nov 20 23:01:32 UTC 2008 # check we retained usec through the process >> n.usec # note we lost microsecond precision, this is intended => 501000 >> t.usec => 501333
Reducing Ruby Time.now to millisecond precision:
time_float = Time.now.utc.to_f time_msp = ("%0.3f" % time_float).to_f
That doesn’t have much to do with time, I just thought it was cool. Note that apparently doing precision reduction with strings is faster.
Javascript
// Reading an ms-since-epoch time: js> date_from_above = new Date(1227222092501) Fri Nov 21 2008 10:01:32 GMT+1100 (EST) js> date_from_above.toUTCString() Thu, 20 Nov 2008 23:01:32 GMT // note same as above // Make a new current date js> t = new Date Fri Nov 21 2008 10:28:12 GMT+1100 (EST) // Output date object in milliseconds-since-epoch format js> t.valueOf() 1227223692041
I don’t know how the hell I didn’t know this, but you can assign multiple classes to any element in CSS. This allows some really neat tricks if you basically treat classes as stackable “tags”. Just separate the classes with a whitespace and you can add as many as you want.
To whit:
<span class="hide faq_answer"> The answer to the question! </span>
Imagine you’re writing an FAQ, and want to 1. have a certain style for the answer and 2. hide the answer unless the user clicks on the question. Before I knew this, I would have just had one class – say, faq_answer – and styled that in CSS. I then would have written something in JS which hid any instance of that class in the DOM.
That sucks because it’s conflating style and behaviour. And whenever I decided I needed to hide something else, lo and behold I have to add yet another JS rule to hide any instance of that .. before you know it you’ve got 30 JS functions hiding 30 different classes. It’s nasty, it’s fragile, it’s bad practice.
Now I know this, I’ll just write one JS handler to hide anything with the class “hide”, and I’ll style by adding a second (or third, or fourth!) class to the div. Classes can act like tags! Fantastic discovery.
I have no fucking idea how I didn’t come to know this before today.
After reading the self-congratulatory rhetoric splattered all over Yahoo User Interface group’s JavaScript Compressor page, one might think their java compressor – which you actually have to download (2.4M) and run from the fucking command line – is pretty damn good. “It’s a lot of trouble”, you’d say to yourself, “but boy .. sounds like it’s worth it!”
Nope:
-rw-r--r--@ 1 sho sho 50085 4 Jan 22:53 prototype-dean.js -rw-r--r--@ 1 sho sho 72726 4 Jan 22:50 prototype-yui.js -rw-r--r--@ 1 sho sho 124136 8 Nov 12:07 prototype_uncompressed.js
Note that prototype-dean.js, the smallest compressed version, is produced by the Dean Edwards online, web-based JS compressor specifically singled out as inferior in the YUI article.
God I hate Yahoo, and yet there’s a certainly type of developer who showers them with praise – whether it’s for their shitty CSS “grid” (WTF?), their total crap JS “User Interface” library in which every single fucking class name starts with YAHOO, or now their bullshit doesn’t-work fucking downloadable command line java vm-needing time-wasting nothing-doer. I can’t believe I wasted 20 minutes following a suspicion that some Yahoo-loving fuckwit knows anything.
I’ve put it off as long as I reasonably could, but it’s a fact of life for those developing web sites these days – at some point you’ll need to learn JS. I’ve managed to hack together a bit of JS in the past, and managed to put together a few bits and pieces of Prototype code, but I’ve never been even a little bit comfortable with it.
And I’ve always disliked Prototype and its companion Script.aculo.us, or whatever the fuck it’s called. Firstly, combined they’re over 100K (!!!!) which is INSANE. A javascript library must be as small and lightweight as possible! Secondly, I find their syntax weird, trying-to-be-ruby-but-not-quite, hard to grasp and frankly Not Worth Learning (TM). So, I needed a replacement.
Contenders are MooTools and JQuery. Initially I had thought mootools was the best option – it’s certainly got a nice website, with some very compelling demos. But as I looked into it further I lost confidence. You know the feeling – you begin to realise that this #{whatever} has been designed and built by someone who does not share your perspective on things. The demos, while beautiful, were opaque and uninstructive. The mootools framework ignores namespace and plays havoc with anything else you might wish to use. The documentation is a shambles, third party writings have a decided “in-group” feel to them, even the pictures of the developers had a nasty 37Signals-esque “kewl” look to them. Well, fuck that, and fuck that name as well.
Which leads me to jQuery, at 24KB (packed) the smallest (and fastest) of the frameworks.
I like a number of things about jQuery. Firstly, as I mentioned, it’s lean and mean. Seriously – fuck Prototype and its 100K download before you’ve even done anything!! In what kind of universe is that even remotely acceptable? People still use dial-up, you know! You’re looking at upwards of 20 seconds just to download the javascript file!
Anyway. Secondly, I like its selectors. They’re closer to the “metal” of CSS/DOM than any of the others. For example, here’s how you’d, say, hide
<span class="hide">hide me!</span>
in jquery:
$('span.hide').hide();
I like it. $ sends to jQuery. Then you have the css selection: a span, and then its class (with a dot – an ID is selected with a #, just like CSS) – all sent, nicely, to a reasonably named function. Understandable enough.