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.

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