Why Developers Aren’t Really Ditching Frameworks for Vanilla JavaScript

…and why “no-build, native ES modules” can quietly expand your attack surface if you’re not careful. …and why “no-build, native ES modules” can quietly expand your attack surface if you’re not careful. The seductive myth of a framework exodus You’ve probably seen the headline: “Developers are ditching frameworks for Vanilla JavaScript.” It’s a compelling story. Everyone’s burnt out on React hooks discourse, upgrade churn, build tools, and megabyte bundles. Native browser APIs are better than ever. AI can scaffold code for you. And honestly, a clean index.html + a couple of tags does feel refreshing after years of pipelines. index.html But there’s a difference between a cultural mood and an actual industry shift. Yes, Vanilla JS is having a moment — especially in small projects, content-driven sites, and performance-obsessed setups. But the idea that frameworks are being abandoned misunderstands why they exist, how large teams work, and what actually happens when you throw unbundled ES modules into a real production environment. abandoned This piece is a rebuttal to the “frameworks are over” narrative — and a warning: naive “no-build, native module” setups can introduce very real security risks if you don’t treat them with the same rigor you apply to your build chain. Framework fatigue is real — but not a funeral Framework fatigue isn’t imaginary. Developers are tired: Endless churn: React → hooks → Suspense → Server Components; Vue 2 → Vue 3; meta-framework of the month.Toolchain sprawl: bundlers, linters, formatters, dev servers, test runners, SSR layers, adapters.Onboarding overhead: “To render a button, first learn our 12-layer architecture.” Endless churn: React → hooks → Suspense → Server Components; Vue 2 → Vue 3; meta-framework of the month. Endless churn: Toolchain sprawl: bundlers, linters, formatters, dev servers, test runners, SSR layers, adapters. Toolchain sprawl: Onboarding overhead: “To render a button, first learn our 12-layer architecture.” Onboarding overhead: But fatigue doesn’t logically lead to “ditch frameworks.” It leads to a different conclusion: We want leaner, clearer frameworks.We want better defaults, fewer layers, and tighter interoperability with the platform.We want to use frameworks where they’re justified, not everywhere by default. We want leaner, clearer frameworks. We want leaner, clearer frameworks. leaner clearer We want better defaults, fewer layers, and tighter interoperability with the platform. We want better defaults, fewer layers, and tighter interoperability with the platform. We want to use frameworks where they’re justified, not everywhere by default. We want to use frameworks where they’re justified, not everywhere by default. where they’re justified Frameworks arose to solve genuine problems: Shared architectural patterns across teamsState management for complex, long-lived UIsRouting, data fetching and cachingSSR/SSG and streaming for performance and SEODev tooling (hot reload, type integration, testing)Predictable component models across browsers and devices Shared architectural patterns across teams Shared architectural patterns State management for complex, long-lived UIs State management Routing, data fetching and caching Routing, data fetching and caching SSR/SSG and streaming for performance and SEO SSR/SSG and streaming Dev tooling (hot reload, type integration, testing) Dev tooling Predictable component models across browsers and devices Predictable component models These problems didn’t vanish in 2025 just because native APIs got nicer. Native APIs are powerful — but they don’t replace architecture Modern browsers are legitimately impressive now: fetch is standard.IntersectionObserver, MutationObserver, ResizeObserver… all built in.ES modules, import maps, Web Components, Shadow DOM.CSS has grown its own superpowers: container queries, :has(), etc. fetch is standard. fetch IntersectionObserver, MutationObserver, ResizeObserver… all built in. IntersectionObserver MutationObserver ResizeObserver ES modules, import maps, Web Components, Shadow DOM. CSS has grown its own superpowers: container queries, :has(), etc. :has() So, can you build rich interfaces with Vanilla JS + native APIs? Absolutely. For certain projects, it’s not just possible — it’s ideal. But there’s a hard line between capability and architecture. capability architecture Native APIs don’t give you: Opinionated app structure: Where does state live? How does it flow?Routing and data coordination: URL → data → UI → transitions.SSR/SSG strategies: SEO, initial render speed, personalization.Team-scale conventions: How do 20 developers avoid 20 patterns?Optimization heuristics: When and how to batch DOM updates?Cross-browser, cross-device guarantees: Polyfills and guardrails. Opinionated app structure: Where does state live? How does it flow? Opinionated app structure: Routing and data coordination: URL → data → UI → transitions. Routing and data coordination: SSR/SSG strategies: SEO, initial render speed, personalization. SSR/SSG strategies: Team-scale conventions: How do 20 developers avoid 20 patterns? Team-scale conventions: Optimization heuristics: When and how to batch DOM updates? Optimization heuristics: Cross-browser, cross-device guarantees: Polyfills and guardrails. Cross-browser, cross-device guarantees: Web Components are a powerful primitive, but: They’re low level.They don’t prescribe state management.They don’t address streaming rendering or hydration.They don’t give you a cohesive ecosystem on their own. They’re low level. They don’t prescribe state management. They don’t address streaming rendering or hydration. They don’t give you a cohesive ecosystem on their own. That’s exactly the space frameworks live in. Performance isn’t just “less JavaScript = faster” The “framework tax” is a real thing. Over-engineered SPAs for news articles, massive bundles for static marketing pages — that’s all fair criticism. But the argument “Vanilla JS is always faster because it’s less JavaScript” is too shallow. Modern frameworks have quietly evolved: Tree-shaking and code splitting are default, not exotic.Compiler-driven frameworks (Svelte, Solid, Qwik, etc.) remove runtime overhead.Partial hydration and islands architecture reduce JS on the critical path.React Server Components eliminate whole classes of client-side code.Static extraction (Next, Astro, Remix-style) generates HTML first, enhances later. Tree-shaking and code splitting are default, not exotic. Tree-shaking code splitting Compiler-driven frameworks (Svelte, Solid, Qwik, etc.) remove runtime overhead. Compiler-driven frameworks Partial hydration and islands architecture reduce JS on the critical path. Partial hydration islands architecture React Server Components eliminate whole classes of client-side code. React Server Components Static extraction (Next, Astro, Remix-style) generates HTML first, enhances later. Static extraction Meanwhile, hand-rolled Vanilla JS can easily become: DOM-manipulation soupHard-to-trace performance bugsMultiple competing patterns as teams growA graveyard of ad-hoc optimizations DOM-manipulation soup Hard-to-trace performance bugs Multiple competing patterns as teams grow A graveyard of ad-hoc optimizations Performance is less about “framework vs no framework” and more about: Right tool for the jobDoing less on the clientBeing thoughtful with data flow and renderingAvoiding unnecessary abstractions — including hand-made ones Right tool for the job Right tool for the job Doing less on the client Doing less on the client Being thoughtful with data flow and rendering Being thoughtful with data flow and rendering Avoiding unnecessary abstractions — including hand-made ones Avoiding unnecessary abstractions — including hand-made ones A minimal framework with strong defaults can outperform a sprawling DIY vanilla architecture any day. AI doesn’t kill frameworks — it upgrades them Another claim is that AI assistants make frameworks unnecessary because they can generate Vanilla JS quickly. The reality: AI thrives on structure and convention. Frameworks provide: A common vocabulary (useState, props, computed, etc.)Predictable file layouts and idiomsStable patterns that AI can recognize and refactor A common vocabulary (useState, props, computed, etc.) common vocabulary useState props computed Predictable file layouts and idioms Predictable file layouts Stable patterns that AI can recognize and refactor Stable patterns This means AI can: Scaffold React/Vue/Svelte components instantlyWire up routing, forms, and data fetching with standard patternsRefactor legacy patterns to modern idiomsSuggest performance optimizations within established constraints Scaffold React/Vue/Svelte components instantly Wire up routing, forms, and data fetching with standard patterns Refactor legacy patterns to modern idioms Suggest performance optimizations within established constraints Contrast that with a large Vanilla JS codebase where every team does things slightly differently. AI has less structure to lean on and more room for subtle misinterpretation. AI doesn’t erase the need for frameworks; it reduces the cognitive cost of using them well. The “no-build, native ES module” dream — and its security shadow Now to the interesting part: unbundled native ES modules in production. The vision is seductive: No bundler.No massive build pipeline.Just type="module" and import from URLs or relative files.Microfrontends, decoupled modules, fast deploys. No bundler. No massive build pipeline. Just type="module" and import from URLs or relative files. type="module" import Microfrontends, decoupled modules, fast deploys. This actually aligns nicely with the broader trend toward microfrontends and no-build architectures. But there’s a less discussed angle: microfrontends no-build architectures Every time you move responsibility from a controlled build pipeline to runtime resolution, you change your security story. Let’s unpack some specific risks. 1. CDN sprawl and origin trust Unbundled ES modules are often loaded from multiple origins: import { something } from "https://cdn.example.com/some-lib/v1/index.js"; import { helper } from "https://another-cdn.com/helpers.js"; import { something } from "https://cdn.example.com/some-lib/v1/index.js"; import { helper } from "https://another-cdn.com/helpers.js"; Risks: Risks: Expanded trust boundary: Every CDN, subdomain and path becomes part of your trusted compute surface.Compromised third party: A single compromised CDN/library update can inject malicious logic into your app without any build-time visibility.Dynamic imports: import() used with URLs built at runtime can be abused for injection if not tightly controlled. Expanded trust boundary: Every CDN, subdomain and path becomes part of your trusted compute surface. Expanded trust boundary: Compromised third party: A single compromised CDN/library update can inject malicious logic into your app without any build-time visibility. Compromised third party: Dynamic imports: import() used with URLs built at runtime can be abused for injection if not tightly controlled. Dynamic imports: import() Framework setups usually centralize dependencies into a lockfile & build step. The shift to runtime resolution can make this much more diffuse. 2. Weak or absent integrity guarantees Without a build step, teams often skip Subresource Integrity (SRI) and tight Content Security Policy (CSP) configurations. Subresource Integrity (SRI) No SRI on module imports: If you’re pulling modules directly from a CDN without SRI hashes, you’re trusting that resource to remain safe and unchanged, indefinitely.Loose CSP: If your CSP allows script-src https://cdn.example.com broadly, a compromised file anywhere on that CDN under your paths can become executable in your origin. No SRI on module imports: If you’re pulling modules directly from a CDN without SRI hashes, you’re trusting that resource to remain safe and unchanged, indefinitely. No SRI on module imports: Loose CSP: If your CSP allows script-src https://cdn.example.com broadly, a compromised file anywhere on that CDN under your paths can become executable in your origin. Loose CSP: script-src https://cdn.example.com https://cdn.example.com Bundled builds, by contrast: Embed fixed, fingerprinted assets.Are often hosted on the same origin.Can be locked down with stricter CSP (script-src 'self' + hashes). Embed fixed, fingerprinted assets. Are often hosted on the same origin. Can be locked down with stricter CSP (script-src 'self' + hashes). script-src 'self' With native ES modules loaded directly from multiple origins, you must be deliberate about: must SRI attributes on and where possible.Tightly scoped CSP, ideally with import maps limiting hostnames/routes.No dynamic construction of module URLs from user-controlled values. SRI attributes on and where possible. SRI attributes Tightly scoped CSP, ideally with import maps limiting hostnames/routes. Tightly scoped CSP No dynamic construction of module URLs from user-controlled values. No dynamic construction of module URLs from user-controlled values. 3. Dependency drift and silent changes With unbundled ES modules: It’s easy to reference remote versions like /latest/ or /v1/.It’s tempting to “just point to the CDN” instead of pinning versions and building locally. It’s easy to reference remote versions like /latest/ or /v1/. /latest/ /v1/ It’s tempting to “just point to the CDN” instead of pinning versions and building locally. Consequence: you lose deterministic builds. Consequence: A library can introduce a breaking change or a vulnerable version.That change is picked up immediately by users loading your app.No CI, no build, no review — just silent behavioral changes in production. A library can introduce a breaking change or a vulnerable version. That change is picked up immediately by users loading your app. No CI, no build, no review — just silent behavioral changes in production. Framework-driven bundlers are usually wired into CI: Dependencies are pinned in a lockfile.PRs update versions explicitly.Builds are tested before deployment. Dependencies are pinned in a lockfile. PRs update versions explicitly. Builds are tested before deployment. If you’re going no-build with ES modules, you need equivalent rigor in a different place: equivalent rigor in a different place Strong version pinning (no /latest).A mirrored/internal registry rather than live CDNs where possible.Monitoring and alerts for changes in remote resources. Strong version pinning (no /latest). /latest A mirrored/internal registry rather than live CDNs where possible. Monitoring and alerts for changes in remote resources. 4. CSP, import maps, and attack surface creep Import maps and ES modules give you new power — and new footguns. An import map like: { "imports": { "lib": "https://cdn.example.com/lib/v1/index.js" } } { "imports": { "lib": "https://cdn.example.com/lib/v1/index.js" } } If an attacker finds any injection vector that lets them modify this block (or inject a new one), they can: Redirect imports to a malicious endpoint.Hijack core logic without touching your original source. Redirect imports to a malicious endpoint. Hijack core logic without touching your original source. CSP can help, but: Many apps use overly permissive CSPs to “just get things working.”Few teams revisit CSP once shipped.Adding microfrontends/modules often leads to “temporarily relaxing CSP” that becomes permanent. Many apps use overly permissive CSPs to “just get things working.” Few teams revisit CSP once shipped. Adding microfrontends/modules often leads to “temporarily relaxing CSP” that becomes permanent. No-build architectures demand more disciplined CSP than many teams currently practice, not less. more disciplined CSP 5. Observability blind spots When everything goes through a build pipeline: You can statically analyze bundles.You can scan for vulnerable dependencies.You can trace what code ends up in which asset. You can statically analyze bundles. You can scan for vulnerable dependencies. You can trace what code ends up in which asset. With unbundled ES modules: Code is fetched from many paths at runtime.The effective dependency graph is constructed in the browser.Security scanners and SCA tools may miss dynamic imports or CDN-pulled modules. Code is fetched from many paths at runtime. The effective dependency graph is constructed in the browser. Security scanners and SCA tools may miss dynamic imports or CDN-pulled modules. Unless you intentionally: Log module usage,Track dependency URLs,And incorporate runtime scanning, Log module usage, Track dependency URLs, And incorporate runtime scanning, …you’ll likely lose visibility into what’s actually executing in the client. actually Vanilla JS vs frameworks is the wrong fight Stepping back, the real story isn’t: Frameworks bad, Vanilla JS good. It’s more: We abused frameworks where they weren’t needed, frameworks grew heavy in response to real complexity, the platform has caught up, and now we have more options than ever. Vanilla JS (plus modern browser APIs) is fantastic for: Content-heavy sites with light interactivityEmbeddable widgets and micro-interactionsHighly performance-sensitive surfacesTeams that genuinely value minimalism and know the tradeoffs Content-heavy sites with light interactivity Embeddable widgets and micro-interactions Highly performance-sensitive surfaces Teams that genuinely value minimalism and know the tradeoffs Frameworks remain essential for: Complex, long-lived productsMulti-team frontendsRich stateful applicationsSSR/SSG-heavy experiencesStrong conventions and onboardingMature tooling, testing and observability pipelines Complex, long-lived products Multi-team frontends Rich stateful applications SSR/SSG-heavy experiences Strong conventions and onboarding Mature tooling, testing and observability pipelines And the security story is this: Bundled, framework-driven pipelines give you a central choke point to control, scan, and reason about what’s shipped.Unbundled, native ES-module architectures give you flexibility and simplicity — but only if you replace build-time safety with runtime discipline. Bundled, framework-driven pipelines give you a central choke point to control, scan, and reason about what’s shipped. Bundled, framework-driven pipelines give you a central choke point Unbundled, native ES-module architectures give you flexibility and simplicity — but only if you replace build-time safety with runtime discipline. Unbundled, native ES-module architectures give you flexibility and simplicity — but only if you replace build-time safety with runtime discipline. Without that discipline, your “no-build, framework-free” setup can quietly become more fragile and more exposed than the “bloated” framework app you were trying to escape. more more The real reset: intentional choices, not pendulum swings The framework hangover is actually a wake-up call, but not the one the slogans suggest. It’s not: Rip out your framework and go raw Vanilla JS. It’s closer to: Use frameworks where their structure, tooling, and ecosystem bring real value. Use the platform directly where it’s enough. And wherever you land — with or without a build step — treat security, observability and maintainability as first-class concerns. In 2026, writing Vanilla JS doesn’t mean you’re going backwards. And using a framework doesn’t mean you’re stuck in the past. Progress isn’t about picking a side in “Vanilla vs Frameworks.” It’s about mastering both and being honest about the tradeoffs of each, including the security ones.