342 JavaScript frameworks were created between 2020 and 2025, according to a (possibly satirical, possibly accurate) tracking project on GitHub. In that same period, HTTP added zero new methods. CSS gained container queries, cascade layers, native nesting, and the :has() selector. And vanilla JavaScript became so capable that entire categories of third-party libraries became unnecessary.
The frameworks change constantly. The platform evolves gradually. And most developers I meet — including, until recently, myself — know the frameworks intimately and the platform barely at all.
The Abstraction Trap
I built React applications for three years before I could properly explain the CSS box model. I used TypeScript daily but would've struggled to write a clean JavaScript class without type annotations. I deployed to Vercel without understanding what a CDN actually does or why my cache invalidation sometimes didn't work.
I was a framework developer, not a web developer, and the distinction became painfully clear the first time I encountered a problem the framework couldn't solve.
It was a layout bug. A specific combination of flex containers and overflow handling that produced different results in Chrome and Safari. Styled-components (my CSS tool at the time) couldn't explain what was happening because the issue was in CSS itself — how different browsers interpret the flex specification's edge cases. I spent four hours on what, in retrospect, required understanding about twenty lines of CSS specification.
After that, I started going back to basics. Not abandoning frameworks — using them with understanding of what they're abstracting, so that when the abstraction leaks (and all abstractions leak), I can diagnose the underlying issue rather than desperately searching Stack Overflow for someone who had the exact same bug with the exact same framework version.
CSS: The Most Disrespected Powerful Technology
CSS gets an astonishing amount of disrespect from developers who control everything they see on screen using it. I think this is partly because CSS has a learning curve that's shaped like a wall (easy to start, suddenly complex), and partly because modern tooling makes it possible to avoid writing CSS directly — Tailwind, styled-components, CSS modules, component library defaults.
But CSS in 2026 is a dramatically different technology from CSS in 2015. Container queries mean components can respond to their container's size rather than the viewport — genuinely revolutionary for component-based architectures. The :has() selector is a parent selector that developers begged for since approximately the invention of CSS. Native nesting eliminates one of the primary reasons people used Sass. Scroll-driven animations replace entire JavaScript scroll libraries with a few CSS properties that perform better.
I spent a month rebuilding a side project using only modern CSS — no JavaScript framework, no utility classes, no build step. It was humbling and clarifying. A responsive layout that previously needed a ResizeObserver and React state now worked with three lines of container query CSS. An animation requiring a scroll library was replaced by native scroll-driven CSS that was smoother and used zero JavaScript.
If the last time you seriously engaged with CSS was the Flexbox era, you're working with an outdated mental model of what CSS can do.
HTTP: The Protocol Nobody Reads About
Quick: what's the difference between a 301 and a 302 redirect? What does the Cache-Control header actually control? When does a browser send a preflight OPTIONS request, and what determines whether CORS allows the subsequent actual request?
If you hesitated on any of those, you're building on a protocol you don't fully understand. And that's fine for routine development — until something breaks, at which point understanding HTTP becomes the difference between a 15-minute fix and a four-hour debugging session.
CORS errors are the classic example. Junior developers treat CORS as a mysterious force that randomly blocks API calls. It's not random — it's a security mechanism with well-defined rules based on Origin headers, allowed methods, and credential handling. Understanding those rules makes CORS errors trivially diagnosable. Not understanding them makes every cross-origin API integration a potential multi-hour struggle.
From my experience, a solid understanding of HTTP is more durable career investment than learning any specific API framework. Express.js might be replaced. HTTP has been around since 1991, and the fundamentals haven't changed.
The Web Stack You Should Actually Understand
Think of web development as layers. At the bottom: HTTP (how data travels). Then HTML/DOM (how pages are structured). Then CSS (how they're styled and laid out). Then JavaScript (how interactivity works). Frameworks sit on top of all of this.
Most developers learn from the top down — framework first, then whatever underlying knowledge is necessary to use the framework. The problem with top-down learning is that your understanding has gaps wherever the framework didn't need you to understand. And those gaps are exactly where bugs hide.
Learning from the bottom up — understanding each layer before building on top of it — is slower initially but produces more robust understanding. A developer who understands the DOM doesn't need to memorize React's rules about rendering — they follow logically from how the DOM works. A developer who understands CSS layout doesn't need to debug with trial-and-error — they can reason about why a specific layout behaves as it does.
A Practice That's Changed My Development
I build one small project per month using vanilla JavaScript. No React. No TypeScript. No build step. Just an HTML file, a CSS file, and a script tag.
Last month's project was a real-time image editor using Canvas API and Web Workers. No external libraries, no server-side processing. It runs offline (Service Workers), the total JavaScript payload is under 15KB, and it handles image operations that most developers would default to importing a third-party library for.
Compare that to a typical React application, which ships 150-200KB of framework code before a single line of business logic. The vanilla version is ten times smaller, loads instantly, works offline, and required understanding five browser APIs that I previously knew only by name.
These projects aren't portfolio pieces — they're exercise. They keep my fundamentals sharp and remind me what the web platform actually provides versus what frameworks provide. Often, the platform provides more than I expected, and the framework provides less than I assumed.
Frameworks Are Tools, Not Identities
The job title "React Developer" bothers me, though I've had it on my LinkedIn. React is a library. It's a tool. Calling yourself a "React Developer" is like a carpenter calling themselves a "DeWalt Developer" — it elevates the tool over the craft.
The best developers I've worked with don't identify with their tools. They're web developers who use React when React makes sense, use vanilla JS when that makes sense, and are prepared to use whatever comes next because they understand the platform those tools are built on.
Frameworks will keep changing. The fundamentals — HTTP, HTML, CSS, JavaScript, browser APIs — will keep being the foundation that everything else rests on. Learning the foundation isn't as exciting as learning the latest framework. But it pays compound interest for an entire career, while framework-specific knowledge depreciates with every major version.
I'd rather be a developer who happens to use React than a React developer who happens to make websites. The distinction is subtle, and it's everything.
Comments (0)
Be the first to share your thoughts on this article.