$30 off During Our Annual Pro Sale. View Details »

You should use <insert library / framework here>, it's the bestestest!

Paul Lewis
November 06, 2015

You should use <insert library / framework here>, it's the bestestest!

A talk I gave at FFConf 2015 in Brighton, talking about the benefits and costs (to developers and users) of frameworks.

Paul Lewis

November 06, 2015
Tweet

More Decks by Paul Lewis

Other Decks in Technology

Transcript

  1. “YOU SHOULD USE
    IT’S THE BESTESTEST!”
    ,
    (worst talk name ever.)

    View Slide

  2. “I'm thinking based on your last post, there's a great
    talk in there, but rather than throw you to the mob with
    "Your framework sucks", I was thinking a talk entitled
    (something like) "Data Driven Decisions”
    would be awesome.
    Remy Sharp, email, Jul 2015

    View Slide

  3. OK, LET’S GET
    data!

    View Slide

  4. POP QUIZ
    number one

    View Slide

  5. “…your last post…”

    View Slide

  6. View Slide

  7. “…the bottleneck is almost
    always the DOM mutation
    and not JS execution.
    React docs

    View Slide

  8. View Slide

  9. 2 timers started
    Time in Framework
    Timer 1 finished Timer 2 finished
    “DOM Manipulation”

    View Slide

  10. View Slide

  11. View Slide

  12. LET’S PLAY GUESS THE
    element count!

    View Slide

  13. URL Element count
    2015.ffconf.org 388
    twitter.com/rem 4,501
    play.google.com/music/listen#/now 3,231
    github.com/torvalds/linux/graphs/contributors 5,050
    facebook.com 2,936
    html.spec.whatwg.org 143,998

    View Slide

  14. “If you torture your data
    long enough, they will
    confess to anything.
    Ronald Coase… Probably.

    View Slide

  15. DATA POINT:
    react-ions.
    (thanks, I know. I know.)

    View Slide

  16. “I don't see you mentioning
    shouldComponentUpdate
    at all.
    Twitter responder number one

    View Slide

  17. Every framework has
    best practices that I need
    to learn & follow.
    MY ANALYSIS:

    View Slide

  18. “An f1 car is fast but you can[’t]
    do your weekly shop in it
    Twitter responder number two

    View Slide

  19. I find writing vanilla HTML, JS
    & CSS is too difficult.
    MY ANALYSIS:

    View Slide

  20. Perf is a red herring.
    Twitter responder number three

    View Slide


  21. MY ANALYSIS:

    View Slide

  22. “React isn't popular because
    it's fast. It's popular because
    it's fun.
    Twitter responder number four
    (my emphasis added)

    View Slide

  23. MY ANALYSIS:
    Having fun when writing code
    is more important to me than
    other factors.

    View Slide

  24. ERGONOMICS VERSUS
    user needs.

    View Slide

  25. ERGONOMICS USER NEEDS
    • Fun to use.
    • Quick to build.
    • Works around bugs.
    • Gets me paid, yo.
    • Loads quickly.
    • Has smooth interactions.
    • Doesn’t slow down my phone.
    • Doesn’t crash.
    • Has features I want.

    View Slide


  26. React + Performance = ?, aerotwist.com
    It seems to me that
    developer ergonomics
    should be less important
    than our users’ needs.

    View Slide

  27. POP QUIZ
    number two.

    View Slide

  28. ERGONOMICS USER NEEDS
    • Fun to use.
    • Quick to build.
    • Works around bugs.
    • Gets me paid, yo.
    • Loads quickly.
    • Has smooth interactions.
    • Doesn’t slow down my phone.
    • Doesn’t crash.
    • Has features I want.

    View Slide

  29. ALL CODE HAS
    a cost.

    View Slide

  30. DEV COSTS
    • Learning it.

    View Slide

  31. View Slide

  32. DEV COSTS
    • Learning it.
    • Re-learning it.

    View Slide

  33. POP QUIZ
    number three.

    View Slide

  34. DEV COSTS USER COSTS
    • Learning it.
    • Re-learning it.
    • Debugging it.
    • Time.
    • Bandwidth.
    • CPU usage (battery).
    • Frame rate.
    • Memory usage.

    View Slide

  35. LIBRARIES VS.
    frameworks.

    View Slide

  36. Jake Archibald, arguing on Twitter (probably).

    View Slide

  37. OK, LET’S GET
    more data!

    View Slide

  38. View Slide

  39. • Time.
    • Bandwidth.
    • CPU usage (battery).
    DEV COSTS USER COSTS
    • Learning it.
    • Re-learning it.
    • Debugging it.
    • Frame rate.
    • Memory usage.

    View Slide

  40. Model data
    requested
    Model data
    arrives
    JS requested
    JS arrives
    Page
    interactive
    Evaluation, load & execution
    BOOTSTRAPPING / “TIME-TO-INTERACTIVE”
    Load

    View Slide

  41. View Slide

  42. HERE’S AN
    alternative.

    View Slide

  43. BIG RIG

    View Slide

  44. DEMO
    With TodoMVC!

    View Slide

  45. Responses

    View Slide

  46. Animations

    View Slide

  47. Page Load

    View Slide

  48. Page Load

    View Slide

  49. npm install -g bigrig
    github.com/GoogleChrome/big-rig
    github.com/GoogleChrome/node-big-rig

    View Slide

  50. BACK TO THOSE
    frameworks.

    View Slide

  51. Model data
    requested
    Model data
    arrives
    JS requested
    JS arrives
    Page
    interactive
    Evaluation, load & execution
    Load
    BOOTSTRAPPING / “TIME-TO-INTERACTIVE”

    View Slide

  52. AND HERE ARE
    the results.

    View Slide

  53. Framework Size Bootstrap time N51,3 Bootstrap time iPhone 5S2,3
    Polymer v1.1.4 41KB5 409ms 233ms
    AngularJS v1.4.3 324KB 518ms 307ms
    React v0.13.3 311KB 1,201ms 1,463ms
    React v0.13.3 [JSX transformed via Babel]4 162KB 509ms 282ms
    Backbone v1.2.2 [inc. jQuery & Underscore] 139KB 248ms 168ms
    Ember v1.10.0-beta.3 580KB 1,992ms 1,440ms
    Vanilla 16KB 50ms 33ms
    1. Tests done on a Nexus 5 running Chrome 47.
    2. Tests done on an iPhone 5S running Safari 9.
    3. All bootstrapping time includes handling initial todo list data.
    4. JS Transformer stripped; JSX files transformed via Babel.
    5. Excludes Web Components Polyfill (38KB)

    View Slide

  54. POSSIBLE OBJECTIONS
    • TodoMVC isn’t idiomatic.
    • TodoMVC isn’t my use-case.

    View Slide

  55. View Slide

  56. POSSIBLE OBJECTIONS
    • TodoMVC isn’t idiomatic.
    • TodoMVC isn’t my use-case.
    • A Nexus 5 / iPhone 5S isn’t what our users use.
    • It’ll be better in the next version of [insert framework here].

    View Slide

  57. SO SHOULD YOU USE
    a framework?

    View Slide


  58. PPK, The true JavaScripter, FOWA Oct 2015
    Uses libraries & frameworks
    when needed…

    View Slide

  59. FRAMEWORKS ARE AN
    inversion of control

    View Slide


  60. PPK, The true JavaScripter, FOWA Oct 2015
    But studies them in detail
    before doing so…

    View Slide

  61. COSTS
    • Time.
    • Bandwidth.
    • CPU usage.
    • Frame rate.
    ERGONOMICS
    • Fun to use.
    • Quick to build.
    • Works around bugs.
    • Gets me paid, yo.
    • Memory usage.
    • Learning it.
    • Re-learning it.
    • Debugging it.

    View Slide

  62. USE THE DATA AS A
    decision informer.

    View Slide


  63. PPK, The true JavaScripter, FOWA Oct 2015
    And prefers to use a single
    one per project…

    View Slide


  64. PPK, The true JavaScripter, FOWA Oct 2015
    … which provides the technical
    background to change a library
    or framework if necessary.

    View Slide

  65. SO SHOULD YOU USE
    a framework?

    View Slide

  66. ERGONOMICS USER NEEDS
    IMPORTANCE

    View Slide

  67. ERGONOMICS USER NEEDS
    IMPORTANCE

    View Slide

  68. ALWAYS FOCUS ON
    the people bit.

    View Slide

  69. Thanks!
    say hi: @aerotwist

    View Slide