I Pledge My Allegiance

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

Transcript

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 application
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
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
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 use
48. The user's device might add performance constraints
49. Constraints impact the choices that you make as a web developer
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
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 workflow”
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 criteria
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 support?
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
138. We can then use these examples to see how code is structured for a particular framework
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
152. The results across the frameworks we're looking at are as follows
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 decisions
161. A special thanks goes out to to Charlie Fielding for being so patient and watching this talk 100x
162. Thank you, any questions?