The Framework Dilemma: Why I’m Building a Headless Web Component Library
Has this ever happened to you? You’re starting a fresh project and realize you have to switch frameworks because a new one simply fits the app’s requirements perfectly. You are excited, but then tragedy strikes — you realize you can’t use your favorite UI libraries anymore. (I’m looking at you, Shadcn UI lovers suddenly stranded outside the React ecosystem).
In my day job, I’m primarily an Angular developer. However, when it comes to my personal projects, I absolutely love using Astro. Sure, I know about Analog.js, which gracefully lets you use Angular inside Astro, but for this new venture, I wanted to explore a completely different path: Web Components.
Now, I know there’s a constant debate on social media. Are web components the ultimate modern solution, or are they a mistake of the modern frontend? In my opinion, there is a perfect use-case for every technology, and for this specific scenario, web components are brilliant. Why? Because they are truly framework-agnostic. And that thought is what pushed me to start building my own component library.
Going Deeper: The Headless Approach
But what if we dive a little deeper? What if, instead of just creating a standard web component library, I built a headless component library that could work with any framework?
Think along the lines of Base UI, but completely untethered from React, or something closer to Zag.js. Sounds pretty good, right?
Speeding Things Up with Tailwind and CVA
Continuing down this path, I decided to build all of this using Tailwind CSS and CVA (Class Variance Authority). Why? Because building everything from scratch as a solo developer takes a massive amount of time!
I know Tailwind can be a controversial topic, and there are developers who aren’t fond of it. But honestly, it helps immensely. When you’re trying to get a project off the ground, tools like Tailwind are lifesavers. They help you survive the initial grind and actually reach that coveted alpha version without burning out.
Choosing the Right Tool: Why Not Lit?
So, we’ve settled on web components — but what should we use to build them?
Get Andersseen’s stories in your inbox
Join Medium for free to get updates from this writer.
Lit? It’s honestly not a bad choice. In fact, I really liked that the JS Foundation adopted Lit after its time at Google; I saw that as a huge positive! However, the real turning point for me was seeing that Astro recently deprecated its official Lit integration. Since Astro is one of my absolute go-to frameworks, seeing Lit practically become obsolete within that ecosystem was a clear sign I needed to look elsewhere.
Obviously, the whole point of this project is to build a library that is truly framework-agnostic — so I’m not tied to any ecosystem at all. But realistically, as I build this, Angular and Astro are my guiding lights right now, and they naturally influence my technical decisions.
Enter Stencil JS. For me, Stencil is the perfect choice. I know Ionic has been facing tough competition from React Native in the hybrid mobile app space lately, but as a technology to generate web components, Stencil remains incredibly solid. And here’s the best part: as an Angular developer, Stencil’s Developer Experience (DX) feels very similar to Angular’s. It was an absolute match!
The Master Plan: Components as Game Objects 🎮
So, here is the core idea: generate a web component library using Stencil JS, styled with Tailwind via CVA and tailwind-merge.
But in parallel, I’m also building a purely TypeScript headless component library inspired by Zag.js and its state machines. As a passionate gamer who has previously tried to create a video game, I really love the idea of treating UI components almost like game objects with their own distinct states and behaviors.
Going Even Deeper: The Magic of Attributes
So, we have a solid base: web components built on headless logic that you can drop into plain HTML or Vanilla JS. But what if we added some quality-of-life attributes so we don’t end up with massive, overloaded HTML classes?
In one of my previous articles, I explored the idea of using specific attributes for styling layouts — an idea heavily inspired by Clarity Core. That approach worked out wonderfully for me, and I wanted to integrate that same mentality here.
This train of thought brought me to animations. We all use the same standard animations on our websites — fade-ins, zoom-outs, slide-ups. I’m not trying to compete with amazing tools like Motion.dev, but wouldn’t it be incredibly comfortable to just drop an attribute like and-motion="slide-up" and and-motion-trigger="enter" into your HTML and just have it work? No more repeating the same CSS for the hundredth time. At least, I know I would definitely use it!
Looking Ahead
And that brings me to where I am today. The main idea is to build something I find useful, but I would be absolutely thrilled if other developers found value in these libraries too.
It isn’t quite at the alpha stage yet, but it’s getting very close! If you want to follow along with my progress or check out the code, you can see the repository right here:
🚀 Check out and-web-components on GitHub
Let me know what you think of this approach in the comments! Are you using web components in 2026? Happy coding!
