There is a pattern I see repeatedly in engineers who plateau early: they are fluent in the current framework but lose their footing the moment the framework changes. They're not bad engineers — they work hard and stay current. The problem is the strategy they're optimizing for.
Framework chasing is the practice of treating every new tool, library, or framework as a primary object of study. The next JavaScript meta-framework, the new Rust web crate, the hot take on state management. The resume grows. The depth doesn't.
What frameworks actually are
A framework is a set of opinions about how to structure code, encoded in library form. Those opinions exist to solve a set of recurring problems in a particular domain. To use a framework effectively, you need to understand the problems it's solving — and that requires understanding the domain at a level below the framework.
React solves the problem of synchronizing UI state with the DOM efficiently. To use React well, you need to understand the concurrency and consistency challenges of UI state management — not just the hooks API. Next.js solves the problem of delivering React applications with good performance characteristics. To extend it beyond the happy path, you need to understand HTTP caching, server rendering, and bundle splitting — not just file-based routing.
The framework is not the knowledge. The framework is a vehicle for applying knowledge you already have.
This is why engineers who deeply understand HTTP make better use of Next.js than engineers who have memorized the Next.js docs. The framework unlocks productivity once you have the underlying knowledge. Without it, the framework is a collection of magic incantations that mostly work until they don't.
The compounding returns of depth
Here's what I've observed in my own career and in the career arcs of engineers I admire: depth compounds. A year spent seriously studying how databases work — transactions, isolation levels, query planning, index design — pays dividends for the next twenty years across every database you'll ever touch. That year is not wasted when Postgres releases a new version. It's not wasted when you switch to a different system. It transfers.
The same is true for:
- Understanding how TCP/IP works — transfers to every networked system
- Understanding memory allocation and GC fundamentals — transfers across runtimes
- Understanding concurrency primitives — transfers from threads to coroutines to actors
- Understanding the lambda calculus — genuinely illuminates every functional language
Framework knowledge has a much shorter half-life. React will not be the dominant UI paradigm in ten years. The knowledge of how to manage derived state, handle asynchronous rendering, and think about component trees — that will survive.
The practical argument
I'm not making an abstract argument for intellectual purity. There's a direct professional benefit.
When something breaks in production, the engineer who understands what the framework is doing under the hood is the one who can diagnose it. When a new framework arrives with different opinions, the engineer with deep fundamentals can evaluate it quickly: what problem is this solving, is it the right tradeoff for my context, how does it compare to what I've seen before?
The framework-chaser has to start from scratch with each new tool. The fundamentals-focused engineer has a map.
The right balance
I'm not saying never learn frameworks. You have to ship software, and frameworks make that feasible. The point is about the ratio of effort. My rough heuristic:
- Know your primary framework well. Read the source. Understand how it works, not just how to use it.
- When you learn a new framework, focus on the problem it solves. The API will change. The underlying insight won't.
- Invest time in foundational understanding that doesn't expire. Algorithms, data structures, concurrency, networking, type systems, databases. These are slow to acquire and last forever.
- Be suspicious of tutorials that start with framework setup. The best learning often starts with first principles.
The engineers I've learned the most from all share one trait: they can reason clearly about a problem in the absence of any particular tool. The framework is just how they execute. The thinking happens at a level above it.