Fix Your DX in 2025: My Vanilla Web Component Journey

We didn't go all-in at once. We picked a small, universal, and notoriously tricky component to build: a modal dialog. Every project needed one, and they were always a pain to get right, especially concerning accessibility and stacking contexts.

Our first vanilla Web Component looked something like this (simplified for clarity):

class ModalDialog extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
    this.shadowRoot.innerHTML = `
      <style>
        :host {
          /* Styles for the modal container */
        }
        .scrim {
          /* Styles for the background overlay */
        }
      </style>
      <div class="scrim"></div>
      <div class="dialog">
        <slot name="header"></slot>
        <slot></slot> <!-- Default content -->
        <slot name="footer"></slot>
      </div>
    `;
  }

  // ...methods to open(), close(), etc.
}

customElements.define('modal-dialog', ModalDialog);
  

The first time we dropped <modal-dialog>Hello World</modal-dialog> into a plain HTML file and it just worked, it was a revelation. The styles were perfectly scoped. The logic was self-contained. We then dropped the exact same component file into a React project and a legacy jQuery page. It worked everywhere. This was the "aha!" moment. We weren't just building a component; we were building a durable digital asset.

What Actually Changed for Our Developers

Adopting this "Web Component-first" approach had a profound and immediate impact on our team's daily lives.

Onboarding in Hours, Not Days

A new developer joined the team a month into our experiment. Instead of a week of learning our bespoke React/Vue hybrid setup, we told them, "If you know HTML, CSS, and JavaScript, you can be productive today." They were. The component's interface was the HTML tag and its attributes. The documentation was the element itself. The barrier to entry had vanished.

Liberating Tooling and Blazing Builds

For local development on our component library, we often didn't need a build step at all. We just used a simple live-server extension in VS Code. Our CI/CD pipeline, which once groaned under the weight of transpiling and bundling a massive framework app, was now just running tests and copying a handful of JS files. Build times for our component library were measured in seconds.

Unbreakable Styles and Fearless Refactoring

Shadow DOM was the unsung hero. A developer could go into the <modal-dialog> component and completely refactor its internal styles, confident that they wouldn't accidentally break the button styling on the marketing site. This psychological safety made everyone more willing to make improvements and less afraid of the codebase.

It's Not a Silver Bullet: The Hurdles and Realities

Our journey wasn't without its challenges. Moving to Web Components isn't a panacea for all development woes.

State management is the big one. Web Components are great for self-contained UI, but for complex applications, you still need a way to manage shared state. We ended up using a simple pub/sub event bus for communication between components and a lightweight state library for one of our more complex apps. The key was that this was a conscious choice, not a default imposed by a framework.

Server-Side Rendering (SSR) can also be tricky. While Declarative Shadow DOM is making this much easier, it's not as mature as the SSR solutions in frameworks like Next.js or SvelteKit. For our public-facing, SEO-critical sites, we still use a framework for the 'shell' but populate it with our standard Web Components on the client side.

Finally, there's a bit more boilerplate to writing a vanilla component compared to the slick syntax of something like Svelte or Vue. We mitigated this by creating our own simple base classes, but libraries like Lit are a fantastic, lightweight option that provides helpful sugar without locking you in.

Our 2025 DX Verdict: A Breath of Fresh Air

Has our DX been fixed? Absolutely. We didn't throw away our frameworks—they still serve a purpose, especially for application routing and structure. But we shifted our foundation. We now build from the bottom up with durable, standard, and simple Web Components.

Our codebase is simpler, our builds are faster, our teams are more aligned, and our developers are genuinely happier. We've traded the churn of the framework-of-the-month for the stability of the web platform. In a world of ever-increasing complexity, this simplification has been the single greatest improvement to our developer experience.

If your team is feeling the framework fatigue, I urge you to give it a try. Pick one small, leaf-node component and build it with vanilla JavaScript. You might just be surprised at how liberating it feels to just build for the web.