Would love to know how they went about implementing these. I always find custom elements interesting. I know the guys over at data-star.dev used one to implement their inspector element, but unfortunately that is also behind pro.
I know Lit is used a lot but I’m always looking for new approaches.
This is a exciting use-case for custom elements, and probably how tailwind should have been implemented from the start, but it’s hilariously a paid feature?! (https://tailwindcss.com/plus#pricing) Intuitively, I’d expect the custom elements to be free and the framework integrations to cost money.
Tailwind is fine, but I do find it humorous that they discourage wrapping up tw classes into a component class ala Bootstrap, but they wrap html up like this:
Looks like it's done using standards-based web components[0]. The page says these components don't require any existing JavaScript framework; because web component support is built-in to the browser.
The world would be a significantly better place if someone could throw a small mountain of money at the Tailwind folks so that they can stop worrying about money and simply make the full tailwind experience freely available. There are so many lost opportunities for deep integration with other projects.
Kind of like how Jeff Bezos threw a bunch of money at 37signals at some insane valuation, which helped them completely avoid the VC trap.
This is the only feature I genuinely want available for tailwind free users too. Sounds really interesting and I can't even try this? That's a shame.
But I understand that funding open source is never easy & I still appreciate tailwind from the bottom of my heart simply because some might hate it for what it is, but I appreciate that I have options to being with (daisy,tailwind etc.)
If anyone who has ever contributed to open source is reading this. Thanks. I am a real frugal person but one day, I want to earn enough money that I can donate to you guys without hesitation and be an open source contributor too.
I am not a Tailwind user but I am a big fan of these "headless" web components. I have been using home-grown web components for tabs, modals, drawers, dropdown, tooltips, toasts and selects they implement functionality and accessibility with minimal styling. I use them across different projects and different solutions (Django templates, Vue, React, vanilla HTML) without any problems.
I just can't fathom how someone can look at this and think "yeahhhh thats some good clean code". How did tailwind get so popular? Learn plain CSS. It's really good now
I have a feeling that Tailwind started with a good intention to be a utility classes CSS framework, akin to “Bourbon on Steroids”, but people began to accept and use their prototype/sample/example codes way better than they had intended, and they ran with it.
I stumbled on Tailwind in 2018 and introduced it to a team looking to revamp a pretty massive project. I remember that the initial proposal I made was to treat it like Bourbon[1] and write classes that build on Tailwind’s utilities. That way, you can still have `.button`, `.button-primary`, and `.button-primary__accent` etc without the cryptic classes in the HTML.
However, after reading Tailwind, the team found it much easier to write the pre-built classes and stack them as they progressed. And it worked; if I don’t care about how the code is written, things were consistent. It reminds me of “Pixel Perfection” before the responsive design era, when things looked as designed in Photoshop and printed for clients during presentations.
We actually ended up adding the custom animation-specific data props to all dialog specific custom elements before the release, so the group-*/dialog is no longer necessary but I forgot to update the code in the post.
Before Tailwind, every web designer I’ve ever worked with invented their own version of this.
Yes, CSS in theory is powerful and has everything necessary to avoid using Tailwind, but in practice CSS has a major flaw: You’re almost required to build a semantic model to get the full power. But this ignores that designers are working with mood and emotion just as much as document structure and information architecture. Capturing these more nebulous concepts as logical semantic rules is very difficult if not impossible. Tailwind just codified what everyone already did: Skip the semantic dance (“Making that text bold would be really cool, but what does it mean to be cool, as a general rule?”) and just create semantic rules like “bold” and “red”.
I think Tailwind became popular because React doesn't have a good way to combine CSS and JSX in a single file, unlike Vue/Svelte which support single-file components. With Tailwind utility classes you can just add them to your JSX template. React problem solved.
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.
Put simply: if you’re using something like React, Vue, Svelte, whatever, then Web Components are strict overhead in terms of bundle size and runtime overhead. And when there’s impedance mismatch between the two worlds, which I hear is particularly common in React (can’t attest it personally, I don’t use React), you have to compromise on functionality or ergonomics, or else do fancier bindings, at which point why even bother with Web Components?
It will also commonly not play nicely with some more advanced aspects of the frameworks, like server-side rendering will probably suffer (depending on how exactly things are done).
In a world where React is dominant and you’re wanting to use React yourself, targeting Web Components just doesn’t make sense.
Then “headless” makes it worse. The more comprehensive implementations have a lot of overhead.
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 <script> 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 `<script>` 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 `<script>` tags given that, so am I just missing something?
I still can't justify using Tailwind. It's not that I don't like it, but I find CSS does everything I need and more, and I do some pretty complex styling and animations in CSS.
I just find that at some point, Tailwind gets in the way and I revert back to plain CSS. TW invariably then just becomes another style src in the HTML.
42 comments
[ 3.9 ms ] story [ 60.0 ms ] threadI know Lit is used a lot but I’m always looking for new approaches.
Well, yeah, because they added an `<el-command-palette>` that specifically does that.
Nice to see devs picking up web components.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
Kind of like how Jeff Bezos threw a bunch of money at 37signals at some insane valuation, which helped them completely avoid the VC trap.
But I understand that funding open source is never easy & I still appreciate tailwind from the bottom of my heart simply because some might hate it for what it is, but I appreciate that I have options to being with (daisy,tailwind etc.)
If anyone who has ever contributed to open source is reading this. Thanks. I am a real frugal person but one day, I want to earn enough money that I can donate to you guys without hesitation and be an open source contributor too.
edit:
Confirmed, they removed alpine from their copy/pastable code. Now you see:
<!-- Include this script tag or install `@tailwindplus/elements` via npm: -->
<!-- <script src="https://cdn.jsdelivr.net/npm/@tailwindplus/elements@1" type="module"></script> -->
This sucks because I have been using alpine and now I can't copy paste the examples ~_~
I stumbled on Tailwind in 2018 and introduced it to a team looking to revamp a pretty massive project. I remember that the initial proposal I made was to treat it like Bourbon[1] and write classes that build on Tailwind’s utilities. That way, you can still have `.button`, `.button-primary`, and `.button-primary__accent` etc without the cryptic classes in the HTML.
However, after reading Tailwind, the team found it much easier to write the pre-built classes and stack them as they progressed. And it worked; if I don’t care about how the code is written, things were consistent. It reminds me of “Pixel Perfection” before the responsive design era, when things looked as designed in Photoshop and printed for clients during presentations.
1. https://www.bourbon.io
I doubt that changes your mind, though.
Yes, CSS in theory is powerful and has everything necessary to avoid using Tailwind, but in practice CSS has a major flaw: You’re almost required to build a semantic model to get the full power. But this ignores that designers are working with mood and emotion just as much as document structure and information architecture. Capturing these more nebulous concepts as logical semantic rules is very difficult if not impossible. Tailwind just codified what everyone already did: Skip the semantic dance (“Making that text bold would be really cool, but what does it mean to be cool, as a general rule?”) and just create semantic rules like “bold” and “red”.
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.
It will also commonly not play nicely with some more advanced aspects of the frameworks, like server-side rendering will probably suffer (depending on how exactly things are done).
In a world where React is dominant and you’re wanting to use React yourself, targeting Web Components just doesn’t make sense.
Then “headless” makes it worse. The more comprehensive implementations have a lot of overhead.
https://next.semantic-ui.com/
Has Tailwind support out of the box, just had to mod oxide to get non threaded wasm support in the browser
https://next.semantic-ui.com/examples/tailwind
> Has Tailwind support out of the box, just had to mod oxide to get non threaded wasm support in the browser
have you checked unocss? might be more efficient.
- 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 `<script>` tags given that, so am I just missing something?
[1] https://github.com/muxinc/media-chrome
I just find that at some point, Tailwind gets in the way and I revert back to plain CSS. TW invariably then just becomes another style src in the HTML.