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

I Pledge My Allegiance

I Pledge My Allegiance

Lets talk about how we make decisions over which framework to use, considering how our internal biases effect our decision

Jonathan Fielding

November 18, 2016
Tweet

More Decks by Jonathan Fielding

Other Decks in Programming

Transcript

  1. I Pledge My Allegiance
    Jonathan Fielding @jonthanfielding

    View full-size slide

  2. A bit about me…
    • Technical Architect at Beamly
    • Author of ‘Beginning Responsive Design’
    • Regular contributor to open source,
    including SimpleStateManager, Echo.js,
    CriticalJS, FT’s Polyfill Service, Doccy
    among many projects

    View full-size slide

  3. Often as developers we
    find ourselves making
    lots of decisions

    View full-size slide

  4. These decisions can have
    a huge impact on our
    project

    View full-size slide

  5. It can make a huge
    difference to our user
    experience

    View full-size slide

  6. and have a major impact
    on the ergonomics of
    developing our
    application

    View full-size slide

  7. The problem is most of
    the information out
    there is laced with bias

    View full-size slide

  8. We often see developers
    saying X is better than Y

    View full-size slide

  9. Pledging their allegiance to
    their framework of choice

    View full-size slide

  10. and I myself am guilty of this

    View full-size slide

  11. So today I want to look at
    how we make these
    decisions

    View full-size slide

  12. and encourage you to
    have confidence in the
    decisions that you make

    View full-size slide

  13. Why do developers
    choose to use
    frameworks?

    View full-size slide

  14. 5 years ago many would
    have defaulted to jQuery

    View full-size slide

  15. It had a huge ecosystem
    around it that made it the
    default choice

    View full-size slide

  16. jQuery helped
    tremendously to move
    the web forward

    View full-size slide

  17. These days however,
    jQuery is bloated and it
    often leads to code that
    quickly becomes
    unmaintainable

    View full-size slide

  18. Instead of libraries like
    jQuery, developers
    instead often choose to
    use frameworks

    View full-size slide

  19. The reason that
    developers choose
    frameworks is they
    provide a solution to
    some key problems

    View full-size slide

  20. First, they offer well
    defined application
    architectures

    View full-size slide

  21. Secondly, they offer a
    community of support
    when building your
    application

    View full-size slide

  22. Thirdly, they offer pre-
    built components you
    can use off the shelf

    View full-size slide

  23. These three things make
    developers happy

    View full-size slide

  24. They can be the
    difference between a
    project feeling like a
    mountain

    View full-size slide

  25. Or a molehill

    View full-size slide

  26. and they can give us the
    kickstart at the beginning
    of a project

    View full-size slide

  27. What makes
    choosing a
    framework difficult?

    View full-size slide

  28. There is a huge amount
    of choice

    View full-size slide

  29. Each framework tries to
    solve a set of problems
    that web developers face

    View full-size slide

  30. It's therefore important
    to choose the framework
    that is right for your
    project

    View full-size slide

  31. There is an
    overwhelming amount of
    information to wade
    through

    View full-size slide

  32. and with so much choice
    we need to be pragmatic
    in making our decision

    View full-size slide

  33. especially since it is
    difficult to separate fact
    from opinion

    View full-size slide

  34. Learning to be
    pragmatic

    View full-size slide

  35. Let's start with a
    definition of what
    pragmatic means

    View full-size slide

  36. To a developer this
    means to make choices
    that fit within the
    constraints of our project

    View full-size slide

  37. What are the
    constraints?

    View full-size slide

  38. We need to understand
    limits to what we can
    quickly pick up

    View full-size slide

  39. and we need to
    understand what outside
    knowledge is available to
    us

    View full-size slide

  40. We are likely constrained
    by a deadline

    View full-size slide

  41. The user's browser
    might constrain the
    features that we might
    use

    View full-size slide

  42. The user's device might
    add performance
    constraints

    View full-size slide

  43. Constraints impact the
    choices that you make as
    a web developer

    View full-size slide

  44. and when being
    pragmatic you need to
    make a decision that sits
    within these constraints

    View full-size slide

  45. How biases influence
    how pragmatic we
    can be

    View full-size slide

  46. Successful developers are
    those who are able to
    evaluate all potential
    options and choose the one
    that is best for the situation

    View full-size slide

  47. However, good
    developers often fall
    victim to bad decisions

    View full-size slide

  48. Biases are unconscious:
    unless we are actively
    avoiding them then they
    can affect our decision
    making

    View full-size slide

  49. We therefore need to
    acknowledge our biases

    View full-size slide

  50. Confirmation Bias

    View full-size slide

  51. This can manifest itself in
    both how we search for
    information and how we
    interpret it

    View full-size slide

  52. To overcome
    confirmation bias you
    need to seek ways to
    challenge what you think
    you see

    View full-size slide

  53. Anchoring Bias

    View full-size slide

  54. https://www.towergateinsurance.co.uk/liability-insurance/cognitive-biases

    View full-size slide

  55. During normal decision
    making, we tend to weigh
    a specific piece of
    information more heavily
    than other factors.

    View full-size slide

  56. To overcome anchoring
    bias you need to look
    more into the other
    frameworks

    View full-size slide

  57. The Availability Heuristic

    View full-size slide

  58. https://www.towergateinsurance.co.uk/liability-insurance/cognitive-biases

    View full-size slide

  59. If a JavaScript framework is
    featured regularly on a subreddit
    we regularly visit, when it comes
    to making a decision we're more
    likely to recall information on it
    which will bias our decision

    View full-size slide

  60. To avoid this bias you
    need to ensure you are
    looking across a bunch of
    frameworks

    View full-size slide

  61. External Biases

    View full-size slide

  62. We also often encounter
    other people's biases
    when carrying out our
    research

    View full-size slide

  63. In order to separate fact
    from opinion we need to
    know what signs to look
    for

    View full-size slide

  64. Watch for buzzwords

    View full-size slide

  65. Look at how the writer
    talks about other
    frameworks

    View full-size slide

  66. See if you could rewrite
    the article, using the
    same information, to tell
    a completely different
    story

    View full-size slide

  67. “49% of developers
    agree that React
    improves their workflow”

    View full-size slide

  68. “51% of developers
    agree that React does
    not improve their
    workflow”

    View full-size slide

  69. Making a pragmatic
    choice

    View full-size slide

  70. Clarify your
    project
    Evaluate your
    options
    Assess the risks
    Make the
    decision
    Evaluate your
    success
    Implement

    View full-size slide

  71. Clarify your project

    View full-size slide

  72. What are the objectives
    of the project?

    View full-size slide

  73. What devices are being
    used to access your
    project?

    View full-size slide

  74. What are the needs of
    the end users?

    View full-size slide

  75. Who will be working on
    the project?

    View full-size slide

  76. How much time do you
    have to complete the
    project?

    View full-size slide

  77. Evaluate your options

    View full-size slide

  78. Earlier we looked at the
    different kind of biases
    that can impact your
    project

    View full-size slide

  79. When evaluating
    frameworks we want to
    avoid being impacted by
    these biases

    View full-size slide

  80. The way to prevent bias
    is to identify your
    evaluation criteria

    View full-size slide

  81. Our criteria should first
    address the areas we
    already clarified about
    our project

    View full-size slide

  82. Does this framework
    allow us to meet its
    objectives?

    View full-size slide

  83. Will this framework work
    on the devices I have to
    support?

    View full-size slide

  84. Does this framework
    support the needs of my
    users?

    View full-size slide

  85. How long will it take to
    implement using this
    framework?

    View full-size slide

  86. We should then extend
    our criteria to cover
    other areas that we care
    about

    View full-size slide

  87. Does it work around any
    bugs in the web
    platform?

    View full-size slide

  88. This will save you time as
    you won’t have to work
    around bugs yourself

    View full-size slide

  89. What is the impact on
    performance of using
    this framework?

    View full-size slide

  90. From an end user
    perspective,
    performance is
    incredibly important

    View full-size slide

  91. Amazon found every
    100ms delay in loading a
    page cost them 1% in sales

    View full-size slide

  92. Google found an extra 500ms
    delay loading search results
    decreased traffic by 20%

    View full-size slide

  93. Walmart saw for every 1 second
    decrease in page load they had a
    2% increase in conversions

    View full-size slide

  94. There are 3 big areas
    that frameworks can
    effect performance

    View full-size slide

  95. File size performance

    View full-size slide

  96. Framework initialisation
    performance

    View full-size slide

  97. Repaint performance

    View full-size slide

  98. Having identified
    evaluation criteria you
    should then use these to
    evaluate each of the
    frameworks

    View full-size slide

  99. React AngularJS Backbone Vue.js Polymer
    Suitable for
    projects
    objectives
    yes yes no yes yes
    Support required
    devices
    yes yes yes yes yes
    Does it support
    rapidly updating
    my interface?
    yes (with redux) yes unknown unknown yes (with redux)
    How long will it
    take to
    implement
    2 weeks 1.5 weeks 3 weeks 1.5 weeks 1.5 weeks
    Own criteria goes here

    View full-size slide

  100. Assess the risks

    View full-size slide

  101. Is the technology familiar
    to you?

    View full-size slide

  102. When choosing a
    framework you are
    making a commitment

    View full-size slide

  103. You are committing to
    learn a new thing

    View full-size slide

  104. And you are committing
    to using the thing going
    forward

    View full-size slide

  105. Are there many other
    developers using this
    technology?

    View full-size slide

  106. Hacker News Hiring Trends
    http://www.ryan-williams.net/hacker-news-hiring-trends/2016/october.html?compare1=AngularJS&compare2=Backbone&compare3=Ember&compare4=React

    View full-size slide

  107. Will it be maintained?

    View full-size slide

  108. If the framework is open
    source, you are relying
    on the developers to
    continue to maintain it

    View full-size slide

  109. How easy will it be to
    maintain this project
    over the long term?

    View full-size slide

  110. Make the decision

    View full-size slide

  111. Rule out the riskiest
    options

    View full-size slide

  112. Apply weightings to your
    evaluation criteria

    View full-size slide

  113. React AngularJS Backbone Vue.js Polymer Weighting
    Suitable for
    projects objectives
    yes yes no yes yes 30
    Support required
    devices
    yes yes yes yes yes 20
    Does it support
    rapidly updating my
    interface?
    yes (with redux) yes unknown unknown
    yes (with
    redux)
    10
    How long will it
    take to implement
    2 weeks 1.5 weeks 3 weeks 1.5 weeks 1.5 weeks 10
    Own criteria goes here

    View full-size slide

  114. Discuss with other
    developers in your team

    View full-size slide

  115. Agree on what you want
    to use

    View full-size slide

  116. Build your project using
    your chosen technology

    View full-size slide

  117. Make a note of any
    problems you face which
    you can then reflect on
    later

    View full-size slide

  118. Evaluate the success

    View full-size slide

  119. Look at what went well

    View full-size slide

  120. Identify areas that you
    are unhappy with

    View full-size slide

  121. Highlight any technical
    debt accrued

    View full-size slide

  122. Looking at popular
    frameworks

    View full-size slide

  123. To compare frameworks
    we can build the same
    application in each one

    View full-size slide

  124. Doing this ourselves is
    time consuming

    View full-size slide

  125. and we might not even
    end up with solutions
    that suit the framework

    View full-size slide

  126. This is where
    todomvc.com comes in

    View full-size slide

  127. We can then use these
    examples to see how
    code is structured for a
    particular framework

    View full-size slide

  128. We can also do some
    benchmarking using the
    chrome devtools

    View full-size slide

  129. Firstly let's capture how
    much JavaScript each
    framework uses

    View full-size slide

  130. 329KB 82.7KB 343KB 183KB 119KB 170KB

    View full-size slide

  131. Next we want to look at
    how long it takes the
    framework to load the
    application

    View full-size slide

  132. The results across the
    frameworks we're
    looking at are as follows

    View full-size slide

  133. 5990ms 1700ms 5400ms NA 1930ms 2790ms

    View full-size slide

  134. By spending time looking
    at frameworks we can
    find out for ourselves the
    facts about a framework.

    View full-size slide

  135. Avoid pledging your
    allegiance to a single
    framework

    View full-size slide

  136. Make decisions based on
    the type of project

    View full-size slide

  137. Consider your users'
    expectations

    View full-size slide

  138. Alongside the
    ergonomics you want
    from a framework

    View full-size slide

  139. I hope you go away
    feeling confident in
    making these decisions

    View full-size slide

  140. A special thanks goes out
    to to Charlie Fielding for
    being so patient and
    watching this talk 100x

    View full-size slide

  141. Thank you, any questions?

    View full-size slide