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

More Decks by Jonathan Fielding

Other Decks in Programming


  1. I Pledge My Allegiance Jonathan Fielding @jonthanfielding

  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
  3. Often as developers we find ourselves making lots of decisions

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

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

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

    our application
  7. The problem is most of the information out there is

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

  9. Pledging their allegiance to their framework of choice

  10. and I myself am guilty of this

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

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

    you make
  13. Why do developers choose to use frameworks?

  14. 5 years ago many would have defaulted to jQuery

  15. It had a huge ecosystem around it that made it

    the default choice
  16. jQuery helped tremendously to move the web forward

  17. These days however, jQuery is bloated and it often leads

    to code that quickly becomes unmaintainable
  18. Instead of libraries like jQuery, developers instead often choose to

    use frameworks
  19. The reason that developers choose frameworks is they provide a

    solution to some key problems
  20. First, they offer well defined application architectures

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

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

    the shelf
  23. These three things make developers happy

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

    a mountain
  25. Or a molehill

  26. and they can give us the kickstart at the beginning

    of a project
  27. What makes choosing a framework difficult?

  28. There is a huge amount of choice

  29. None
  30. None
  31. Each framework tries to solve a set of problems that

    web developers face
  32. It's therefore important to choose the framework that is right

    for your project
  33. There is an overwhelming amount of information to wade through

  34. and with so much choice we need to be pragmatic

    in making our decision
  35. especially since it is difficult to separate fact from opinion

  36. Learning to be pragmatic

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

  38. None
  39. To a developer this means to make choices that fit

    within the constraints of our project
  40. What are the constraints?

  41. Knowledge

  42. We need to understand limits to what we can quickly

    pick up
  43. and we need to understand what outside knowledge is available

    to us
  44. Time

  45. We are likely constrained by a deadline

  46. Technology

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

  48. The user's device might add performance constraints

  49. Constraints impact the choices that you make as a web

  50. and when being pragmatic you need to make a decision

    that sits within these constraints
  51. How biases influence how pragmatic we can be

  52. Successful developers are those who are able to evaluate all

    potential options and choose the one that is best for the situation
  53. However, good developers often fall victim to bad decisions

  54. Biases are unconscious: unless we are actively avoiding them then

    they can affect our decision making
  55. We therefore need to acknowledge our biases

  56. Confirmation Bias

  57. None
  58. This can manifest itself in both how we search for

    information and how we interpret it
  59. To overcome confirmation bias you need to seek ways to

    challenge what you think you see
  60. Anchoring Bias

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

  62. During normal decision making, we tend to weigh a specific

    piece of information more heavily than other factors.
  63. To overcome anchoring bias you need to look more into

    the other frameworks
  64. The Availability Heuristic

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

  66. 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
  67. To avoid this bias you need to ensure you are

    looking across a bunch of frameworks
  68. External Biases

  69. We also often encounter other people's biases when carrying out

    our research
  70. In order to separate fact from opinion we need to

    know what signs to look for
  71. Watch for buzzwords

  72. Look at how the writer talks about other frameworks

  73. See if you could rewrite the article, using the same

    information, to tell a completely different story
  74. “49% of developers agree that React improves their workflow”

  75. “51% of developers agree that React does not improve their

  76. Making a pragmatic choice

  77. Clarify your project Evaluate your options Assess the risks Make

    the decision Evaluate your success Implement
  78. Clarify your project

  79. What are the objectives of the project?

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

  81. What are the needs of the end users?

  82. Who will be working on the project?

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

  84. Evaluate your options

  85. Earlier we looked at the different kind of biases that

    can impact your project
  86. When evaluating frameworks we want to avoid being impacted by

    these biases
  87. The way to prevent bias is to identify your evaluation

  88. Our criteria should first address the areas we already clarified

    about our project
  89. Does this framework allow us to meet its objectives?

  90. Will this framework work on the devices I have to

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

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

  93. We should then extend our criteria to cover other areas

    that we care about
  94. Does it work around any bugs in the web platform?

  95. This will save you time as you won’t have to

    work around bugs yourself
  96. What is the impact on performance of using this framework?

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

  98. Amazon found every 100ms delay in loading a page cost

    them 1% in sales
  99. Google found an extra 500ms delay loading search results decreased

    traffic by 20%
  100. Walmart saw for every 1 second decrease in page load

    they had a 2% increase in conversions
  101. There are 3 big areas that frameworks can effect performance

  102. File size performance

  103. Framework initialisation performance

  104. Repaint performance

  105. Having identified evaluation criteria you should then use these to

    evaluate each of the frameworks
  106. 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
  107. Assess the risks

  108. Is the technology familiar to you?

  109. When choosing a framework you are making a commitment

  110. You are committing to learn a new thing

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

  112. Are there many other developers using this technology?

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

  114. Will it be maintained?

  115. If the framework is open source, you are relying on

    the developers to continue to maintain it
  116. How easy will it be to maintain this project over

    the long term?
  117. Make the decision

  118. Rule out the riskiest options

  119. Apply weightings to your evaluation criteria

  120. 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
  121. Discuss with other developers in your team

  122. Agree on what you want to use

  123. Implement

  124. Build your project using your chosen technology

  125. Make a note of any problems you face which you

    can then reflect on later
  126. Evaluate the success

  127. Look at what went well

  128. Identify areas that you are unhappy with

  129. Highlight any technical debt accrued

  130. Looking at popular frameworks

  131. To compare frameworks we can build the same application in

    each one
  132. Doing this ourselves is time consuming

  133. and we might not even end up with solutions that

    suit the framework
  134. This is where todomvc.com comes in

  135. None
  136. None
  137. None
  138. We can then use these examples to see how code

    is structured for a particular framework
  139. None
  140. None
  141. We can also do some benchmarking using the chrome devtools

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

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

  144. Next we want to look at how long it takes

    the framework to load the application
  145. None
  146. None
  147. None
  148. None
  149. None
  150. None
  151. None
  152. The results across the frameworks we're looking at are as

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

  154. By spending time looking at frameworks we can find out

    for ourselves the facts about a framework.
  155. Summary

  156. Avoid pledging your allegiance to a single framework

  157. Make decisions based on the type of project

  158. Consider your users' expectations

  159. Alongside the ergonomics you want from a framework

  160. I hope you go away feeling confident in making these

  161. A special thanks goes out to to Charlie Fielding for

    being so patient and watching this talk 100x
  162. Thank you, any questions?