Vanilla JavaScript support for Tailwind Plus

Why not use the web inspector? That’s usually the quickest way to see which style is applied to an element.

How has shipping high quality products using AI generated tailwind components actually been working for you? I think the problem that I and many others have/had, is that it can certainly build a few components that look good in isolation, but it doesn’t do a good job at maintaining a cohesive theme/idea across many different page sections/components etc. I built blendful [0] to solve this, and sort of lost interest when LLMs became increasingly capable. However, seeing them not making any gains, really, on visual cohesion between sections and components provoked enough excitement to continue working on it this year.

We will see how long it takes for LLMs to make headway in this area specifically.

[0]: https://www.blendful.com

People would rather have to parse out a big dumb list of classes than look at the actual list of what properties affect something, with a clear ability to drill down into them. Its madness, akin to carpenters giving up hammers, preferring to use glue, because they hit their thumb a few times by accident

This is great. Last time I looked into this UI component world I was surprised the popular UI libraries weren't all 'headless' at their base. Web components have been around a long time now. What was stopping this approach?

There are so many framework specific libraries like shadcn, and the community set about building half finished conversions for different frameworks like Vue, which are always several iterations behind and don't really work properly. They have their own version of the docs and it all relies on a specific version of Vue and a specific version of Tailwind and whatever else. It's an abomination.

Start with headless UI as a base and then build wrappers for specific frameworks if you really feel the need. But the wrappers should be syntax sugar only and linked directly to the base library.

I'm sure it's all more complicated than that but a man can dream.

I love seeing a mainstream/popular project embracing web components. We've been working on a web components project for media players[1] for a while for the same reasons:

    Instead of being coupled to a specific JavaScript framework, these custom elements work anywhere you can use a  tag

But...React is still the elephant in the room here. Maybe TW is just in a different world if they're truly just anticipating folks using this via a `` tag, but if not, very curious how they're going to deal with some of the web component (WC) stuff we've dealt with, like:

- Despite signals/promises, React 19 didn't add full support for WC. React uses a diff algorithm for reconciliation. There are some rough edges for any "complex value" cases in the incomplete solution for 19's WC support with client vs server side rendering. This results in us being required to use 'use client' for parts of our component architectures, meaning WC providers aren't able to take full advantage of SSR.

- WCs are async loading, which in combination with React can have a negative impact on performance for things like core web vitals (and the dreaded cumulative layout shift).

- WCs are just different from React patterns. Each WC creates a DOM element, but React components don't have to, which just inherently means different shapes of code.

- React focus management libraries don't play nice with WCs. We've talked to multiple devs/companies that were excited about/using WCs that backed out because of cross-ecosystem complexities like this.

- React Native is, uh....a whole thing.

On a somewhat separate note...one of my complaints about TW historically has been that it feels like "just classes" (great!), yet requires a build step (oh...). I'm a little confused to see them leaning into `` tags given that, so am I just missing something?

[1] https://github.com/muxinc/media-chrome