Improvisational JavaScript

76f795cabbf80024b1024517c67f0bcf?s=47 Garann Means
October 07, 2012

Improvisational JavaScript

In the book Bossypants, Tina Fey gives three rules of improv: 1. Always say yes, 2. Say yes, and, 3. Make statements. These rules are a damn good approach to dealing with the unexpected in comedy or anything else. Error handling in JavaScript, for example. The way JS deals with exceptions is already a little unpredictable - instead of fighting that, let’s take advantage of it to create better user experiences, more powerful services, and room for hacks and happy accidents.

76f795cabbf80024b1024517c67f0bcf?s=128

Garann Means

October 07, 2012
Tweet

Transcript

  1. Improvisational JavaScript what Tina Fey taught me about error handling

  2. howdy Garann Means, @garannm engineer at Etsy Austin, Texas Node

    for Front-End Developers Austin All-Girl Hack Night, Girl Develop It Austin
  3. this book right here

  4. “bossypants” by Tina Fey 30 Rock, Saturday Night Live, Mean

    Girls hilarious best-seller success without infallibility
  5. fallibility e.g. Liz Lemon empathetic character a caricature of Ms.

    Fey conflict inherent in doing something without knowing if it’s the right thing == lulz!
  6. javascript infallible! fallibility comes from the developer failure to account

    for edge cases ignorance of user “works for me” mindset
  7. key difference fallibility in Tina Fey characters: hilarious relatable fallibility

    in JavaScript: not funny users/developers run away screaming
  8. comedy cope with uncertainty, even tragedy guide to dealing with

    humans adjusts expectations of how the world works computers rely on us to communicate this, using our observations
  9. rules of improv “Will Change Your Life and Reduce Belly

    Fat *” 1. AGREE 2. SAY YES, AND 3. MAKE STATEMENTS 4. THERE ARE NO MISTAKES
  10. 14,000 results for “bossypants rules of improv”

  11. business, fasting(?), feminism, scrum, life.......

  12. improv for machines machines like Yes and No all things

    must be true or false grey areas need algorithms grey areas approximated by developers instead of programming right answers, we program ways to find right answers
  13. let’s improv a user registration form!

  14. AGREE all answers are saved even incomplete gibberish even illegal

    strings nothing executed, just safely cached
  15. SAY YES, AND autocomplete context-sensitive hints reuse entered info e.g.

    mailing and billing address
  16. MAKE STATEMENTS work with what you know e.g. show a

    preview user profile highlight incomplete data separately allow continued, sandboxed progress
  17. NO MISTAKES suggest a stronger password make it a step

    to more privileges suggest a unique username show user ID until then
  18. hopefully not news ideas already exist in UI philosophy JavaScript

    can do more. dynamic typing schema-less data stores flexibility unique to our language and sphere of implementation
  19. let’s improv some $#@!@ JavaScripts

  20. improv.js your JavaScript is an improv partner a framework a

    transpiler machine learning JavaScript don’t give a
  21. AGREE JS has no method overloading i.e., JS has infinite

    method overloading! function foo can do several things use arguments to decide which
  22. agreeable functions JavaScript wants to say yes check for existence

    typeof check Object.length
  23. agreeing in the real world jQuery’s $() $( `#myThing` );

    $( document.getElementById( myThing ) ); $( this ); $( `<div id=”myThing”></div>` ); same result for all
  24. SAY YES, AND is there a callback? execute that callback

    can’t tell? go back to AGREE-ment at minimum, return chainable context object
  25. affirmative return values design functions to alter a context always

    be next()ing JavaScript would like to talk your ear off
  26. affirming the real world jQuery again people love that chainability

    put a callback on it luxury return values
  27. MAKE STATEMENTS create helpful instances include the most information reasonable

    don’t hide information once set clarify what is application state and what is object state
  28. imperative states return instances automatically set smart defaults allow access

    to the best picture of state possible from any object JS doesn’t know what it’s doing, but it’s doin it!
  29. real world imperatives the good ol’ DOM all properties exist

    add more properties easily each element has its own state browser’s DOM API unaffected
  30. NO MISTAKES try..catch should be a last resort if private

    property is accessible, it isn’t private type casting should be the norm, not an error AGREE or return this and GTFO
  31. no-error error handling can’t run foo() with input bar? check

    for type, properties errors are the result of a developer failing to realize a use case JS just wants to make you happy
  32. real world error handling try to execute an XHR timeouts

    wait, try again n times 500 error try other methods
  33. when things just fail JS has a thing for that

    error-first callbacks (or arguments) if an error callback isn’t supplied, gets swallowed developer opts in to error handling
  34. improv.js and the golden rule

  35. the golden rule code it like you have to use

    it frameworks transpilers UIs any tool you create
  36. agreeable functions function’s goal is reuse good functions are decoupled

    functions usable in multiple ways will be used more people like useful functions
  37. affirmative return values return true; === return “derp derp derp”;

    worst case? goes unused fewer modern functions are pure utilities async? return promises or subscribers functions that leave you hanging suck
  38. imperative states clear and controllable picture of app expose carefully

    chosen, useful information protect abstractions for convenience, not out of distrust “that’s a good-lookin object!”
  39. no-error error handling exceptions are useless nowhere to go from

    a dead stop multiple ways to provide opt-in error information developers know what they want, and JS wants to give it to them
  40. errors become useless once you deploy to prod encourage narrower

    definitions of acceptable instead of broader ones every error thrown costs empathy points
  41. the golden rule if your code is not a good

    improv partner, code and developer both fail code is meant to be built upon someone will use your code in a way you don’t expect
  42. JavaScript wants to be empathetic

  43. language features loosely defined function signatures ad-hoc object states, visibility

    no need to declare exceptions blurred line between users and developers
  44. the future ES6, TypeScript, Dart? you can write JS in

    any language now JavaScript creates unique opportunities JS is comedy in a world of drama deals well with uncertainty
  45. uncertainty is hard encouraging good coding practices chaining without object

    type guarantees potentially limitless state hierarchies continuing after errors in a useful state
  46. uncertainty is awesome massively decoupled code exponential potential empathetic systems

  47. JavaScript wants to be hilarious predictability is boring “legality” is

    boring forcing others to conform to your expectations is boring the way JS works is the way it works best
  48. * JavaScript will not reduce belly fat.

  49. image credits http://www.flickr.com/photos/penelopejonze/3693651284/ http://www.flickr.com/photos/derivativeofcourse/6794700318/ http://www.flickr.com/photos/35442027@N08/3447109640/in/ photostream/ http://www.flickr.com/photos/rakka/4643831214/ http://www.flickr.com/photos/rakka/3096769092/ http://www.flickr.com/photos/rakka/2536040927/ http://www.flickr.com/photos/fieldtripp/3116937266/