Unpopular Opinion: We’re repeating history by relying on bloated abstractions and forgetting the fundamentals. Modern frameworks? They’re the new jQuery, and we’re going to regret it.

Before you grab your virtual pitchforks, hear me out. I’ve been around the block a few times, and if there’s one thing I’ve learned, it’s that tech trends often loop back around, sometimes with a fresh coat of paint but the same old foundational issues.

And speaking of age, here’s a little nugget of truth: Frameworks age like milk. Only jQuery still works in IE6. Mic drop.

The Golden Age of jQuery (and Its Unseen Costs)

Remember jQuery? Oh, the halcyon days! It was JavaScript for the rest of us. It promised to simplify DOM manipulation, smooth out those nasty cross-browser inconsistencies, and generally make web development less of a pain in the… browser.

// jQuery back in the day: So simple, so elegant!
$('#myButton').on('click', function() {
    $('.message').slideToggle('slow');
});

Versus the vanilla JavaScript of the time:

// Vanilla JS (pre-modern APIs): A bit more verbose, a lot more "oh god, IE?"
document.getElementById('myButton').addEventListener('click', function() {
    var messages = document.querySelectorAll('.message');
    for (var i = 0; i < messages.length; i++) {
        // Imagine complex cross-browser animation code here. Yikes.
        messages[i].style.display = (messages[i].style.display === 'none' ? 'block' : 'none'); // Simplified
    }
});

jQuery was a godsend. It abstracted away the gnarly bits, and you could build interactive UIs with remarkable speed. But here’s the kicker: many developers only learned jQuery. They knew how to chain methods but had no clue how the DOM worked underneath, how events propagated, or what this meant in vanilla JavaScript.

Then came the performance concerns. The bloat. The “do I really need a whole library for this one thing?” questions. And eventually, native browser APIs caught up, making many of jQuery’s features redundant.

Enter the Framework Overlords

Fast forward to today. We have React, Angular, Vue, Svelte, and a dozen others popping up faster than you can say “build tooling.” They promise componentization, state management, declarative UIs, and developer happiness. And they deliver! To a point.

But look closely:

  • Bloat is back, baby! Sure, tree-shaking helps, but are you really shipping lean bundles when your node_modules folder weighs more than your grandma’s computer?
  • Abstraction layer upon abstraction layer. Remember learning HTML, CSS, and JS? Now you need to learn JSX, TypeScript, CSS-in-JS, state management patterns (Redux/Vuex/NGRX/Context API/Zustand/Jotai/Recoil/Pinia), bundlers (Webpack/Vite/Rollup), and a thousand plugins just to get a basic app off the ground.
  • The churn is real. Blink and there’s a new version, a new “best practice,” a new hot library that makes the last one obsolete. Keeping up is a full-time job.
  • The “magic” problem. Just like jQuery, these frameworks do a lot of “magic” for you. It’s fantastic until the magic stops working, and you have zero clue why, because you never learned the underlying JavaScript, or how the browser actually renders a page.

When something goes wrong with a deeply nested component or a mysterious re-render, you’re not debugging JavaScript. You’re debugging a framework’s interpretation of JavaScript, filtered through a bundler, possibly transpiled from TypeScript, and hoping you understand the particular lifecycle methods or hooks involved.

The Cycle of Abstraction: When Will We Learn?

We abstract to simplify. That’s good. But we’re also abstracting away fundamental knowledge. The more layers of abstraction we pile on, the further we get from the actual metal. This isn’t just about frontend; it happens everywhere in IT. Remember when people actually understood networking without just clicking through a wizard? Or building a server without clicking a cloud provider’s “launch instance” button?

The “we’ll regret this” part comes when:

  1. Performance hits: Your users are on mobile, and your framework-heavy site takes ages to load.
  2. Maintenance nightmares: A critical security vulnerability appears in a deprecated framework version, and your entire app is built on it.
  3. Hiring challenges: Finding developers who truly understand the underlying technologies, not just the framework du jour.
  4. The inevitable pivot: You realize your chosen framework isn’t suitable for a new requirement, but refactoring is a monstrous task because everything is tightly coupled to it.

The Path Forward: Fundamentals First, Tools Second

I’m not saying frameworks are evil. They’re powerful tools. But like any tool, they should be used judiciously.

Learn the fundamentals first:

  • HTML: Semantic HTML matters for accessibility and SEO.
  • CSS: Learn Flexbox, Grid, the cascade, and how to style components effectively without relying on an abstraction layer every single time.
  • JavaScript: Understand the DOM API, asynchronous operations, event loops, this, closures, prototypes (or classes), and how JavaScript truly works in the browser. Learn to build small, interactive pieces without any framework.

Once you have a solid grasp of these, then pick a framework. Understand why it does what it does, what problems it solves, and its trade-offs. Don’t just follow the hype. Use it as an accelerator, not a crutch.

Your code will be leaner, more performant, and you’ll be a far more capable developer when the next “new shiny” comes along. Because knowing HTML, CSS, and JavaScript is future-proof. Knowing only Framework-X isn’t.

So, let’s learn from history. Let’s build robust, performant web experiences by mastering the basics, and using frameworks as the valuable tools they are, not as a replacement for true understanding. What do you think? Am I just a grumpy old dev, or is there a kernel of truth in this unpopular opinion? What do you think?