New Rules For JavaScript

Video Coverage: http://www.youtube.com/watch?v=S4cvuuq3OKY

I bet you've been writing JS for years and you think you're pretty good at it. I bet you think you know all about how functions create closured scope, and how `this` gets bound, and even how `.prototype` works. Or, rather, you probably don't care because your framework or library takes care of all that for you.

JavaScript is generally considered one of the most misunderstood (and maligned) languages of the modern programming era. And there's good reason for that, because most developers who write JS never actually deeply *know* how the language works. They blame all their WTFs on language bugs, instead of the shortcomings in understanding.

This talk re-visits some of the "tough parts" of the language by declaring "New Rules" (Bill Maher style) for the language. For instance: "new rule: stop using `this` until you really understand how it gets assigned"

This talk is hard-core on coding and expects a solid understanding of the language.

Transcript

1. for javascript kyle simpson @getify http://getify.me
2. linters jslint, jshint, eslint
3. might hurt your feelings
4. new rule: JS has types. Quit pretending otherwise.
5. JS has 7* types right now: null undefined boolean string number object function
7. values have types, and those types can’t change, but variables can hold any value at any time
8. new rule: Start using == and implicit coercion
10. == checks value === checks value and type == allows coercion === disallows coercion
11. “When comparing any of the following values, always use the === or !== operators, which do not do type coercion: 0 “” undefined null false true If you want the type coercion, then use the short form...” — “The Good Parts”
14. http://RestrictMode.org
15. == and implicit coercion can be helpful IF you learn & know what you’re doing
16. also: stop treating null and undefined differently
19. if you treat null and undefined the same, you’re rewarded with simpler comparisons
20. new rule: Stop defining anonymous functions
25. named function(-expression)s are always preferable
26. also: stop bloating your function closures
29. don’t just assume the JS engine optimizes away your mistakes
30. new rule: stop abusing your function’s scope
34. block scoping is better than manually hoisting variables
35. this won’t work until ES6!? this won’t even work in ES6! this can work right now in ES3!
36. https://github.com/getify/let-er
37. --es6
38. start also using block scoping “let is not the new var”
39. also: loops <3 block scope
45. let + loops ftw
46. new rule: stop using this until you really understand how it gets assigned
49. 1 2 3 4
50. 4 steps to this 1. is the call-site new-invoked? use that 2. is the call-site binding overridden with call/apply? use that 3. is the call-site on an owned-object? use that 4. otherwise, use global (except strict mode)
51. this is only magical or confusing when you don’t look at the call-site
52. also, var self = this is often just misguided
55. much type so hate ugly -doge
56. aka: var self = this
58. don’t try to be so clever and mix-n-match this-style with closure-style code pick one or the other. use it.
59. new rule: Stop using new Something() "constructors" to "instantiate" and "inherit" "classes"
61. prototypal inheritance Apples vs. Oranges: that’s not an apple, it’s just a red orange.
62. OO vs. OLOO class-oriented vs. delegation-oriented objects linked to other objects
63. Foo Bar a1 a2 b1 b2 class-oriented
67. it doesn’t have to be so hard
68. Foo.prototype Bar.prototype a1 a2 b1 b2 delegation-oriented
74. quit trying to mimic more complicated “classes” and “inheritance” and just embrace OLOO delegation
75. no hurt feelings, right?
76. kyle simpson @getify http://getify.me thx!