Every week there's a new JavaScript framework. A new CSS library. A new state management tool. A new way to do the thing you were already doing just fine.
And every week, developers on Twitter panic because they haven't learned the new thing yet.
I'm going to say something that might be controversial: stop learning new frameworks. At least for a while. It's doing more harm than good.
The Framework Treadmill
Let me paint a picture. It's 2024. You learn React. By the time you're comfortable, everyone's talking about Next.js. You learn Next.js. Then it's Remix. Then it's Astro. Then it's whatever dropped this Tuesday.
Each time you switch, you spend weeks learning the new syntax, the new patterns, the new ecosystem. And each time, you think THIS is the one that'll make you a better developer.
But here's the thing: you're getting better at learning frameworks. You're not getting better at building software.
Those are two very different skills.
What You Should Be Learning Instead
1. Data Structures and Algorithms (Yes, Really)
I know. Everyone hates DSA. "When am I ever going to need a binary tree in real life?"
Probably never. But here's what DSA actually teaches you: how to think about problems systematically. When you understand Big O notation, you stop writing code that works on 100 items but crashes on 10,000. When you understand hash maps, you stop doing nested loops for lookups.
You don't need to grind LeetCode for hours. Just understand the basics:
- Arrays vs. linked lists (when to use which)
- Hash maps (why they're your best friend)
- Trees and graphs (how data relates to other data)
- Time complexity (is your code fast or is it just fast on small inputs)
This knowledge transfers to EVERY framework and EVERY language. React, Swift, Rust, whatever comes next in 2027. The fundamentals don't change.
2. How the Internet Actually Works
I've interviewed developers who can build a full React app but can't explain what happens when you type a URL into a browser. They know how to call an API but don't understand HTTP methods, status codes, or headers beyond what their framework handles for them.
Learn these properly:
- HTTP/HTTPS (request/response cycle, methods, headers, status codes)
- DNS (how domains turn into IP addresses)
- Caching (browser cache, CDN, server-side cache)
- Authentication (cookies, tokens, OAuth flow)
- CORS (why it exists, not just how to disable it)
When you understand these, you can debug network issues in ANY framework. You're not searching "Next.js CORS error" or "React fetch not working." You understand the protocol and can fix the actual problem.
3. SQL
Every app uses a database. Every single one. Yet most bootcamp grads and self-taught developers treat SQL like an afterthought.
They learn just enough to do SELECT * FROM users and then rely on an ORM for everything else. When the ORM generates a slow query, they're stuck.
Learn SQL properly:
- JOINs (inner, left, right, cross)
- Aggregations (GROUP BY, HAVING, COUNT, SUM)
- Indexes (what they are, when to create them)
- Query optimization (EXPLAIN, avoiding N+1 queries)
- Transactions (ACID properties, when you need them)
I switched from MongoDB to PostgreSQL last year. Knowing SQL well saved me weeks of debugging because I could write efficient queries from day one. The framework changed. The SQL knowledge stayed.
4. Design Patterns
Not the "Gang of Four" textbook with 23 patterns you'll never use. The practical patterns that show up everywhere:
- Observer pattern: How event systems, notifications, and reactive frameworks work. Once you get this, you understand React state, SwiftUI bindings, and RxJS at a deep level.
- Strategy pattern: How to swap algorithms or behaviors at runtime. Shows up in payment processing, sorting, validation.
- Repository pattern: How to separate data access from business logic. Shows up in every backend and most mobile apps.
- Factory pattern: How to create objects without specifying exact classes. Shows up in dependency injection, testing, configuration.
These patterns exist in every language and every framework. Learn them once, apply them everywhere.
5. Git (Beyond Push and Pull)
Most developers know: add, commit, push, pull. That's about 20% of Git.
Learn these and your productivity doubles:
- Interactive rebase (clean up your commits before merging)
- Cherry-pick (grab a specific commit from another branch)
- Bisect (find exactly which commit introduced a bug)
- Stash (save your work without committing)
- Reflog (recover from almost any Git mistake)
I once saved a teammate's two weeks of work using git reflog after they accidentally force-pushed to the wrong branch. They thought the code was gone forever. It took me 30 seconds to recover it.
6. Testing
Not just "how to write a unit test." Understand the testing pyramid:
- Unit tests: Test individual functions. Fast, isolated.
- Integration tests: Test components working together. Medium speed.
- End-to-end tests: Test the whole system. Slow but thorough.
Learn WHEN to write each type. Learn how to write tests that actually catch bugs instead of just getting the coverage number up.
A developer who writes good tests is worth three developers who don't. Because they ship code that works the first time.
7. System Design Basics
You don't need to design Netflix at scale. But you should understand:
- Client-server architecture
- REST vs. GraphQL (tradeoffs, not just syntax)
- Caching strategies
- Message queues (when and why)
- Load balancing (concepts, not implementation)
When you understand system design, you make better decisions at the code level. You know when a simple REST API is enough and when you actually need WebSockets. You stop over-engineering small projects and under-engineering large ones.
The "T-Shaped Developer" Approach
Here's what I recommend instead of the framework treadmill:
Go deep in ONE technology. Pick your lane and become an expert. For me, that's Swift and SwiftUI. For you, it might be React, or Python, or Go.
Then go wide on fundamentals. Networking, databases, system design, testing, algorithms. These apply to everything.
Fundamentals (wide)
┌─────────────────┐
│ HTTP │ SQL │ Git │
│ DSA │ Testing │
│ System Design │
─────────┴────┬────────────┴─────
│
│ Your framework
│ (deep)
│
│ React / Swift /
│ Python / Go
│
▼
This is what makes you actually valuable. Not knowing 10 frameworks at a surface level. Knowing one deeply AND understanding the fundamentals that make all of them work.
"But What About My Resume?"
I hear this a lot. "If I don't know the latest framework, I won't get hired."
Let me tell you something. I've been on both sides of the hiring table. When I'm reviewing candidates, I don't care how many frameworks you list on your resume. I care about:
- Can you solve problems?
- Can you write clean, maintainable code?
- Can you learn new things quickly?
Point 3 is the key. If you have strong fundamentals, you can learn any framework in a couple of weeks. Employers know this. The ones worth working for, at least.
I'd rather hire someone who deeply understands HTTP, SQL, and one framework than someone who's "familiar with" React, Vue, Angular, Svelte, Solid, and Qwik but can't explain how a GET request differs from a POST.
The 30-Day Challenge
Here's what I'm proposing. For the next 30 days:
- Stop reading "X vs Y framework" articles. They don't help you. They create anxiety.
- Pick one fundamental topic per week. Week 1: HTTP. Week 2: SQL. Week 3: Git advanced. Week 4: Testing.
- Build something with your existing stack. Don't switch. Go deeper. Hit the walls, find the edge cases, learn how things actually work under the hood.
- When you see a new framework trending on Twitter, ignore it. It'll either stick around (and you can learn it later) or it'll be forgotten in three months.
The Counterargument
"But what if I miss out on the next big thing?"
You won't. If something truly changes the industry, you'll have plenty of time to learn it. React didn't replace jQuery overnight. Swift didn't replace Objective-C overnight. These transitions take years.
And when the transition does happen, developers with strong fundamentals adopt faster than developers who only know framework-specific patterns. Because they understand WHY the new framework exists, not just HOW to use it.
Final Thought
The developers I admire most aren't the ones who know every framework. They're the ones who can pick up any codebase and understand it. Who can debug any system because they understand the fundamentals. Who build things that work and last, regardless of what framework they're using.
That's the goal. Not framework expertise. Problem-solving expertise.
Stop running on the treadmill. Start building a foundation.
If you found this useful, I share more stuff like this on Telegram and sell developer toolkits on Boosty.
Top comments (0)