Why Frameworks Are Overused (And How to Avoid It)

The Framework-First Fallacy

In the landscape of 2026, the default response to almost any web development project is to start with a framework. Need a personal landing page? Reach for Next.js. Building a simple data dashboard? Boot up a React template. Creating a documentation site? Gatsby or Nuxt is the presumed choice.

We have reached a point where many developers—especially those who entered the industry in the last five years—literally cannot build a website without first installing a framework. This isn’t just a shift in preference; it’s a Framework-First Fallacy that prioritizes the developer’s comfort over the user’s experience and the project’s long-term health.

The Hidden Costs of Abstraction

While frameworks promise speed and consistency, they come with a significant “Abstraction Tax” that is rarely discussed in the hype-filled world of tech social media and YouTube tutorials.

1. The Bundle Size Reality Check

Let’s look at the math for a “simple” interactive site in 2026. If you use a modern meta-framework, your baseline might look like this:

• Framework Core (React/Vue/Angular): ~45KB - 130KB gzipped
• Hydration Logic: ~20KB - 50KB
• Routing & State Management: ~30KB
• UI Component Library (Radix, HeadlessUI, etc.): ~40KB
• Your Actual Business Logic: ~15KB

In this scenario, you are shipping nearly 300KB of JavaScript to the user just to deliver 15KB of unique functionality. On a high-speed fiber connection, this might feel negligible. But on a spotty 4G connection or an entry-level mobile device, that 300KB represents a multi-second delay in Time to Interactive (TTI). We are essentially forcing the user to download and execute a massive engine just to move a few pixels.

2. The Learning Curve Trap

Frameworks don’t just require you to learn JavaScript; they require you to learn a dialect of it. You aren’t just learning how to manipulate the DOM; you’re learning about “Hooks,” “Signals,” “Observables,” or “Virtual DOM reconciliation.”

By the time a developer masters the specific idioms of Framework A, Framework B has been released with a “revolutionary” new paradigm that makes Framework A look antiquated. This creates a cycle of Perpetual Relearning that steals time away from mastering the fundamental technologies (HTML, CSS, Browser APIs) that have remained stable for decades.

3. Dependency Hell and Maintenance Rot

Modern framework projects don’t just have dependencies; they have ecosystems. A simple npm install today can result in 2,000+ folders in your node_modules.

This creates a massive surface area for:

• Security Vulnerabilities: Every transitive dependency is a potential entry point.
• Breaking Changes: A minor update in a sub-dependency can break your entire build pipeline.
• Maintenance Rot: Try opening a framework project from three years ago and running it. The odds of it “just working” are near zero.

The Framework Necessity Test

Before you run npx create-..., put your project through this checklist. If you can’t check at least three boxes, you probably don’t need a framework.

• Does the application have highly dynamic, synchronized state across multiple UI components?
• Is the project being built by a team of 10+ developers who need strict architectural guardrails?
• Does the UI require complex, real-time updates (e.g., a collaborative editor or a high-frequency trading dashboard)?
• Are you building a “Single Page Application” (SPA) where navigation must happen without full page reloads for a specific UX reason?
• Do you need to leverage a specific, massive ecosystem of pre-built components that would take months to build from scratch?

Comparison: Vanilla vs. Framework (The Modal Example)

To illustrate the point, let’s look at how we might build a simple modal.

The “Modern Framework” Way: You import a Modal component, a Portal, a State hook, and probably an animation library. You write 50 lines of code, but you’ve added 4 dependencies and 80KB to your bundle.

The “Platform” Way (Vanilla JS):

// A modal in 2026 using the native <dialog> element
const modal = document.querySelector("#myModal");
const openBtn = document.querySelector("#openModal");
const closeBtn = document.querySelector("#closeModal");

openBtn.addEventListener("click", () => modal.showModal());
closeBtn.addEventListener("click", () => modal.close());

// Simple, performant, and requires ZERO dependencies.

By using the native <dialog> element, you get accessibility (focus trapping, ESC key to close) for free, with zero bundle size impact.

The Progressive Enhancement Approach

The alternative to “Framework-First” is Progressive Enhancement. It’s a philosophy that has guided the web since its inception, yet it feels revolutionary in the current climate.

1. Content First (HTML): Start with the semantic structure. Does the site work if JavaScript is disabled? It should.
2. Presentation (CSS): Layer on the design. Modern CSS (Grid, Container Queries, Layers) can handle 90% of the layouts that used to require JS-heavy libraries.
3. Enhancement (JS): Add interactivity. Use Vanilla JS for simple things. If a specific section of the page (like a complex filter or a shopping cart) needs heavy state management, use a “micro-framework” like Alpine.js or Petite-Vue only for that specific area.

We need to stop treating frameworks as the foundation and start treating them as the accessory.

When Frameworks Actually Make Sense

Lest I be accused of being a luddite: frameworks do have a place. If you are building Spotify, Figma, or Discord, a framework isn’t just helpful—it’s essential. These are applications where the state is so complex and the interactions so dense that managing them with Vanilla JS would be an exercise in masochism.

The problem isn’t that frameworks exist; it’s that we use them for everything. We are using a sledgehammer to hang a picture frame.

Pro Tip: The 80/20 Rule of Tooling 80% of the web consists of content-heavy sites (blogs, portfolios, documentation, marketing pages). 20% consists of complex “App-like” experiences. If you are in the 80%, you should prioritize Static Site Generators (like Hugo) and Vanilla JS. Save the heavy frameworks for the remaining 20%.

The Sustainability Argument

There is also a human and environmental cost to framework churn.

• Mental Health: The pressure to stay “current” with every framework update contributes significantly to developer burnout.
• Environmental Impact: Shipping megabytes of unnecessary JS across the globe every second consumes massive amounts of energy. A “light” web is a greener web.
• Accessibility: Framework-heavy sites often fail the “low-end device” test, effectively gatekeeping information from users who can’t afford the latest iPhone.

Conclusion

The next time you start a project, I challenge you to not install a framework. Try to see how far you can get with just HTML, CSS, and a sprinkle of Vanilla JavaScript. You’ll likely find that not only is it possible, but the resulting site is faster, easier to maintain, and more satisfying to build.

Learn the platform before you learn the abstraction. The framework you learn today will be gone in five years, but the browser APIs you learn today will serve you for the rest of your career.

As I argued in my comparison of static sites versus WordPress, I’ve broken down why simple is often better for your next project’s architecture.