I'm going to say something that might sound a little heretical for a developer who builds courses about a JavaScript framework: I don't really trust frameworks anymore. Not the way I used to.
Let me explain what I mean, because I'm not saying don't use them. I use them every day. I'm saying, don't trust them. There's a difference.
Quick context, because where this is coming from matters. I've spent most of my career betting on frameworks and getting extremely good by going deep on one at a time. First it was WordPress. Sponsored by Yoast for years.
My code lives in WordPress core and Gutenberg. I led the performance team, and I led the migration of WordPress's end-to-end tests to Playwright. Then it was Svelte and SvelteKit.
I built a six-figure agency on that stack, ran it for two years, and still maintain a course about it. Now I'm going all in on AI tools, in every form I can find.
So this isn't the take of someone who never picked a side. It's the take of someone who's picked three.
When I was younger in this career, I treated frameworks like they were the floor. Solid ground. The thing you build on top of. If a framework said something was the right way to do it, I assumed it was the right way to do it, and I shaped my code to fit. If the framework changed its mind in the next major version, I changed my mind too. I was, in retrospect, a religious convert.
I'd argue with people online about why my framework was better than their framework, as if any of it actually mattered.
What changed? A few things. The first was that I shipped enough projects to start seeing the same problems show up in every framework I touched. Different names, different APIs, but the same underlying issues. Suddenly the surface-level differences felt like marketing.
The second thing, and this one took longer, was that I watched a few frameworks I'd bet on quietly stop being maintained. Not all at once. Just a slow fade. The release notes get shorter. The Discord gets quieter. The maintainers move on, which they're allowed to do, because they were never your employees.
And one day you realize you've built your business on top of a thing that's drifting toward a rock, and you're the one steering now.
So now when I evaluate a framework, I ask different questions than I used to. I don't ask: is this elegant? I don't ask: does this have a great DX? I ask: what does my code look like underneath this?
Because the framework is a suit, and one day I'm going to take it off, and what's left is the body of work I actually built. If the framework disappeared tomorrow, would my code still make sense? Could I port it? Could I read it?
If the answer is yes, the framework is doing its job. It's a tool. It's helping me move faster without taking ownership of my thinking. If the answer is no, if my code only makes sense when wrapped in a specific framework's idioms, if my business logic is tangled up with their conventions, if I can't even describe what my app does without invoking their vocabulary, then I've made a mistake. I've let the tool become the floor. And the floor is moving.
The hard part is, frameworks want you to do this. They want you to go all in. The whole pitch is: stop thinking, we've thought about it for you. And honestly, sometimes that's exactly the deal you want. When I'm prototyping, I want to stop thinking. When I'm writing a course, I want clear, opinionated paths so people aren't drowning in choices. Frameworks are great for that.
But for the parts of an app that actually matter, like the data model, the business rules, the things that would still be true if you rewrote everything from scratch tomorrow, keep them yours. Keep them in plain functions. Keep them in code that doesn't import from anywhere fancy. Treat the framework like glue, not structure. Glue is replaceable. Structure is forever.
I know this sounds like I'm telling you to write boring code. I am. Boring code outlives interesting code. Boring code survives major version bumps and acquisition rumors and the slow death of Discord servers.
Boring code is the thing you'll thank yourself for in three years when the new hotness lands and everyone's panicking about migration paths.
This matters more now, not less. AI is getting absurdly good at code, and the cost of moving a codebase from one framework to another keeps dropping. What used to be a six-month port is starting to look like a long weekend. One more reason to focus on the parts that don't move: the data model, the business rules, the things that would still be true if you rewrote the whole thing tomorrow.
Those are the parts AI can carry across frameworks for you. The framework scaffolding around them isn't worth protecting.
So use frameworks. Love frameworks, even. But don't trust them. Trust your own code. Trust the parts you wrote on purpose, that you can defend without saying well, that's the framework way. Those are the parts that are actually yours.
Everything else is rented.