I spent the better part of Tuesday afternoon watching a junior engineer struggle to center a button within a nested stack of proprietary component libraries. It was a masterclass in modern absurdity: we have built a digital skyscraper out of toothpicks and glue, then wondered why the windows won’t open. The prevailing winds in our industry suggest that "using the platform"—relying on the native capabilities of the browser—is a quaint, regressive hobby. Instead, we have outsourced our architectural integrity to a rotating door of frameworks that promise speed but deliver bloat.

We are currently living through a crisis of over-engineering. The argument for these behemoth tools is always the same: they provide a unified developer experience. But let’s be honest about whose experience we are prioritizing. We aren't building for the user, who suffers through massive JavaScript bundles and jagged layout shifts. We are building for the convenience of the developer’s resume. We have traded the enduring stability of web standards for the dopamine hit of a new syntax.

The irony is that the browser has caught up. The features we once needed thousands of lines of code to simulate—state management, scoped styling, complex layouts—are now baked into the engine itself. Yet, the momentum of the framework ecosystem is a powerful drug. When you are inside the room of a major tech firm, the pressure to adopt the latest industry standard is immense. To suggest that we could simply use vanilla components is treated as a heresy, a sign that you aren't a "serious" engineer.

This is a failure of leadership as much as it is a failure of craft. We have allowed the tooling to become the product. When I look at the current landscape, I see a generation of developers who can navigate a complex state library but couldn't tell you how a browser actually renders a DOM node. This creates a fragile ecosystem where the knowledge base is shallow and the dependencies are deep. If the specific framework you rely on falls out of fashion or stops being maintained, your entire product becomes a legacy liability overnight.

It is time to stop hiding behind the abstraction. The platform is not a limitation; it is the most stable foundation we have. We need to stop treating native APIs as a fallback and start treating them as the primary tool. The true mark of a senior engineer shouldn't be how well they can manage a package manager, but how little code they need to write to solve a problem. The web was designed to be resilient, accessible, and fast. If your development stack makes it none of those things, you aren't innovating—you're just making a mess.