A Modest Server-Centric Development Proposal 🔗 **Source:** [A Modest Server-Centric Development Proposal](https://automattic.com/2026/02/17/server-centric-development/) > [!note]+ Document Notes > tags: [web-performance, javascript, architecture] > author: Sérgio Gomes > source: Automattic > reference: [https://automattic.com/2026/02/17/server-centric-development/] > date created: 2026-02-23 00:00 > > # 🏷️ Title: A Modest Server-Centric Development Proposal > <!-- 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) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened. - Sérgio Gomes argues that JS-heavy, React-style SPAs are structurally bad for long-term web performance and proposes server-centric architectures instead. - Why it matters. - Performance directly affects access, conversions, and user trust; current “modern” stacks make good performance fragile and expensive to maintain. - Key stakeholders. - Web product teams, WordPress and PHP/HTML developers, browser and framework authors, users on slower devices and connections. - Risks and tradeoffs. - JS-heavy DX and ecosystem benefits vs. persistent performance debt, monitoring overhead, ecosystem churn, and user exclusion. - Bottom line. - Default to server-rendered, HTML-centric, JS-lite designs; reserve heavy client-side frameworks for truly client-bound problems and treat performance as non-optional. ## 📖 Main Content - Explain the core arguments in plain language. - JS-heavy apps (especially React) start off slower and degrade over time due to growing bundles, fragile patterns, and performance-hostile defaults. - npm dependencies bloat bundles, and tools rarely surface size or runtime cost by default. - Frameworks encourage easy-but-wrong patterns: global context, sync imports, monolithic bundles, non-memoized selectors, and reducers that trigger widespread re-renders. - Performance fixes are fragile: one careless import or selector can undo months of work, and ecosystem churn (hooks, concurrency, testing tools, state management fashions) forces large rewrites. - Tooling is worse than the platform’s own: React’s profiler is siloed from browser devtools, lacks good aggregates, and common SSR hydration failures are opaque. - To keep a JS-heavy app fast, teams must invest in code-splitting, bundle tracking, lint rules, perf tests, CI perf gates, RUM, and ongoing education—significant overhead. - Performance is not optional: ignoring it effectively excludes users with low-end hardware, slow networks, or metered data. - Server-centric architectures move expensive work to predictable, controllable servers, shipping HTML and minimal JS instead of megabytes of client code. - Full-page navigation, HTML replacement (Turbolinks-like, View Transitions), and HTML-enhancing tools (htmx, WordPress Interactivity API) provide better baseline performance for many apps. - Some highly interactive tools (e.g., editors) may still need rich client-side UIs, but even there, React is no longer the obvious choice; newer frameworks offer smaller, more efficient runtimes. - Industry should stop reflexively choosing JS frameworks and ask whether client-side rendering truly benefits users for each project. - Add sourced context and define terms. - “Hydration”: matching server-rendered HTML with client JS to attach event handlers; monolithic hydration ships the entire app JS on first load. - “Performance budget”: explicit thresholds (e.g., Core Web Vitals) that releases must respect. - “RUM” (Real User Monitoring): measuring performance in real user sessions vs. lab tests. - “JS-lite” / “HTML-enhancing”: architectures where HTML is primary and JS augments interactions, not drives all rendering. - Note uncertainties or contested claims. - He relies on extensive anecdotal evidence from Automattic-scale work; he acknowledges possible selection bias and doesn’t present large comparative datasets. - He concedes that some client-side apps are justified and that server-side can also be slow if misdesigned. ### 🗒️ Notes - Author is a PerfOps engineer at Automattic focusing on browser-side performance; he has repeatedly seen the same classes of problems in JS-heavy stacks. - React is argued to be a framework (inversion of control) despite being marketed as a “library.” - JS-heavy narratives claim: faster iteration, fewer bugs, maintainability, agility, and “DevEx trickling down” to UX; his experience contradicts this in real-world, long-lived projects. - npm dependency bloat: large date libraries, utility bundles, design systems; many grow over time (e.g., `moment`, `react-dom` increases). Tools (npm, bundlers, IDEs, Dependabot) rarely surface size deltas by default. - Performance-hostile defaults: - Top-level contexts shared everywhere vs. localized data. - Synchronous imports vs. conditional dynamic imports. - Single monolithic bundle vs. route-based code-splitting and shared chunks. - Simple but wasteful Redux reducers and selectors vs. change detection and memoization. - Overuse of inline SVG components vs. external SVG sprites. - Tutorials often teach the simplest (and slowest) patterns, sometimes with only a footnote warning that “production code will differ.” - Performance fragility: - One static import of a heavy library can reintroduce it into the critical path. - One bad selector or reducer can degrade every action. - New team members or those from other stacks are likely to make these mistakes. - Debugging pain: - Browser devtools are excellent, but React’s devtools ignore them and use separate profiling, with no integrated view of JS execution and React commits. - Preact is praised for integrating with native devtools and annotating profiles with component events. - Hydration errors in SSR React apps often yield unhelpful messages, making root-cause analysis hard. - Redux devtools lack direct support for finding slow selectors/reducers. - Bundlers don’t default to building bundle composition maps; extra plugins are required. - Mitigation strategies proposed: - Organization-level buy-in that performance affects business outcomes. - Project-specific performance budgets. - Careful stack and architecture selection; consider SSR and where latency lies. - Code splitting by route, shared bundles, and deferred loading of non-critical chunks. - Automated bundle size tracking in local builds and CI with PR comments for regressions. - Lint rules for forbidden imports, preventing monolithic vs. modular misuse, enforcing dynamic imports where required. - Perf tests using Puppeteer/Playwright, with CPU/network throttling, per-PR runs, and careful CI stability tuning. - Historical metrics dashboards and RUM integration with custom metrics relevant to the app. - Feedback loops with support teams to surface real user pain points. - He argues the overhead of this perf program is only realistic for large, well-funded orgs; smaller teams can’t sustain it. - React ecosystem instability examples: hooks vs. classes, React 18 concurrency changes, Enzyme deprecation for tests, shifting state management fashions. - “Is performance optional?”: ignoring it effectively chooses a privileged subset of users and higher user data costs. - Server-centric alternative: - JS is the heaviest resource; parsing, compiling, and executing are CPU-expensive and mostly single-threaded on the client. - Servers have better CPUs, power budgets, and cache behavior; you control them and can log/trace easily. - HTML-first designs equalize experiences across cheap phones and powerful desktops. - SSR + monolithic hydration is a half-measure that may improve paint but harms interactivity time. - Recommended patterns: - Plain full-page navigation on good hosting/CDN. - HTML replacement (Turbolinks-like, View Transitions API). - HTML-enhancement (htmx, WordPress Interactivity API). - Some apps (e.g., rich editors) can justify client-heavy designs, but React is now an unattractive default given its size, pitfalls, and lack of novelty; other frameworks offer finer-grained reactivity and smaller runtimes. - Closing plea: stop reflexively using JS-heavy stacks; evaluate whether client-side rendering actually benefits users vs. offloading work they shouldn’t bear. ## 📚 References - Automattic – “A Modest Server-Centric Development Proposal” (https://automattic.com/2026/02/17/server-centric-development/) - Google Web Fundamentals – Core Web Vitals (https://web.dev/vitals/) - MDN Web Docs – View Transitions API (https://developer.mozilla.org/en-US/docs/Web/API/View_Transitions_API) - htmx (https://htmx.org/) - WordPress Interactivity API (https://developer.wordpress.org/block-editor/reference-guides/packages/packages-interactivity/) ## 🗣️ Paraphrase - Paragraph A paraphrase. - Many modern JS-heavy web apps, especially those built with React, are structurally inclined toward poor performance and require enormous ongoing effort to keep fast, making them a bad default for most projects. - Paragraph B paraphrase. - Shifting as much work as possible to servers—serving HTML with only modest client-side enhancements—usually leads to faster, more inclusive experiences and more sustainable performance maintenance, so teams should reconsider automatic reliance on big client frameworks. ## 📰 Newsletter In this week’s performance-focused dispatch, we’re spotlighting Sérgio Gomes’ “A Modest Server-Centric Development Proposal” from Automattic. Gomes, a PerfOps engineer, lays out why JS-heavy React apps almost inevitably bloat, slow down, and demand expensive observability just to stay “okay.” His alternative: HTML-first, server-centric architectures with a sprinkle of JS, bolstered by tools like htmx and the WordPress Interactivity API. If you care about Core Web Vitals, user inclusivity, and sustainable performance budgets, this is essential reading. Pair it with a review of your own stack’s bundle sizes, perf budgets, and RUM setup—and consider whether your next feature really needs a client-side framework, or just solid server rendering plus a bit of progressive enhancement. ## ✅ Action Items #### DevRel - Publish a technical deep-dive on server-centric patterns in WordPress (Interactivity API, full-page navigation, Turbolinks-style flows). - Create sample repos showing “React SPA vs. HTML-first” implementations with perf comparisons. - Run workshops on setting and enforcing performance budgets, including bundle tracking and RUM. - Develop talks for WordCamps on “JS-lite architectures in a React-heavy world.” - Add quickstarts and templates for HTML-enhancing approaches in DX docs. - Survey developers on perceived vs. actual perf of their current stacks. #### OSPO - Encourage upstream contributions to HTML-first tools (htmx, Interactivity API, relevant PHP frameworks). - Document guidance discouraging unnecessary JS-heavy stacks for public-facing properties. - Add license and security checks into dependency management to limit churn-driven rewrites. - Track ecosystem risks of relying on unstable JS libraries and frameworks. - Support upstream funding for server-centric tooling and observability. #### Community - Host maintainer clinics on migrating from heavy SPAs to JS-lite/server-rendered architectures. - Offer contributor pairing on performance profiling and bundle size reduction. - Share case studies of successful server-centric migrations and associated business metrics. - Encourage sponsors to back performance-focused refactors and infra work. - Run cross-project incidents drills around performance regressions and rollback strategies. #### WordPress - Core: reinforce performance budgets for new features and evaluate JS usage critically in proposals. - Core Performance: expand profiling for real-world themes/plugins; integrate automated perf checks into CI. - Core AI: ensure AI-driven features avoid unnecessary client-side heavy computation where servers suffice. - **Core Program Team:** schedule regular cross-team perf reviews and roadmaps aligned with HTML-first goals. - Mobile: ensure frontends consume HTML-first APIs efficiently; avoid re-implementing heavy client logic. - Playground: provide labs comparing SPA vs. server-centric implementations under throttled conditions. - Community: include perf best practices in meetup kits and WordCamp content tracks. - Training: design learning paths on server-centric architectures and progressive enhancement. - Marketing: shift narratives away from “modern == React SPA” toward “modern == fast and inclusive.” - Support: improve triage for performance-related tickets; surface patterns from recurring issues. - Design: incorporate performance as a first-class design constraint; avoid JS-heavy interaction patterns by default. - Documentation: expand examples for Interactivity API and JS-lite patterns; emphasize perf implications. - Photos / TV / Polyglots / Accessibility / Meta / CLI / Hosting / Tide / Openverse / Themes / Plugins: - Embed perf considerations into contribution guidelines, review checklists, and automated checks, especially regarding JS payloads and client-side frameworks. #### The WPOCC - Programs: support maintainers focused on performance refactoring and server-centric transitions. - Projects: organize documentation sprints on HTML-first and JS-lite design patterns. - Funding experiments: pilot grants for projects that replace heavy SPAs with server-centric architectures and publish results. ### FAIR - Technical independence: prefer architectures that don’t hard-lock communities into specific JS frameworks. - Policies and covenants: document commitments to user-centric performance, including constraints on JS payloads. - Productized governance artifacts: create scorecards and checklists assessing perf impact of architectural choices. ## 🧪 Hypotheses - H1: Long-lived React-based SPAs require significantly more ongoing engineering time to maintain good performance than comparable server-centric apps. - H2: Users on low-end devices experience disproportionately worse UX on JS-heavy SPAs than on HTML-first, JS-lite sites. - H3: Automated bundle-size tracking and perf CI gates slow performance degradation but do not eliminate it in JS-heavy stacks. - H4: For most content and CRUD apps, server-centric architectures achieve better Core Web Vitals at equal or lower total development cost. - H5: Integrating framework profiling into native browser devtools materially improves engineers’ ability to fix performance issues. ### 📊 Methodology - For H1 & H4: - Comparative longitudinal case studies of similar products implemented as React SPAs vs. server-rendered apps. - Track perf metrics, engineering hours spent on perf work, and feature velocity over multiple releases. - For H2: - Lab studies on representative low-end and mid-range devices using throttled networks, measuring Core Web Vitals and task completion times across architectures. - For H3: - A/B study on JS-heavy projects with and without strict perf CI; compare slope of metric degradation and regression frequency. - For H5: - Controlled experiment where teams debug seeded perf issues using (a) separate framework tools vs. (b) integrated devtools overlays, measuring time-to-fix and accuracy. ### ❓ Questions - When is a heavy client-side framework truly necessary, versus habit or tooling inertia? - How can we standardize perf budgets and enforcement mechanisms across diverse teams and stacks? - What incentives or metrics best encourage product leadership to prioritize performance over short-term feature velocity? - How can community-driven ecosystems like WordPress lead a shift back toward server-centric defaults? - What minimum-level JS payload should public-facing sites aim for as a norm? ### 🔮 Future Research - Framework-agnostic profiling standards that integrate seamlessly with browser devtools. - Patterns and tooling for gradual migration from React SPAs to HTML-first, JS-lite architectures. - Longitudinal CrUX-based comparisons of SPAs vs. server-rendered sites across industries. - Better educational materials that teach performance-safe patterns as the default, not advanced. ### 💡 Implications - Practice: Teams should reconsider stack choices at project inception and bias toward server-rendered, HTML-centric solutions. - Policy: Organizations may codify performance budgets and limit JS payload sizes for customer-facing properties. - Security: Reducing client JS surface may shrink attack vectors and dependency-driven supply-chain risk. - Education: Curricula should treat performance and accessibility as core, not optional, and show non-SPA architectures. - Funding: Grant-making bodies and sponsors might prioritize performance and inclusivity refactors over new SPA rewrites. ### 🧠 Learning Styles Assessment - Reading level estimate: Around upper high-school / early college, using a rough Flesch-Kincaid scan (multi-clause sentences, domain terms). #### 👀 Visual learners - Present: Conceptual contrasts (client vs. server), examples of architectures. - Improve: Add diagrams of request flows, hydration vs. HTML-first pipelines, and perf dashboards. #### 🔊 Aural learners - Present: No audio, but narrative style supports narration. - Improve: Provide a 3–5 minute audio summary and podcast-style discussion. #### 🗣️ Verbal learners - Present: Clear definitions (framework vs. library, RUM, hydration), analogies (recipes vs. ready meals). - Improve: More explicit glossaries and side-by-side comparisons of key terms. #### 🧩 Kinesthetic learners - Present: Actionable suggestions (setup steps for perf monitoring and code-splitting). - Improve: Hands-on labs with reproducible SPA vs. server-centric implementations. #### 🧠 Logical learners - Present: Stepwise arguments, causal chains (JS weight → CPU cost → UX). - Improve: Tables comparing tradeoffs across architectures and more explicit quantified examples. #### 🧑‍🤝‍🧑 Social learners - Present: Implicit team-oriented actions (getting everyone aligned on performance). - Improve: Discussion prompts and team workshop guides. #### 🧘‍♀️ Solitary learners - Present: Long-form essay with room for reflection. - Improve: Reflection questions and short self-assessment checklists. #### 🌿 Naturalistic learners - Present: Indirectly touches on resource waste (data, energy). - Improve: Explicit discussion of environmental costs of heavy JS and server vs. client energy profiles. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Blog post likely uses standard headings and landmark structure. - Improve: Ensure descriptive headings and proper alt text where applicable. #### Keyboard navigation - Present: Standard WordPress theme behavior (likely decent). - Improve: Confirm focus outlines, skip links, and logical tab order. #### Contrast and readability - Present: Typical Automattic styling, generally adequate. - Improve: Recheck contrast in code samples, links, and inline notes. #### Text resizing and reflow - Present: Responsive layout should support zoom and reflow. - Improve: Verify no horizontal scrolling at 200% zoom and respect prefers-reduced-motion. #### Media and captions - Present: Primarily text; minimal media. - Improve: If diagrams or videos are added, ensure captions/transcripts. #### Forms and interactions - Present: Minimal interactive elements in article itself. - Improve: Site-wide forms should follow accessible label, error, and target-size patterns. #### Standards reference - Map gaps to WCAG 2.2 AA for perceivable, operable, understandable, robust content. ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focus on global users with weaker devices/connections. - Improve: Include explicit examples from multiple regions and bandwidth realities. #### Inclusive language - Present: Generally neutral, user-centered language. - Improve: Reduce jargon further and add plain-language summaries. #### Neurodiversity support - Present: Chunked sections with headings, logical flow. - Improve: More subheadings, bullet lists, and consistent callout patterns. #### Representation - Present: Mainly technical content; limited visual representation. - Improve: If images are added, ensure diverse, non-stereotypical representation. #### Psychological safety - Present: Critiques tools and practices, not individuals; respectful tone. - Improve: Add clear community guidelines and constructive framing for change. ### ✅ Logical Validity #### Strong reasoning - Uses causal reasoning: JS cost → device strain → poor UX, especially on weaker devices. - Inductive reasoning from repeated case studies across stacks to general concerns about JS-heavy approaches. - Acknowledges limitations and possible selection bias, which strengthens credibility. #### Fallacies - Potential overgeneralization: heavy reliance on Automattic and similar experiences may not represent every React app. - Fix: Frame more arguments as conditional (“in many long-lived apps…”) and supplement with broader empirical data. #### Tone of voice - Tone is candid, slightly exasperated, but professional and user-advocacy driven. - Uses rhetorical questions to challenge norms (“Is performance optional?”) and motivate re-evaluation. ### 🛡️ DARVO Analysis - Deny: Does not deny issues; instead, highlights problems in prevailing “modern” narratives. - Attack: Critiques technologies and patterns (React, JS-heavy approaches) but does not attack individuals or users. - Reverse victim/offender: Does not portray developers as victims; instead, centers users suffering from poor performance. - Overall: The piece is a critique of norms, not an example of DARVO dynamics. ## 🎯 Conclusion - Restate the bottom line. - JS-heavy, React-style architectures generally make good performance fragile, expensive, and exclusionary, especially over the long term. Server-centric, HTML-first, JS-lite approaches usually offer better, more sustainable user experiences and are underused as defaults. - Note practical next steps for readers. - Audit your current JS payloads and Core Web Vitals; set explicit performance budgets; consider whether upcoming features genuinely require heavy client-side frameworks; explore server-rendered and HTML-enhancing patterns; and integrate lightweight monitoring and bundle tracking to keep user experience—not developer convenience—at the center of architectural decisions. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [{Title or entity}](https://automattic.com/2026/02/17/server-centric-development/) by [[Sérgio Gomes]] via [[Automattic]]. Published 2026-02-17. > “JS-heavy web apps are fragile and performance-hostile.” Two lines: context and use. Cite data if relevant. [view highlight](https://automattic.com/2026/02/17/server-centric-development/#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [{Title or entity}](https://automattic.com/2026/02/17/server-centric-development/) > “Server-centric, HTML-first architectures better serve users.” Two lines: context and use. [view highlight](https://automattic.com/2026/02/17/server-centric-development/#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] JS-heavy apps make performance fragile over time - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Web-Performance]] [[Frontend-Architecture]] #### [Z2] Server-centric rendering improves inclusivity and reliability - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Web-Performance]] [[Backend-Architecture]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Audit my main projects’ JS bundle sizes and perf budgets — context/https://automattic.com/2026/02/17/server-centric-development/ #fleeting #inbox - [F2] Prototype a server-centric version of a current SPA feature — context/https://automattic.com/2026/02/17/server-centric-development/ #fleeting #inbox - [F3] Design a workshop on HTML-first, JS-lite architectures — context/https://automattic.com/2026/02/17/server-centric-development/ #fleeting #inbox --- <!-- deep-read:sections end -->