Skip to main content

Current Research Synthesis 2026

Purpose​

This synthesis records the current external source signals used to deepen the guide. It is not a trend list. It explains which current platform and security facts should influence architecture guidance.

Source signals​

Source familyCurrent signalArchitecture implication
web.dev Web VitalsCore Web Vitals continue to center user experience around loading, responsiveness, and visual stability: LCP, INP, and CLS. Field measurement remains essential.Performance chapters should evaluate route and interaction quality with field data, not only lab audits or bundle guesses.
React official docsReact 19 stabilized Actions-related APIs, Server Components remain framework-mediated, and Server Functions move mutation ergonomics closer to UI code.Rendering/data chapters must separate ergonomic colocation from authorization, validation, idempotency, and cache invalidation boundaries.
MDN web standards modelOpen, interoperable, accessible, and backward-compatible web standards remain the stable base beneath framework churn.Part 0 and Part II should teach browser/platform reasoning before framework-specific decisions.
MDN CSP guidanceCSP is a browser-enforced policy layer that reduces XSS and resource-loading risk when designed deliberately.Security chapters should treat CSP/reporting/Trusted Types as architecture controls with rollout, triage, and ownership.
OWASP Client-Side Security RisksClient-side risk includes broken client-side access control, DOM XSS, sensitive leakage, outdated components, third-party origin control, JavaScript drift, client-side logging gaps, and missing browser controls.Review packets must cover browser-specific risks, third-party scripts, drift monitoring, and logging/alerting, not only backend OWASP concerns.
MDN cookies and privacy docsCookies are state mechanisms with explicit security and privacy implications; tracking and third-party behavior remain constrained by browser and regulatory pressure.Auth/session/privacy chapters need cookie attributes, consent-aware loading, minimization, and third-party governance.
MDN Attribution Reporting docsSome attribution reporting headers/APIs are deprecated, non-standard, or browser-limited.Attribution guidance must avoid false stability; teams should design measurement around uncertainty, fallback, consent, and source verification.
W3C/WAI WCAG 2.2Accessibility is a standards-backed product quality requirement, not a final QA pass.Design-system and review chapters should encode keyboard, focus, semantics, names, error help, target size, and cognitive load into component contracts.

Guide changes implied​

The guide should keep moving from "topic coverage" toward "decision capability." The deepest gaps are not missing definitions; they are missing examples of how architects actually run decisions through teams.

Add and maintain:

  • maturity models that calibrate senior, staff, and architect evidence
  • completed artifacts for route architecture, scorecards, threat models, readiness packets, and ADRs
  • operating cadence for architecture reviews, platform governance, performance/accessibility/security budgets, and incident learning
  • current-source refresh notes for unstable platform claims
  • scenario drills that force tradeoff decisions under time, product, and risk pressure

Maintenance triggers​

Re-check primary sources when:

  • React or a major framework changes server function, compiler, caching, or streaming guidance
  • Web Vitals metric definitions or thresholds change
  • browser privacy APIs or attribution APIs change support status
  • OWASP publishes a new client-side or web Top 10 update
  • WCAG or browser/assistive technology guidance changes
  • a new AI/GenUI protocol becomes a production dependency

Sources to keep pinned​