Going Lean: Why Some Developers Are Ditching the Framework Stack Entirely

Open any job posting for a mid-level web developer in 2024 and you'll see the usual suspects: React, Next.js, TypeScript, a handful of testing libraries, maybe a state management tool or two. The modern JavaScript ecosystem has consolidated around a recognizable set of heavy-hitters, and for good reason — these tools solve real problems and come with enormous communities behind them.

But spend enough time in certain corners of GitHub, Hacker News, or the more opinionated dev Discord servers, and you'll notice something: a growing number of experienced developers are quietly walking away from that stack. Not because they can't use it — because they've decided they don't want to.

This isn't a fringe movement. It's a genuine philosophical shift, and it's worth taking seriously.

The Dependency Problem Nobody Talks About

Here's a number that should give you pause: the average React application ships with somewhere between 700 and 1,500 npm packages as dependencies, depending on how you count them. Most developers have no idea what the majority of those packages actually do. They're the accumulated weight of years of decisions — some deliberate, many automatic — baked into starter templates and framework defaults.

That weight has real consequences. Build times creep up. Bundle sizes balloon. Security vulnerabilities surface in packages you've never heard of that are six layers deep in your dependency tree. And the cognitive overhead of keeping all of it updated, compatible, and functioning together becomes a job in itself.

The left-pad incident from 2016 — where a developer unpublished a tiny utility package and broke thousands of builds worldwide — was a wake-up call that a lot of teams quietly filed away and forgot. But some developers didn't forget. They started asking an uncomfortable question: how much of this do we actually need?

The Case Studies That Make You Think

Take the case of Fastmail, one of the few email providers that has consistently outperformed Gmail on raw interface speed. Their frontend is built on a deliberately minimal JavaScript foundation — no React, no Vue, no Angular. Their engineers have written publicly about the tradeoffs, and the throughline is consistent: owning your code means understanding your code, and understanding your code means you can optimize it in ways framework users simply can't.

Or look at the explosion of interest around tools like HTMX, which lets you add dynamic behavior to HTML without writing a single line of JavaScript framework code. The project's tagline — high power tools for HTML — is almost aggressively anti-framework. And yet it's landed on the GitHub trending page multiple times and has attracted serious attention from developers who've spent years in React.

Then there's the Go ecosystem, where the standard library philosophy is almost the opposite of JavaScript's. Go developers are culturally biased toward solving problems with the standard library before reaching for a third-party package. The result is a community that produces remarkably lean, maintainable codebases — and a very different kind of debugging experience.

When Minimalism Actually Works

Let's be honest about the limits here, because this is where the conversation tends to go sideways. Minimal-dependency development isn't a universal answer. There are real scenarios where a mature framework is the correct choice, full stop.

If you're building a large application with a team of ten or more engineers, a shared framework creates a common language that makes collaboration dramatically easier. If you're moving fast in a startup environment and your bottleneck is shipping features rather than performance, the productivity benefits of a well-understood framework are real and measurable. And if you're building something with genuinely complex state management needs, reinventing that wheel from scratch is a bad trade.

But here's where the calculus shifts: content-heavy sites, internal tools, developer utilities, and applications where performance is a competitive differentiator. In those contexts, the overhead of a heavy framework isn't just unnecessary — it's actively counterproductive.

A marketing site doesn't need a virtual DOM. An internal dashboard with three views doesn't need a routing library with twenty configuration options. A command-line tool doesn't need a test suite that takes four minutes to run. The mismatch between tool and problem is where most of the pain lives.

The Autonomy Argument

Beyond performance, there's a softer argument that resonates with a lot of the developers pushing this approach: autonomy.

When you depend heavily on a framework, you're making a long-term bet on that framework's continued development, stability, and community health. Angular 1 to Angular 2 was a migration that burned a lot of teams. The React ecosystem's rapid evolution — hooks replacing class components, server components changing the mental model again — demands ongoing attention and re-learning that has a real cost.

Developers who build on minimal, stable primitives — web standards, the platform itself, language built-ins — don't carry that risk. The web platform's commitment to backwards compatibility means that vanilla JavaScript written in 2015 still runs fine today. That's not true of most framework code from the same era.

This is the argument that lands hardest with senior engineers who've been through multiple framework cycles. They've migrated enough codebases to have a visceral appreciation for stability.

What This Means for How We Build

The rise of minimal-dependency development isn't going to kill React or Next.js. Those tools are too entrenched, too useful in the right contexts, and backed by too much institutional momentum. But the conversation happening around them is healthy and overdue.

The best developers have always been tool-agnostic at heart. They reach for the right instrument for the job rather than defaulting to whatever's familiar. What the lean development movement is really pushing for — underneath all the framework skepticism — is intentionality. Knowing what you're using, why you're using it, and what it costs you.

That's not contrarianism. That's just good engineering.