Single Page Applications - was it a good idea?
summary
A case study shows a Spartacus storefront delivered in under six months that boosts sales but returns a Lighthouse 20 score, prompting months of fixes: server-side rendering, caching, lazy loading, critical CSS inlining, bundle compression and a final ~50 score still leaving the client unhappy. The claim is that SPAs trade initial developer velocity and snappy runtime for a hard performance ceiling, SEO and resilience costs. Alternatives discussed: React Server Components, Remix, Islands and Qwik that push rendering back to the server or load JS only on demand.
AI-written summary · about
chapters (9)
- 0:00Introduction to SPAs
- 2:51Real-world SPA project challenges
- 8:31History of web standards and SPAs
- 14:13Benefits of single page applications
- 17:24Problems with single page applications
- 21:02Are SPAs a good idea?
- 22:04Alternatives to SPAs
- 25:57Future of web development
- 27:21Closing remarks and Q&A
related talks
45mSPA, isomorphic and back to the server: our journey with JS
32mWhy you don’t need a Single Page App
33mGo Full Stack Server-Side Rendering vs SPAs
37mUsing Lit and Web Components to build Single-Page Applications
58mAlways crashing in the same car (the state of front end web development in 2022)
29mSPAs are dead. Long live Microfrontends.
11mSam Skjonsberg - SeattleJS Conference 2017
43mRethinking SPAs: web-native apps