These days, developer experience (DX) is often the strongest case for using JavaScript frameworks. The idea is simple: frameworks improve DX with abstractions and tooling that cut boilerplate and help developers move faster. The tradeoff is bloat, larger bundles, slower load times, and a hit to user experience (UX).

But does it have to work like that? Do you always have to trade UX for DX? And are frameworks really the only path to a good developer experience?

In a previous article on anti-frameworkism, I argued that modern browsers provide APIs and capabilities that make it possible to create lightweight websites and applications on par with JavaScript frameworks. However, the DX question still lingers. This post addresses it by introducing web interoperability as an alternative way to think about frontend DX, one that prioritizes reliability, predictability, and stability over abstractions and tooling.

The origins of developer experience

The term DX has been preceded by two experience-related expressions: ‘user experience,’ coined by Don Norman in 1993 while working at Apple, and ‘experience economy,’ introduced by B. Joseph Pine II and James H. Gilmore in their 1998 Harvard Business Review article “Welcome to the Experience Economy.”

“Developer experience” builds on that same line of thinking. The term was first introduced by Jürgen Münch and Fabian Fagerholm in their 2012 ICSSP paper Developer Experience: Concept and Definition. As stated in the abstract:

As the quote suggests, DX was shaped in the image of UX, aiming to capture developer behavior and sentiment in ways that drive productivity.

Initial adoption of the DX paradigm

While developer productivity can be measured with quantitative metrics such as deployment frequency, delivery speed, or bugs fixed, developer experience attempts to quantify feelings through surveys, rating scales, sentiment analysis, or other qualitative methods. This makes DX inherently difficult to define.

Cognitive dissonance

The DX paradigm gives developers a dual role, which creates two conflicting demands:

• Objective demand – “I’m the creator of code and have to deliver working code fast.”
• Subjective demand – “I’m the consumer of developer tools and must feel good about my experience.”

Since developers are assessed both objectively and subjectively, a kind of cognitive dissonance emerges. By elevating developer sentiment as a core productivity signal, the DX paradigm encourages a mindset where even minor friction points, writing a few extra lines, reading docs, and understanding architecture get reframed as problems that degrade developer experience.

Tool overload

With every bit of friction labeled a DX problem, the default response becomes more tooling. As developer experience gets continuously measured, every issue is surfaced and logged, and the market is quick to step in with something to solve it.

To be fair, tool overload was also fueled by technical necessities. As Shalitha Suranga explains in his article “Too many tools: How to manage frontend tool overload,” frontend development fundamentally shifted around 2015. This was when ECMAScript began annual releases after years of ES5 stability, but browsers couldn’t keep pace, requiring polyfills and transpilers. Meanwhile, single-page applications (SPAs) emerged to compete with native mobile apps, popularizing frameworks such as React and Angular that required build tools by default, unlike earlier JavaScript libraries such as jQuery. TypeScript adoption further accelerated this trend, requiring additional tools.

These technical pressures coincided with the rise of the DX culture, which framed developer feelings and perceptions as productivity metrics. Developers had to address both expectations simultaneously, and they did so by continuously adding tools.

Decision fatigue

This was the point when decision fatigue set in. The growing complexity, increasing dependencies, and steeper learning curves turned out to harm developer experience, the very thing the tools intended to improve in the first place. The tools meant to solve DX problems were starting to create new ones.

The era of maintenance hell

The initial optimism started to fade. Developers had all the tools they wanted, yet they were getting tired.

Cognitive dissonance

Cognitive dissonance intensified. Developers now faced a harder contradiction: they had to maintain increasingly complex tooling while simultaneously avoiding burnout. Their dual role was getting worse:

• Objective demand –“I have to maintain the complex tooling.”
• Subjective demand – “I must avoid fatigue and burnout so I can still report a good experience.”

Tool overload

Not surprisingly, tool overload continued. The solution to complexity was more tools to manage the previous tools. Developers sought better dependency managers, migration tools, and documentation systems. Old dependencies needed constant updates, but each migration introduced new legacy code.

Decision fatigue

Decision fatigue compounded, since constant migrations and hunting for tools to manage the issues created by previous tools were exhausting, and refactoring became endless. Developers now faced a deepening analysis paralysis: which framework, which build tool, which state management library? Every decision carried migration risk, learning overhead, and technical debt.

The acute phase

This is where we are now. Abstractions and tools, meant to improve developer experience, have become the problem.

Cognitive dissonance

By now, cognitive dissonance has become acute. These days, developers must maintain bloated projects that no one fully understands while still reporting good DX. The contradiction has deepened:

• Objective demand – “I must hold this overblown project together.”
• Subjective demand – “I must avoid despair and have a good experience.”

Tool overload

Tool overload has its own breaking point. Today, codebases are stitched together with layers of tools managing other tools, dependency managers for dependencies, migration scripts for migrations, and documentation systems for documentation. Each fix ends up adding another layer of complexity.

The decision point

This is where things reach a decision point. The question now is whether we keep adding more tools to manage the growing complexity, or step back and admit the loop itself is the problem.

Visualized as a loop, it looks something like this:

How to get out of the loop?

Since DX is qualitative rather than quantitative, we can redefine it by changing how we think about it. This is both the root of the problem and the key to the solution. The framework-first approach promised less boilerplate, faster delivery, and more streamlined workflows. While the boilerplate reduction is real, so are the cognitive dissonance, tool overload, and decision fatigue.

In programming, there are several ways to exit an infinite loop. You can break out of it, throw an error, or kill the process entirely. But the cleanest exit is the most fundamental one; modify the condition that keeps it running.

The DX loop runs on the assumption that developer experience is best improved by third-party abstractions. As long as that evaluates to true, the loop continues. The way out isn’t another tool but to change the condition itself.

The antidote to framework fatigue: Web interoperability

While we were chasing the next shiny tool, web browsers were quietly improving native APIs and closing the gap between different browser engines. Web interoperability has silently entered the scene and created the opportunity for a different kind of DX. One built on consistency, stability, and reliability instead of abstractions provided by frameworks and tools.

For many years, browser fragmentation was a constant source of frustration. The same code behaved differently in Chrome, Firefox, and Safari, forcing developers to write workarounds or rely on abstractions to smooth over the differences. This gap has been significantly narrowing in recent years, and this is not by accident. Since 2022, all major browser vendors (Apple, Google, Microsoft, and Mozilla, alongside Bocoup and Igalia) have been collaborating on the annual Interop project, coordinating improvements to inconsistent browser implementations.

The overall Interop score, which measures the percentage of tests that pass in all major browser engines simultaneously, reached 95% in 2025. Relying on native platform APIs is no longer a gamble, which means the DX loop can be upgraded.

Cognitive coherence

As web interoperability becomes a reality, the dual role of developers naturally starts to align:

Objective demand – “I’m the creator of code and have to deliver working code fast.”
Subjective demand – “I’m the user of web APIs and must feel good about my experience.”

This alternative approach to developer experience replaces third-party frameworks, libraries, and developer tools with native web APIs. In this way, reliability, predictability, and stability become the source of good experience, and DX no longer depends on a never-ending tool churn.

Tool simplicity

When the need for abstractions diminishes, so does the pressure to add more tools. With native web APIs as the foundation, the toolchain shrinks naturally because the underlying need for abstraction layers diminishes. The tools we no longer need include frameworks, component libraries, transpilers, complex build pipelines, and many others.

By moving away from a framework-first approach to a platform-first one, development requires little more than a code editor, a linter, and a local dev server. Production may add a lightweight build step for minification, but without any framework-specific toolchain.

Decision clarity

Fewer tools mean fewer decisions, too. Without a constantly shifting toolchain, deciding which framework, build tool, or state management library to use no longer causes analysis paralysis.

Accumulating complexity doesn’t hinder productivity and turn developer experience into frustration and fatigue anymore. Development becomes predictable, and this predictability is what makes good experience sustainable.

This is what the upgraded DX loop looks like:

When frameworks still add value

While web interoperability redefines developer experience, it doesn’t make all abstractions obsolete overnight. Frameworks still have some advantages that platform-first development needs to catch up with.

However, there’s one thing worth noting: frameworks such as React also run on the same web APIs, so they benefit from interoperability improvements as well.

Reactivity and state

Frameworks offer mature, ergonomic solutions for reactivity (i.e., automatically updating the UI when data changes) and state management (i.e., sharing and tracking data across components). As the web platform doesn’t have a native answer here yet, this remains the most significant area where frameworks still add value.

In practice, this means two options when developing on the web platform: writing more boilerplate using native APIs such as Proxy (the native building block for reactivity) and EventTarget (the native publish/subscribe mechanism), or reaching for a lightweight, platform-friendly library, which is still tooling, but significantly less of it. Lit is the most prominent example of the latter, as it sits directly on top of Web Components standards and adds reactivity in around 5 KB.

Component ecosystems

The breadth of ready-made components for popular frameworks such as React, Vue, or Angular is still unmatched.

However, the Web Component ecosystem is growing. Salesforce built its platform UI on Lightning Web Components (LWC), Adobe ships Spectrum Web Components as the design system behind its Creative Cloud products, and Web Awesome (previously known as Shoelace), a framework-agnostic component library, raised $786,000 on Kickstarter.

Web Awesome’s creator, Cory LaViska, switched to web standards after discovering the component library he’d built for Vue 2 wasn’t compatible with Vue 3, leaving him unable to upgrade, a story that illustrates the biggest advantage of web-standards-based components: they work everywhere, without that kind of migration risk.

Documentation and community

The volume of community knowledge around frameworks is hard to match. You’re more likely to find documentation, learning materials, and community support for React and other popular frameworks than for native web APIs. AI coding tools also default heavily to frameworks because that’s what most of their training data contains.

Improving platform-first knowledge requires deliberate effort. The web-native ecosystem grows exactly as fast as its community decides to grow it. You can help the shift by writing tutorials and articles, posting them to your blog or developer-focused social media such as Dev.to or Hashnode, making videos, creating demos and example apps, building new Web Components libraries or extending the existing ones, and starting communities.

The industry is ill, but healing is possible

Right now, we’re experiencing an industry-wide mental health crisis characterized by cognitive dissonance, tool overload, and decision fatigue. While the framework-first era solved real problems at a time when browsers were fragmented and inconsistent, the solution outlasted the problem. The accelerating DX loop is the result of the assumption that developer experience is best served by third-party abstractions, and for a while, it was even true.

However, healing is possible. Browsers have become interoperable in the meantime, and that changes the condition the loop runs on. The upgraded loop redefines developer experience based on reliability, predictability, and stability.

Now, look at your hands. You’re already holding the medicine. Planning a new project? Start without a framework, and keep the toolchain minimal. Already in one? You can still contribute to the platform-first ecosystem by creating Web Components, demos, and tutorials, and spreading the word about an alternative approach to developer experience where cognitive coherence, tool simplicity, and decision clarity replace the old loop.