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
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 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.
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.
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.
We use web components at the hook for my company's advertising code but I've found them pretty thoroughly disappointing, personally. They make it simple to trigger code execution but their API isn't really that good
This has been soooooooo long in the making, i remember playing with webcomponents for personal stuff years ago when i didn't care about compat. Good to see mainstream libraries finally picking it up
12 years I’ve been saying this… 12, damn, years. React graduates look at me crazy. Angular devs say it’s not needed anyway. Svelte bros say get bent. I’m so happy that someone is paying attention.
You don’t need a shadow dom, you don’t need rerendering of everything when a simple value changes. You simply need web components and scoped js/ts with vite or whatever rollup you use.
I remember toying with Polymer circa 2014, for some reason the word "transclusion" jumps into my mind, I remember being excited about it at the time. I barely remember what it means today though.
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.
Worried about money? They are already rich beyond their wildest dreams. They are, reasonably, excited about growing and expanding and building a company that does much more, but that is not driven by a need for money, it is driven by their ambition.
edit: I can’t speak for Adam etc., this is just my impression. My impression is that they want to build a business of which tailwind (the open source project) is one part. I think that regardless of money in the bank they would want to have revenue generating projects. Laravel is a good comparable.
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.
With so many frameworks out there it's infeasible to build custom wrappers for them all. With web components they can build once, and work everywhere. It's only up to the frameworks to make sure they have great web components support (which just means great HTML support).
Vue has great web component support. Even React 19 (finally!) does.
Web components are a mess but this is a great application of them: shipping reusable components that work in all frameworks. It's the one and only killer application of web components.
Frankly I'm surprised they're marketing this as "for vanilla javascript" and not as a "now supports all frameworks" type positioning.
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.
Thanks! It's a paid feature because we just spent around $250,000 developing the library. Couldn't have built it if we were just going to give it away and maintain it forever for free, our engineers are talented people and deservingly well-paid.
It's funny because they're unintuitive to their end users. However, that is deliberate - they are looking for a decision point that comes after, but not too long after, devs have heavily invested in the product.
Yeah this seems like an odd thing to paywall. In the web dev world where everything is free, it's a pretty crazy ask to ask people to tie themselves to a UI framework where I guess you're forever paying a subscription just to continue using the framework?
It's like putting if postgres expected you to pay them a monthly fee.
edit: I see now their pricing is one-time perpetual access. Still, I'm genuinely curious how well this model works.
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.
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:
The wordiness is a common complaint but TBH it's a minor issue, I do have a growing problem with using tailwind that's hidden just behind that superficial complaint though.
px-3, py-2, bg-red-400 etc. are everywhere in tailwind code and they become more or less undocumented conventions. Technically you can configure them, but practically without unintended side effects on an existing project? And if you make extensive config changes, have you just locked yourself out of the ecosystem?
I don't use bootstrap, but from a brief look at the documentation it seems much more reasonable to diverge from defaults. Looking at themes (https://themes.getbootstrap.com/) it seems more flexible than an average tailwind setup.
which is even better than what Bootstrap provides since you get type safety for component props (and more opportunities for customization than what Bootstrap allows)
I've been working with TW more lately and I must admit - there is a convenience factor there that is really nice - and it abstracts a lot of the finicky design system thinking.
But, if you're building any long-term product, investing in your own design system + component library will put many many more miles on the board in terms of DX, flexibility, aesthethic language, dependency footprint, etc.
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 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.
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.
[+] [-] ricardobeat|7 months ago|reply
[+] [-] gloosx|7 months ago|reply
[+] [-] AstroBen|7 months ago|reply
[+] [-] emmanueloga_|7 months ago|reply
[+] [-] jt2190|7 months ago|reply
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”.
[+] [-] Brajeshwar|7 months ago|reply
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
[+] [-] tomnipotent|7 months ago|reply
[+] [-] monkey_monkey|7 months ago|reply
[+] [-] philipp-spiess|7 months ago|reply
I doubt that changes your mind, though.
[+] [-] mmcnl|7 months ago|reply
[+] [-] oleggromov|7 months ago|reply
[+] [-] davidw|7 months ago|reply
[+] [-] timeon|7 months ago|reply
[+] [-] gnarbarian|7 months ago|reply
[+] [-] Marciplan|7 months ago|reply
[+] [-] judah|7 months ago|reply
Nice to see devs picking up web components.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
[+] [-] shortrounddev2|7 months ago|reply
[+] [-] cchance|7 months ago|reply
[+] [-] reactordev|7 months ago|reply
You don’t need a shadow dom, you don’t need rerendering of everything when a simple value changes. You simply need web components and scoped js/ts with vite or whatever rollup you use.
[+] [-] hyperbolablabla|7 months ago|reply
[+] [-] abtinf|7 months ago|reply
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.
[+] [-] abxyz|7 months ago|reply
edit: I can’t speak for Adam etc., this is just my impression. My impression is that they want to build a business of which tailwind (the open source project) is one part. I think that regardless of money in the bank they would want to have revenue generating projects. Laravel is a good comparable.
[+] [-] combyn8tor|7 months ago|reply
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.
[+] [-] ayhanfuat|7 months ago|reply
[+] [-] spankalee|7 months ago|reply
With so many frameworks out there it's infeasible to build custom wrappers for them all. With web components they can build once, and work everywhere. It's only up to the frameworks to make sure they have great web components support (which just means great HTML support).
[+] [-] skrebbel|7 months ago|reply
Web components are a mess but this is a great application of them: shipping reusable components that work in all frameworks. It's the one and only killer application of web components.
Frankly I'm surprised they're marketing this as "for vanilla javascript" and not as a "now supports all frameworks" type positioning.
[+] [-] dawnerd|7 months ago|reply
[+] [-] croes|7 months ago|reply
[+] [-] bikeshaving|7 months ago|reply
[+] [-] gavinray|7 months ago|reply
TailwindCSS itself is meant to be nothing more than a styling tool, like Bootstrap...
[+] [-] adamwathan|7 months ago|reply
[+] [-] benatkin|7 months ago|reply
It's funny because they're unintuitive to their end users. However, that is deliberate - they are looking for a decision point that comes after, but not too long after, devs have heavily invested in the product.
[+] [-] hbn|7 months ago|reply
It's like putting if postgres expected you to pay them a monthly fee.
edit: I see now their pricing is one-time perpetual access. Still, I'm genuinely curious how well this model works.
[+] [-] bitbasher|7 months ago|reply
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 ~_~
[+] [-] Imustaskforhelp|7 months ago|reply
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.
[+] [-] rafram|7 months ago|reply
Well, yeah, because they added an `<el-command-palette>` that specifically does that.
[+] [-] gedy|7 months ago|reply
[+] [-] DimmieMan|7 months ago|reply
px-3, py-2, bg-red-400 etc. are everywhere in tailwind code and they become more or less undocumented conventions. Technically you can configure them, but practically without unintended side effects on an existing project? And if you make extensive config changes, have you just locked yourself out of the ecosystem?
I don't use bootstrap, but from a brief look at the documentation it seems much more reasonable to diverge from defaults. Looking at themes (https://themes.getbootstrap.com/) it seems more flexible than an average tailwind setup.
[+] [-] nettlin|7 months ago|reply
[+] [-] unknown|7 months ago|reply
[deleted]
[+] [-] joduplessis|7 months ago|reply
But, if you're building any long-term product, investing in your own design system + component library will put many many more miles on the board in terms of DX, flexibility, aesthethic language, dependency footprint, etc.
[+] [-] unknown|7 months ago|reply
[deleted]
[+] [-] unknown|7 months ago|reply
[deleted]
[+] [-] unknown|7 months ago|reply
[deleted]
[+] [-] jlukic|7 months ago|reply
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
[+] [-] megaman821|7 months ago|reply
[+] [-] dandano|7 months ago|reply
[+] [-] jaesonaras|7 months ago|reply
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.
[+] [-] paranoidxprod|7 months ago|reply
I know Lit is used a lot but I’m always looking for new approaches.
[+] [-] gnarbarian|7 months ago|reply