It’s Time for Modern CSS to Kill the SPA  🔗 **Source:** [It’s Time for Modern CSS to Kill the SPA](https://www.jonoalderson.com/conjecture/its-time-for-modern-css-to-kill-the-spa/) > [!note]+ Document Notes > tags: [#CSS, #SPA, #WebDevelopment] > - #CSS > - #SPA > - #Performance > Author: Jono Alderson > Source: jonoalderson.com > Reference: https://www.jonoalderson.com/conjecture/its-time-for-modern-css-to-kill-the-spa/ > date created: 2025-07-26 13:10 > > # Title: It’s Time for Modern CSS to Kill the SPA > <!-- deep-read:sections start --> ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## 📝 Summary: Jono Alderson argues that modern CSS features, including the View Transitions API and Speculation Rules, have eliminated the need for most Single Page Applications (SPAs). Historically, SPAs were the only way to achieve seamless, app-like navigation, but now native browser features allow Multi-Page Applications (MPAs) to match or exceed SPA performance without JavaScript bloat. The article calls for a return to HTML/CSS-first architecture for most websites, reserving SPAs for true application-level complexity. --- ## 📖 Main Content: - **App-like fallacy**: Many sites adopt SPAs not for technical necessity but due to stakeholder demands for an "app-like" feel. - **False promise of SPAs**: SPAs add heavy JavaScript to simulate native navigation but often fail to deliver smooth UX, introducing broken scroll, delayed hydration, and SEO complications. - **Modern CSS era**: - View Transitions API enables seamless, declarative page animations without JavaScript. - Speculation Rules allow prerendering and instant navigation with minimal effort. - Back/Forward Cache (bfcache) rewards simple, declarative, multi-page structures. - **Performance comparison**: - SPAs: Large JS bundles, fragile SEO, simulated transitions. - MPAs with modern CSS: Zero-JS, instant transitions, native behavior. - **Call to action**: Use HTML and CSS to build sites. Keep JS minimal and purposeful. Don’t use SPA patterns unless truly necessary. --- ### 🗒️ Notes - **SPA drawbacks**: - Heavy JS bundles to replicate native browser behavior. - Scroll restoration and focus management often broken. - Hydration delays harm perceived performance. - SEO complexity due to client-side routing. - **Native browser solutions**: - View Transitions: Animate between full-page navigations natively. - Speculation Rules: Prerender linked pages for instant navigation. - bfcache: Free performance boost for clean, multi-page sites. - **Code examples**: - CSS-only fade transitions using `@view-transition`. - Shared element animations without JS. - Speculation Rules for instant navigation. - **Cultural shift**: - Over-reliance on frameworks like Next.js and Nuxt for simple content sites. - Bootcamp patterns and hiring pipelines reinforce SPA defaults. - Browsers evolving to reward simplicity and standards. --- ## 📖 References: - Alderson, Jono. *It’s Time for Modern CSS to Kill the SPA*. jonoalderson.com, 24 July 2025. - View Transitions API documentation (MDN) - Speculation Rules proposal (W3C) --- ## 🗣️ Paraphrase: 1. **Original**: “SPAs were a clever solution to a temporary limitation. But that limitation no longer exists.” **Paraphrase**: “Single Page Apps solved an old problem, but the modern web platform has rendered that workaround unnecessary.” 2. **Original**: “Build a site like a site. Use HTML. Use navigation. Use the platform.” **Paraphrase**: “Treat websites as websites: lean on real pages, native links, and the browser’s built-in strengths.” --- ## 📰 Newsletter: 🔥 **Modern CSS vs. SPAs: The 2025 Debate** Jono Alderson is stirring the pot: with native View Transitions and Speculation Rules, most SPAs might be obsolete. His argument? Modern CSS now delivers seamless navigation without JavaScript bloat. The takeaway: if you’re building marketing sites, blogs, or docs with Next.js or Nuxt, you might be over-engineering. MPAs are back—and faster than ever. 👉 Code samples show CSS-only fade transitions and instant prerendering. 🔗 [Read the full article](https://www.jonoalderson.com/conjecture/its-time-for-modern-css-to-kill-the-spa/) --- ## ✅ Action Items: - Aligns with open-source advocacy by promoting web standards over heavy frameworks. - Supports contributor onboarding in WordPress: teaching native APIs simplifies entry-level learning. - Fits OSPO goals: emphasizes maintainability and interoperability. - Reinforces sustainable funding argument: leaner architectures reduce long-term maintenance costs. - Encourages educational content around modern CSS for the WordPress ecosystem. --- ## 🧪 Hypotheses: - H1: Sites using modern CSS + MPAs outperform SPAs in real-world Core Web Vitals. - H2: Developer onboarding and maintenance time drop when avoiding SPA frameworks for simple sites. - H3: Native browser features reduce reliance on JS libraries, improving accessibility by default. ### 📊 Methodology: - Compare SPA vs. MPA builds of the same site using Lighthouse, UX surveys, and maintenance logs. - Gather performance data in low-bandwidth environments. - Conduct developer experience studies on onboarding and code complexity. ### ❓ Questions: - How quickly will browser support for View Transitions and Speculation Rules reach parity? - What education is needed to shift dev culture back to MPA-first design? - How can WordPress core leverage these APIs for theme and plugin developers? ### 🔮 Future Research: - Explore hybrid models combining limited SPA islands with MPA cores. - Investigate impact of these patterns on accessibility and SEO at scale. - Study energy and bandwidth savings from reduced JS payloads. ### 💡 Implications: - Could shift industry hiring and bootcamp curricula toward standards-first development. - Encourages OSS CMS platforms to embrace browser-native capabilities. - Potential to lower infrastructure costs and environmental footprint of web apps. --- ## 🧠 Learning Styles Assessment: - **Visual**: Code snippets serve visual learners; could add diagrams of SPA vs. MPA flows. - **Aural**: No auditory content; adding TTS or podcast discussion recommended. - **Verbal**: Strong explanatory tone supports linguistic learners. - **Physical**: Interactive code sandboxes would enhance kinesthetic engagement. - **Logical**: Clear cause-effect arguments; adding performance graphs would reinforce. - **Social**: Lacks community prompts; link to discussion threads could foster collaboration. - **Solitary**: Offers reflection on dev practices; journaling prompts could be added. - **Naturalistic**: Could use resource efficiency metaphors to connect to environmental sustainability. --- ## 📊 Accessibility Assessment: - Ensure code samples have descriptive context for screen readers. - Article relies on text; adding alt-text to diagrams/code screenshots is crucial. - High contrast and semantic HTML assumed; confirm keyboard navigation compatibility. --- ## 🌍 DEIB Assessment: - Language mostly neutral; assumes technical background. - Could add culturally diverse case studies to broaden relevance. - Breaking long paragraphs into smaller chunks would help neurodiverse readers. - Avoid jargon where simpler terms exist to aid non-native English speakers. --- ## ✅ Logical Validity: - Strong causal reasoning: “Modern CSS solves SPA problems, therefore SPAs aren’t needed for most sites.” - Uses consistent analogies: “Build a site like a site.” - Minor **hasty generalizations**: blanket critique of all SPAs ignores good implementations. - No significant fallacies; tone is assertive but evidence-driven. --- 🔍 **DARVO Analysis** - **Deny**: Rejects SPA necessity in current web landscape. - **Attack**: Mild critique of dev culture adopting SPAs by default. - **Reverse Victim**: Frames browsers and users as victims of SPA overuse; not manipulative, but rhetorical. --- ### 🔍 SEO Evaluation: - **Keywords**: “Modern CSS,” “SPA,” “View Transitions” appear naturally. - **Title Tag**: Concise and keyword-rich. - **Meta Description**: Needs one summarizing CSS vs. SPA argument. - **Headers**: Well-structured; could add keywords to subheaders. - **Links**: External references good; internal links to related CSS articles would help. - **Mobile**: Code snippets responsive; confirm fast load. --- ## 🎯 Conclusion: Modern CSS and browser APIs have shifted the architectural debate. SPAs solved old limitations but now introduce unnecessary complexity for most sites. The article argues for a cultural correction: lean on the platform, keep JS minimal, and build MPAs with native transitions. The result? Faster, more accessible, and sustainable web experiences. <!-- deep-read:sections end --> [[3. Resources/Readwise/Full Document Contents/Articles/It’s Time for Modern CSS to Kill the SPA|Full Document Contents]] ## Document Notes ### 📝 **Summary of Hacker News Comments in Relation to the Article** * **Strong Agreement with the Core Argument** * Many commenters agreed with Jono’s central thesis: most sites don’t need SPAs and are over-engineered. * Developers echoed frustration with React and Next.js being used for simple marketing sites, causing performance hits and complexity for minimal gain. * Support for using modern CSS/View Transitions to solve what SPAs were once used for. * **Pushback & Counterarguments** * Multiple users argued the article misrepresents SPAs: they aren’t *primarily* about page transitions but about long sessions, complex state, and reducing server round-trips. * Some pointed out SPAs make sense when apps require decoupled frontends, offline support, or heavy client-side interaction (e.g., Figma, Google Maps). * A recurring theme: the author frames SPAs as a mistake when they’re often the right tool for real “applications.” * **Historical Context** * Several HN veterans traced SPA history back to jQuery, Backbone, and AngularJS days. * Comments discussed the shift from server-rendered apps to JS-heavy SPAs as a response to old browser limitations and developer workflow needs. * Debate over whether current browser capabilities (View Transitions, Speculation Rules) mean SPAs are now obsolete for most cases. * **Front-end vs. Back-end Culture Clash** * The thread surfaced an undercurrent of bias: some see front-end as “easier” work, others argue it’s just different but equally complex. * Discussions of developer culture, bootcamp influence, and overuse of React because “it’s what everyone learns first.” * **Performance Reality Check** * Many commenters provided anecdotal evidence of SPAs performing worse than MPAs even in ideal conditions. * Others noted that good engineering (code-splitting, caching, lean bundles) can make SPAs competitive, but poor implementations are rampant. * The “SPA for everything” trend is seen as a cause of web bloat and bad UX. * **Pragmatic Voices** * A subset advocated for a nuanced middle ground: * Use SPAs for actual apps with complex state and long-lived sessions. * Use MPAs with modern CSS transitions for most websites. * Don’t blame the tech—blame bad architecture and misapplied tools. --- Would you like me to turn this into the **full Markdown report** with all sections (🗒️ Notes, 🗣️ Paraphrases, ✅ Action Items, DARVO analysis, SEO audit, etc.) tied back to both the article and HN comment themes? Or do you want just a **condensed HN vs. article comparative summary**? ## Highlights - But the decision wasn’t really about architecture. It wasn’t even about performance, scalability, or content management. It was about *interactions*. About how the site would feel when you click around. The assumption was simple: ([View Highlight](https://read.readwise.io/read/01k348hzhsk0g3v8wepwkydh8r))