Rich client state, realtime collaboration, complex forms with cross-field validation, and component libraries reused across dozens of screens earn React, Vue, or Svelte. Hiring pool and testing tooling matter for product companies shipping weekly.
\n\nTime-to-interaction on admin apps beats time-to-first-byte. Different optimization function than marketing.
\n\nRegulated industries may mandate frameworks with audit trails and LTS versions. That constraint shrinks choice set before hype enters. Consultants selling rewrites frame every site as SPA. Second opinion from perf audit saves money.
\n\n// Ship criteria\n// - Team knows the framework\n// - Problem needs components/state/routing at scale\n// - Bundle cost < value of velocityBrochure sites, blogs, documentation, and campaign landers with annual copy changes are often static HTML, Astro, or Eleventy. Paying hydration cost for a hero and footer is poor trade.
\n\nSEO-critical content that must exist in first byte without JavaScript execution favors static generation or SSR with minimal client bundle.
\n\nInternal tools with 200 forms benefit from React Hook Form plus server validation mirror. Brochure with one form does not. Maintenance contract should state framework major version upgrade policy upfront.
\n\nInteraction density 1-5, content change frequency, team prior framework, hosting constraints, accessibility requirements, and perf SLAs. Score above threshold suggests framework. Below suggests static or islands.
\n\nPolitics counts: forcing Svelte on a React shop costs calendar. Technology choice includes people.
\n\nStartup runway: framework speed may matter more than perf for six months. I document refactor trigger metrics upfront. Government RFPs sometimes mandate specific stack; score sheet still helps optional modules.
\n\nMarketing static plus app subdomain is valid. Monorepo with shared tokens.css and separate deploy pipelines. Not every URL needs the same stack.
\n\nWordPress or Spring CMS plus headless front is framework on back, static or React on front. Pick per surface.
\n\nAcquisitions merge codebases; aligning on one framework is political. Technology scorecard helps execs decide. Student projects can use any framework; production payroll needs ops match.
\n\nStarting React for three pages locks dependencies for years. Starting static makes adding islands easier than stripping a SPA. I bias conservative on marketing roots, aggressive on product cores.
\n\nAccessibility requirements for complex widgets push toward mature component libraries with tested patterns.
\n\nDesign system maturity reduces framework switch benefit because tokens port.
\n\nWe need Next for SEO on four pages with no dynamic data. We need micro-frontends because two teams cannot agree on a repo. Framework because the bootcamp taught only React. I document no and why.
\n\nOffline-first PWA with sync may need client framework; read-only marketing site does not.
\n\nAI codegen accelerates boilerplate in any framework; choice still matters for runtime.
\n\nDescribe users, update cadence, and perf budget. I will return a one-page recommendation: stack, deploy target, and what not to buy. Frameworks are tools; the product is the point.
\n\nI write the decision in ADR with revisit date. Calendar reminder beats memory when team churns.
\n\nEnd-of-life framework versions are security debt with calendar deadline, not suggestion. For a related angle I keep coming back to, see Vite vs Next for Content-Heavy Sites.
","tags":["frameworks","react","architecture"],"views":66}