Created
June 4, 2011 19:28
-
-
Save stephancom/1008248 to your computer and use it in GitHub Desktop.
unobtrusive rollover coffeescript vs original
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
// purpose of script is to handle rollovers unobtrusively, e.g. | |
// <img src='original.png' data-rollover='rolled.png'> | |
$(function(){ | |
$('img[data-rollover]').live('mouseover', function(){ | |
if($(this).data('rollover-original') == null) { | |
$(this).data('rollover-original', $(this).attr('src')) | |
} | |
$(this).attr('src', $(this).data('rollover')) | |
}).live('mouseout', function(){ | |
$(this).attr('src', $(this).data('rollover-original')) | |
}) | |
}) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# coffeescript version | |
# eh, it's not that much nicer. Maybe if I could replace '$(this)' with something like '$@' ? | |
# but then it starts looking like perl :( | |
$ -> | |
$('img[data-rollover]').live 'mouseover', -> | |
$(this).data 'rollover-original', $(this).attr('src') unless $(this).data('rollover-original')? | |
$(this).attr 'src', $(this).data('rollover') | |
.live 'mouseout', -> $(this).attr 'src', $(this).data('rollover-original') |
And thus why I'm not impressed.
Most of my Javascript code is jQuery - I so rarely use, say, regular arrays,
or for loops, or even 'var'. I suppose if I was doing something with insane
amounts of logic on the front end - or if I start playing with node.js - it
might be useful.
The other thing of it is that while I hate extra brackets and like using
indents - as in haml and sass - Javascript is sort of Lisp in sheep's
clothing. I finally understood my Lisp classes once I understood
Javascript... so I don't mind the brackets as much, I guess I figure they're
no worse, and maybe a little better than ))))))))))))))) like at the end of
a long Lisp expression.
Past that, I've had enough trouble with people balking at haml because
'designers know html.' I had one client convert all my haml back to erb
after I finished a project. Grrr. I'm not sure if I'd ever trust a
'designer' to play with my templates too much anyway... but I can see a case
where I might want to have someone else working on js and can see it being
an issue.
Coffeescript is nice, don't get me wrong, it's a heroic effort, and I thank
you very much for your attention! You've done a really nice job! :) :) but
I think I'll stick with mostly plain old js/jquery, and maybe use
Coffeescript if I need to do something fancy. Thank heavens for Sprockets
making that easy finally.
Keep up the good work, and thanks again!
…On Sat, Jun 4, 2011 at 1:35 PM, TrevorBurnham < ***@***.***>wrote:
Yeah, jQuery code tends to benefit only minimally from being converted to
CoffeeScript. I'd actually add a little more punctuation than you used,
e.g.:
$ ->
$('img[data-rollover]')
.live('mouseover', ->
$this = $(this)
unless $this.data('rollover-original')?
$this.data 'rollover-original', $this.attr('src')
$this.attr 'src', $this.data('rollover')
).live('mouseout', ->
$this = $(this)
$this.attr 'src', $this.data('rollover-original')
)
(The `$this = $(this)` is pretty standard; there's a bit of overhead every
time you use the `$` function, plus the parentheses hurt readability.)
Relying less on implicit parentheses makes it easier to extend the code in
the future.
Also, be carefuly about implicit returns. It's not an issue in this case
(`$this.attr()` will just return `$this`), but if you were to accidentally
return `false` from an event handler, that would stop the event from
propagating, and possibly have other unintended consequences. So you may
want to explicitly add `return` at the end of each callback as a matter of
habit.
Hey, if you'd rather type function() { }
instead of ->
, be my guest. :)
I think where CoffeeScript really shines is in large applications, where classes provide a very neat way of organizing your code (even if you're not totally into classical OO). I hope you'll keep that in mind in your front-end coding endeavors.
On Sat, Jun 4, 2011 at 4:52 PM, TrevorBurnham < ***@***.***>wrote:
Hey, if you'd rather type `function() { }` instead of `->`, be my guest. :)
Actually in Textmate I just have to do f-tab, so it's actually less
keystrokes. In fact, I had actually forgotten about this shortcut and had
been typing it manually until I saw your comment and I was like "oh, right,
there's a shortcut for that!"
I agree in principle though, and yes -> looks nicer, and yes it's more
expressive.
I think where CoffeeScript really shines is in large applications, where
classes provide a very neat way of organizing your code (even if you're not
totally into classical OO). I hope you'll keep that in mind in your
front-end coding endeavors.
Sure, and I have to say, I don't do a lot of real object oriented JS, I
don't generally make my own, umm, what do they call them? prototypes or
something? I don't really do my own libraries, and I really ought to, and I
see where this might make those a lot cleaner.
It is worth noting that I am now a coffeescript convert - today I would no sooner use plain JS instead of coffeescript than I would use html or erb instead of haml or slim.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Yeah, jQuery code tends to benefit only minimally from being converted to CoffeeScript. I'd actually add a little more punctuation than you used, e.g.:
(The
$this = $(this)
is pretty standard; there's a bit of overhead every time you use the$
function, plus the parentheses hurt readability.) Relying less on implicit parentheses makes it easier to extend the code in the future.Also, be carefuly about implicit returns. It's not an issue in this case (
$this.attr()
will just return$this
), but if you were to accidentally returnfalse
from an event handler, that would stop the event from propagating, and possibly have other unintended consequences. So you may want to explicitly addreturn
at the end of each callback as a matter of habit.