NoFrameworks [provocation] v1.0.0

Label

What If You Didn't Reach for a Framework?

Meta

• License: Apache-2.0
• License Provenance: package-authorship-claim

Trigger

team defaulting to React/Next.js/Vue for a content site, marketing page, blog, or tool with minimal interactivity — without evaluating whether a framework is justified

Question

Your landing page ships 200KB of JavaScript so a 'Sign up' button can be a React component. The same page, written in HTML + a 5KB inline script, would load 8x faster, work without JS, rank higher on SEO, and never break on hydration mismatch. What does the framework give you that you actually need? Or did you just reach for it because it's familiar?

Intent

Frameworks (React, Vue, Svelte, etc.) are excellent for stateful, highly-interactive applications — but the modern web has overcorrected: marketing pages, blogs, docs, and content sites that have minimal interactivity ship full SPA bundles by default. The performance, accessibility, and reliability cost is real and measurable. The provocation is not 'never use frameworks' — it is 'justify the framework against the alternative.' For many surfaces, the alternative (HTML + a sprinkle of JS, or a build-time tool like Astro/11ty/Hugo) is strictly better.

Resolution Paths

• • Context: Marketing landing page with a contact form and nav menu
  • Answer: Plain HTML + Tailwind + 1KB of vanilla JS for the menu toggle. LCP < 1s, no hydration, works without JS. If you absolutely need a framework, use Astro with zero-JS islands.
• • Context: Blog or docs site with code samples
  • Answer: Astro, 11ty, or Hugo. Markdown → HTML at build time. Add framework islands only where actually needed (search box, copy-button).
• • Context: Dashboard with real-time data, drag-drop, complex state
  • Answer: Yes, use React/Vue/Svelte. The complexity earns the bundle cost.
• • Context: Product page with a configurator (3D model, filters, live preview)
  • Answer: Use a framework — but be ruthless about code-splitting. Only ship the configurator JS to the configurator route.
• • Context: Existing app already on a framework, considering 'going vanilla'
  • Answer: Don't migrate. The cost of rewrites usually exceeds the JS-bundle savings. Apply the provocation to NEW surfaces, not existing ones.

Measurable Cost

• React 18 + Next.js minimal app: ~80–120KB gzip baseline
• Vue 3 + minimal Vite: ~60–90KB gzip baseline
• Svelte (compiled): ~10–30KB gzip baseline
• Plain HTML + small inline JS: ~5–15KB total
• Each 100KB of JS adds 1s to TTI on a slow 4G connection (750Kbps effective)

NoFrameworks [provocation] v1.0.0

Label

What If You Didn't Reach for a Framework?

Meta

• License: Apache-2.0
• License Provenance: package-authorship-claim

Trigger

team defaulting to React/Next.js/Vue for a content site, marketing page, blog, or tool with minimal interactivity — without evaluating whether a framework is justified

Question

Your landing page ships 200KB of JavaScript so a 'Sign up' button can be a React component. The same page, written in HTML + a 5KB inline script, would load 8x faster, work without JS, rank higher on SEO, and never break on hydration mismatch. What does the framework give you that you actually need? Or did you just reach for it because it's familiar?

Intent

Frameworks (React, Vue, Svelte, etc.) are excellent for stateful, highly-interactive applications — but the modern web has overcorrected: marketing pages, blogs, docs, and content sites that have minimal interactivity ship full SPA bundles by default. The performance, accessibility, and reliability cost is real and measurable. The provocation is not 'never use frameworks' — it is 'justify the framework against the alternative.' For many surfaces, the alternative (HTML + a sprinkle of JS, or a build-time tool like Astro/11ty/Hugo) is strictly better.

Resolution Paths

• • Context: Marketing landing page with a contact form and nav menu
  • Answer: Plain HTML + Tailwind + 1KB of vanilla JS for the menu toggle. LCP < 1s, no hydration, works without JS. If you absolutely need a framework, use Astro with zero-JS islands.
• • Context: Blog or docs site with code samples
  • Answer: Astro, 11ty, or Hugo. Markdown → HTML at build time. Add framework islands only where actually needed (search box, copy-button).
• • Context: Dashboard with real-time data, drag-drop, complex state
  • Answer: Yes, use React/Vue/Svelte. The complexity earns the bundle cost.
• • Context: Product page with a configurator (3D model, filters, live preview)
  • Answer: Use a framework — but be ruthless about code-splitting. Only ship the configurator JS to the configurator route.
• • Context: Existing app already on a framework, considering 'going vanilla'
  • Answer: Don't migrate. The cost of rewrites usually exceeds the JS-bundle savings. Apply the provocation to NEW surfaces, not existing ones.

Measurable Cost

• React 18 + Next.js minimal app: ~80–120KB gzip baseline
• Vue 3 + minimal Vite: ~60–90KB gzip baseline
• Svelte (compiled): ~10–30KB gzip baseline
• Plain HTML + small inline JS: ~5–15KB total
• Each 100KB of JS adds 1s to TTI on a slow 4G connection (750Kbps effective)

Relations

related: [@community/tradeoff-server-vs-client-rendering, @community/scope-public-facing-marketing, @community/metric-lcp-largest-contentful-paint, @community/principle-implementation-complexity-match]