hangovers and javascript, together at last

1. hangover.js
@alunny
Friday, June 17, 2011
hey guys. I’m andrew lunny and this talk is called hangover.js
i apologize to Jonathan Julian - hopefully he’s in the crowd here and can accept my contrition
- but I didn’t come up with the title. he had one last year, but the content doesn’t overlap

2. me
• chief n00b @ nitobi, vancouver bc
• phonegap and stuff
• build.phonegap.com
Friday, June 17, 2011
i work at nitobi up in vancouver bc. i have a humorous job title to compensate for my meagre
salary. we have a project called phonegap for building native mobile applications using web
technologies. i work on a web service called phonegap build that does that in the cloud. but I
don’t wanna talk about any of that

3. • shitty code is a social problem, not a
technical one
• heuristics, not solutions
too long; don’t listen
Friday, June 17, 2011
this is not gonna be a technical talk; it’s too early in the morning. this is gonna be a hand-
wavey bullshit methodology thing, with a lot of clip art. it’s about why we have so much shitty
javascript code
i encourage everyone who wants an espresso or something to go line up for that now, rather
than listen to me

4. If there’s something you don’t like
Friday, June 17, 2011
if that sounds dumb, you should probably stop listening to me
this was almost halfway funny at jsconf. not a whole lot

5. a hangover
Friday, June 17, 2011
anyway, hangovers

6. Friday, June 17, 2011
there’s a really great book called Everyday Drinking, by Kingsley Amis. it’s a lot of good
writing about some important topics. and it does cover hangovers
one nice point mr amis makes is to distinguish between a physical hangover - so, having a
headache, or a full body ache - and a meta physical hangover. so what’s a metaphysical
hangover?

7. An ineffable compound of
depression, sadness anxiety,
self-hatred, sense of failure and
fear for the future.
Friday, June 17, 2011
this is what he says about a metaphysical hangover: [read quote]

8. huh
Friday, June 17, 2011
now why would I mention this

9. oh yeah, JavaScript
Friday, June 17, 2011
well we are at a javascript conference. do we write some javascript that gives us a
metaphysical hangover? or am I stretching this metaphor a bit too far, especially at this hour?
if i have one point today, it’s that JS is a self-loathing language. I’ll try to make a case for
that, and we’ll see how that goes over the next fifteen minutes

10. Friday, June 17, 2011
so you guys all know ryan dahl, i assume, and he had this enigmatic tweet on the first night
of jsconf. who knows what he really meant, i think he meant jsconf is like a prom for
javascript developers. and ryan’s really smart, so I’m gonna assume that that’s insightful. we
should probably take another moment to consider this tweet.
[pause]
has everyone had ample time to consider that?

11. #jsconf is fun
Friday, June 17, 2011
there are lots of great things about jsconf, but i think the best is that you get a vacation from
your application code
you see all these cool open source projects and frameworks, and how much it would be to
hack on them. you hear about new browser APIs and all the cools stuff that can be done with
them
and the thing that’s great about all this is you see the new sexy stuff in lightweight, hello
world demos, which are always super attractive, because they’re empty codebases

12. new codebases
Friday, June 17, 2011
new codebases are like robert smith, the lead singer of The Cure, during the 1980s. They’re
slick, they’re stylish, and they’re exciting. They make you want to keep writing code.
and that’s the feeling I’ve always gotten from attending jsconf

13. work sucks
Friday, June 17, 2011
Unfortunately, when you return from jsconf, you get the same applications you’ve been
working on for months. and there are TODOs and FIXMEs and whatever else covering over the
crufty parts
you don’t really have the time or the inclination to fix it, and there’s other shit you’ve gotta
get done, so you just ignore all of the problems - the broken windows, in the pragmatic
programmer terminology - for the time being, at least, in favour of immediate concerns
incidentally, this may be the dumbest and the most inane slide in the history of jsconf. i
realize this is a bold claim, but i have 3 different pieces of clipart in there, including one
microsoft word licensed photograph, and the slide’s title is “work sucks”
what this boils down to is that, you know, at work, we deal with old codebases

14. old codebases
Friday, June 17, 2011
this is because old codebases are like robert smith, lead singer of The Cure, in this century:
flabby, dishevelled, unmaintainable and frankly embarassing. and nobody in their right mind
would want to be seen anywhere near them
(I do still like The Cure, even if they have gotten a bit older)

15. • depression
• sadness
• anxiety
• self-hatred
• sense of failure
• fear for the future
Friday, June 17, 2011
so we this is the javascript hangover, with concomitant symptoms [list symptoms]
this makes us unhappy, as you can tell from the sad man in the picture

16. examples
Friday, June 17, 2011
I’m talking in a lot of generalities-- it would help to see some actual bad code
in particular, I want to show you guys the code I hate the most of a project I regularly work
on, and that I’ve been too lazy to fix

17. function GetFunctionName(fn) {
if (typeof fn === "function") {
var name= fn.name;"
" if (!name) {
var m = fn.toString().match(/^s*function
s+([^s(]+)/);
name= m && m[1];"
" }
" if (name && (window[name] === fn)) {
" " return name;
" } else {
" " return anomToNameFunk(fn);
" }
}else {
" return null;
}
}
Friday, June 17, 2011
this comes from the bowels of the phonegap-iphone repository, and annoys everyone to no
end
so this function takes a function as an argument, and returns the name of the function.
sounds great right?
no, it’s horrible
firstly, it does a lot of unnecessary checks. if it’s a function declaration (it says function foo,
not var foo = function), name property will be set on the function. otherwise, anything
involving the local variable name will be spurious and unhelpful
if it manages to resolve that function name, it resolves the name that it finds. otherwise it
calls a new function, that must be good
i’ve highlighted this anonToNameFunk, with a k, function, so let’s look at it

18. var _anomFunkMap = {};
var _anomFunkMapNextId = 0;
function anomToNameFunk(fun) {
" var funkId = "f" + _anomFunkMapNextId++;
" var funk = function() {
" " fun.apply(this,arguments);
" " _anomFunkMap[funkId] = null;
" " delete _anomFunkMap[funkId];"
" }
" _anomFunkMap[funkId] = funk;
" return "_anomFunkMap." + funkId;
}
Friday, June 17, 2011
so this function anomFunkMap takes an anonymous function, creates a unique identifier for
it, creates a new more-or-less bound function for the anonymous function that then deletes
the reference to itself in the anonymous functions...
i know, i know
... then assigns the newly bound function to the function map and returns NOT the identifier
of the anonymous function in the map of anonymous functions, but the string to evaluate to
find the reference to the particular anonymous function within the map of anonymous
functions
this is horrible

19. Friday, June 17, 2011
that was horrible. here’s a picture of a man literally surfing the web.

20. good cop bad cop
Friday, June 17, 2011
rather than talking about that, let’s go on another tangent. I think JavaScript is a good cop
bad cop language.
the language itself - in terms of the semantic and syntactical features - give a wide degree of
freedom and expressiveness to developers.
but the community, for many entirely valid reasons, restricts the freedoms the language gives
to the developers. either backwards compatibility, memory usage, or just the size of the code
restricts what is recommended for client-side JavaScript code
actually, in the JS community, this good cop bad cop thing is easily personified

21. good cop bad cop
Friday, June 17, 2011
we have good cop brendan, who tells us about these cool new language features we can
adopt to improve the expressiveness and beauty of our code
then we have bad cop crockford, who tells us our code is shit and we should stop trying to be
so clever. also, we should be worried about security

22. No solutions
Only heuristics
Friday, June 17, 2011
I touched on this earlier, but there’s not a single solution to badly formed JavaScript code.
There’s not a one-time that you can pay off. There are only patterns, or heuristics, that we
can follow every time we write code, and hope that we succeeed.

23. How to lose weight
without diet or exercise
Friday, June 17, 2011
It reminds of an old joke - how do you lose weight without changing your diet, or taking on
any exercise

24. How to lose weight
without diet or exercise
Friday, June 17, 2011
and the correct answer is disease
you can follow the better practices, or you can do things the hard way

25. How can I avoid bad
code?
Friday, June 17, 2011
so this is an obvious question, and the answers are well known
this image is copyright shutterstock, incidentally

26. How can I avoid bad
code?
• write tests
• write docs
• don’t write long functions
• keep execution stacks small
• don’t be a doosh
Friday, June 17, 2011
The best recommendations are obvious ones: write unit tests, document your assumptions,
avoid long functions or big execution stacks, and don’t code like an asshole. Those are easy
to suggest, but hard to follow.

27. heuristics require discipline and dedication
there’s no shortcut
Friday, June 17, 2011
these lessons are well known among most developers, but social problems make it difficult to
enforce the best practices
if there’s one thing you take away from this talk, it’s that those practices are best practices
for a reason. and they certainly pay off the initial effort.

28. cheers & bye
Friday, June 17, 2011
so that’s me done. thanks everyone