Jim Newbery — How to Survive the Single-Page App-ocalypse (Turing Fest 2018)

At their best, Single Page Apps (SPAs) can rival and even exceed native mobile and desktop applications for value they provide to users. Modern browsers are incredibly capable, and open-source tools and frameworks promise to put slick web apps within reach of even the smallest teams. However, many product teams struggle to maintain and improve their single page apps. They can be slow, buggy, hard to use and resistant to change. This is bad for business. We'll explore how this happened and suggest some approaches product teams can take to shelter themselves from trouble and develop a healthy relationship with their apps.

Transcript

1. HOW TO SURVIVE THE SINGLE PAGE APP–OCALYPSE Jim Newbery
 @froots101
2. HOW TO SURVIVE THE SINGLE PAGE APP–OCALYPSE Jim Newbery
 @froots101
3. Listen to this presentation with care Do as it advises Keep it safely at hand May include anecdotal evidence @froots101
4. SINGLE PAGE APPS DAMAGE BUSINESSES* * Thank you for listening to my controversial premise Some > CAN > CERTAIN > @froots101
5. Application-like experience Dynamic in-page updates API-driven data sources Client-side routing and history Static asset bundling @froots101
6. @froots101
7. @froots101
8. CRUD* *Create, Read, Update, Destroy
9. What is the 
 value to users? @froots101
10. @froots101
11. “Fast transitions and optimistic rendering…”
12. “Long sessions, background fetching of data, interactive elements updating on the fly.”
13. “None of my code runs on the server at all so I can host it wherever…”
14. “It helps them use Twitter more on work time while they wait for the app to unf*** itself.”
15. Better user experience? Benefits @froots101 1
16. Better performance? Benefits @froots101 2
17. It’s still the web? Benefits @froots101 3
18. These benefits are 
 not guaranteed @froots101
19. CHALLENGES TO SURVIVAL @froots101
20. WARNING
 Anecdotal evidence @froots101
21. Ooh, shiny! Waste Great UX and performance Complexity ‘Traditional’ app SPA @froots101
22. How to get in a pickle @froots101
23. MISTAKE 1 Under-invest in front-end skills @froots101
24. https://twitter.com/holtbt/status/977419276251430912 @froots101
25. Tesler’s Law of the Conservation of Complexity @froots101
26. NOPE http://wallsdesk.com/nikola-tesla-65415/ @froots101
27. NOPE @froots101
28. YEP @froots101
29. “Every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it.” @froots101
30. @froots101 Fixed complexity
31. @froots101 User Front end Browser Back end Early web apps
32. @froots101 User Flash Browser Back end Flash apps
33. @froots101 2000s server-side app User Front end Browser Back end
34. @froots101 Single page app User Front end Browser Back end
35. Full-stack teams @froots101
36. MISTAKE 2 Move fast and break things add lots of tech debt @froots101
37. @froots101 Single page app (MVP) User Front end Browser Back end
38. @froots101 Bigger single page app User Front end
39. ‘Traditional’ app SPA @froots101
40. Naïve engineering practices
 +
 Collective bad habits @froots101
41. Poor test coverage Highly coupled code Over-engineering Monolithic applications Giant static asset bundles @froots101
42. Better user experience Better perceived performance It’s still the web @froots101
43. The single-page app approach is over-used @froots101
44. @froots101 Login Account
 management Dashboard Super whizzy
 feature $ $ $ $
45. MISTAKE 3 Surf the waves of framework hype @froots101
46. @froots101
47. “It’s the tools!” @froots101
48. Visibility Time Technology trigger Peak of inflated expectations Trough of disillusionment Slope of enlightenment Plateau of productivity This isn’t working @froots101
49. Visibility Time @froots101
50. “This time it’ll be different” @froots101
51. Optimising for the
 developer experience @froots101 $ $ $ $
52. @froots101 User Front end Big single page app Let’s replace all of this!
53. Frameworks don’t make apps Teams make apps very
 im portant @froots101
54. @froots101
55. Things to get right before big tech changes: Product vision Alignment on user outcomes Communication and psychological safety Skills and capabilities Development practices What the damned thing actually does @froots101
56. Learn about your product @froots101
57. Rewrite
 or
 rework? @froots101
58. Top-down Fundamental change in direction Branched development Long release delay High risk Higher reward? Rewrite @froots101
59. Bottom-up Retaining functionality Trunk development Incremental releases Lower risk Lower reward? Rework @froots101
60. A rewrite encourages forgetting @froots101
61. A rework ensures learning @froots101
62. Extract simpler apps Actual 
 tech advice @froots101
63. Actual 
 tech advice @froots101 Characterisation
 tests Extract simpler apps
64. Actual 
 tech advice @froots101 Characterisation
 tests Extract simpler apps
65. Actual 
 tech advice @froots101 Characterisation
 tests Extract simpler apps
66. Actual 
 tech advice @froots101 Characterisation
 tests Extract simpler apps
67. Eliminate waste @froots101
68. @froots101 Login Account
 management Dashboard Super whizzy
 feature
69. @froots101 Login Account
 management Dashboard Super whizzy
 feature
70. What’s the simplest way to sustainably add and maintain user value? @froots101
71. Learn together how to live with your product @froots101
72. ADVISORY
 It’s OK not to make a single page app @froots101
73. GOOD LUCK! Jim Newbery
 tinnedfruit.com
 @froots101 https://www.hdwallpaperup.com/wp-content/uploads/2015/07/Realm-Of-Fantasy-World-Digital-Art.jpg