Frameworks Come and Go, Fundamentals Don't
The Graveyard
Have a look at the front end alone. jQuery, then Backbone, then Angular 1, then Angular 2 which was not Angular 1 in any meaningful sense, then Vue, then React, then whatever is currently being announced at a conference in San Francisco.
Build tools: Grunt, then Gulp, then Webpack, then Vite. Node servers: Express, then Koa, then Fastify. Each transition arrived with blog posts explaining that this time we had it right.
I’m not sneering. Most of those moves were genuine improvements and I used nearly all of them happily at the time. The point is what happened to the people whose entire professional identity was the tool. Every hop left someone scrambling, because they had spent four years learning an API rather than an idea, and the API had just been deprecated by a company that owed them nothing.
The Boring Stuff That Never Moved
Meanwhile, nothing underneath changed at all.
Data structures and algorithms. A hash map behaves the way it behaved fifty years ago and will behave that way when we’re all dead. Knowing when a list is the wrong shape is not a trend.
HTTP and networking. Requests, responses, status codes, caching, cookies, TLS. The whole web still rests on it and it has barely shifted in the time most of us have been working.
SQL. Databases carry on being databases. Indexes, query plans, schema design, transactions, the eternal question of what your isolation level is actually doing.
Operating systems. Processes, threads, memory, file descriptors, why, the container fell over at 2am. The abstractions persist because the machine persists.
Design patterns. Not the ceremony, the ideas. The problems that produced them are still the problems.
Every one of those pays out for the rest of your career, and none of them will be rewritten by a maintainer having a strong opinion about the future.
Learn the Tool as an Instance of Something
I’m not telling you to ignore frameworks. You have to build with something, and “I only do fundamentals” is a lovely way to ship nothing at all.
The trick is what you take from the tool. When React eventually fades, and it will, the people who understood component models, reactivity, and how UI state gets managed will move across in a fortnight and mostly complain about the naming. The people who knew React’s API and nothing else will be starting again.
So while you’re learning the thing, keep asking what general idea it’s an instance of. React is a component model. TypeScript is a type system, and a fairly conventional one. Kubernetes is container orchestration and a lot of YAML. Redux is a state machine wearing a hat.
Learn the idea through the tool. The tool is a rental. The idea you get to keep.
The tool is a rental. The idea you get to keep.
The Argument Against
The honest counter is that you have to ship this week, not in five years.
Framework knowledge is what’s on the job spec and what’s directly billable. Knowing how TCP works does not help you get the modal to close properly by Friday, and there is something a bit smug about telling a junior to go and read about memory management when what, they need is to understand why the effect keeps firing twice.
There’s also a fair argument that frameworks carry real knowledge rather than just syntax. React’s mental model taught a generation of developers to think in terms of state producing UI, and that was genuinely a shift in how people reason about interfaces. Learning it properly is not wasted effort just because the API changes. The API was never the valuable part.
Where I Might Be Wrong
The rate of churn may be slowing, and if it is, my whole argument gets weaker.
React has been dominant for around a decade now, which is longer than several of its predecessors managed put together. TypeScript looks entrenched. Postgres is not going anywhere. At some point a tool that has been standard for fifteen years starts functioning as a fundamental in practice, whatever the taxonomy says, and someone who bet everything on it will have done perfectly well.
And fundamentals can absolutely be over-studied. Nobody writing a booking form needs to know assembly. There’s a version of this advice that turns into an excuse to read about compilers instead of shipping anything, and I’ve seen people take it that far. Practical beats theoretical eventually, and eventually arrives sooner than the theory crowd expects.
So treat the ratio as a nudge rather than a rule. Roughly most of your deliberate learning time on things that keep, roughly some of it on the ecosystem you’re currently paid to know. Adjust for what’s in front of you.
How I’d Spend the Time
- Pick one fundamental a quarter and go properly deep. Networking, then databases, then systems
- When you learn a tool, write down the general concept it implements. One sentence
- Read the source of the thing you use daily. It demystifies it and teaches you more than the docs
- Build a small, awful version of a tool you rely on. A router, a test runner, a state store
- Learn one new language, not one new framework, when you want a change of scene
- Notice which parts of your knowledge you keep re-explaining to yourself. Those aren’t fundamentals yet
The engineers I most admire could pick up a new stack in a couple of weeks. They’re not good at React. They’re good at understanding systems, and React happens to be the system currently in front of them.
Until next time, happy coding!