Upgrade to Pro — share decks privately, control downloads, hide ads and more …

New Rules For JavaScript

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.


Kyle Simpson

October 04, 2013

More Decks by Kyle Simpson

Other Decks in Programming


  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
  6. None
  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

  9. None
  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”
  12. None
  13. None
  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

  17. None
  18. None
  19. if you treat null and undefined the same, you’re rewarded

    with simpler comparisons
  20. new rule: Stop defining anonymous functions

  21. None
  22. None
  23. None
  24. None
  25. named function(-expression)s are always preferable

  26. also: stop bloating your function closures

  27. None
  28. None
  29. don’t just assume the JS engine optimizes away your mistakes

  30. new rule: stop abusing your function’s scope

  31. None
  32. None
  33. None
  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

  39. also: loops <3 block scope

  40. None
  41. None
  42. None
  43. None
  44. None
  45. let + loops ftw

  46. new rule: stop using this until you really understand how

    it gets assigned
  47. None
  48. None
  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

  53. None
  54. None
  55. much type so hate ugly -doge

  56. aka: var self = this

  57. None
  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"
  60. None
  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

  63. Foo Bar a1 a2 b1 b2 class-oriented

  64. None
  65. None
  66. None
  67. it doesn’t have to be so hard

  68. Foo.prototype Bar.prototype a1 a2 b1 b2 delegation-oriented

  69. None
  70. None
  71. None
  72. None
  73. None
  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!