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.
Vanilla JavaScript support for Tailwind Plus
91–100 of 202 posts
Re: Vanilla JavaScript support for Tailwind Plus
#92Earlier quoted context omitted.
But at what cost? If it’s not a CSS builtin, it’s going to use JS - it may not be something you care about, but it will be there. There’s no other way.
I believe it's regular old css. The :has() pseudo class. https://developer.mozilla.org/en-US/docs/Web/CSS/:has
Re: Vanilla JavaScript support for Tailwind Plus
#93Earlier quoted context omitted.
Type safety is good, but the class soup inside the components is just abysmal. And honestly, more often than not I see it spilling out of the components and onto the page layouts. Design tokens are the one Tailwind feature I genuinely like. Everything else – kill it with fire. Just use whatever scoped CSS your stack does ( in Svelte/Vue, Emotion in React?).
class soup is what tailwind is. It's terrible because is just abbreviations of css attributes which you still need to know because you'll inevitably fiddle around devtools trying things out. The only "smart" thing about it is leaning strongly on using rem. how can it spill out onto the page? it's inline css. The (rare) inline selectors target only descendants. Truth is that it's winning over because it works best wit…
Because people are lazy and don’t make a component for everything. And some people are even lazier and don’t make UI components at all. I’ve seen a project where there was a Button component and that’s it. Well, that was vibe coded probably so makes sense.
> Inline soup works better than looking for styling on different files in the context of the project, so here we are.
Only if you have a separate .css. If you do UI components with [insert your favourite CSS-in-JS solution], it stays in the same file. Maybe the proximity to markup within the file is important?
But no, Tailwind has been rising in popularity long before LLMs came along.
Re: Vanilla JavaScript support for Tailwind Plus
#94Lovely. Verbosity aside, now on top of knowing CSS you need to learn another hierarchical system within class names.
Re: Vanilla JavaScript support for Tailwind Plus
#95Re: Vanilla JavaScript support for Tailwind Plus
#96Tailwind 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: Options ... Bootstrap: Dropdown button ... (I realize you have full control over looks with TW, but Bootstrap and others have utility classes too for the common stuff.)
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 extensiv…
I find it very nice that you can re-theme or brand your app with virtually no code or class changes.
Re: Vanilla JavaScript support for Tailwind Plus
#97Lovely. Verbosity aside, now on top of knowing CSS you need to learn another hierarchical system within class names.
Re: Vanilla JavaScript support for Tailwind Plus
#98This 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 be…
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.
Re: Vanilla JavaScript support for Tailwind Plus
#99Looks 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. Nice to see devs picking up web components. [0]: https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
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.
Re: Vanilla JavaScript support for Tailwind Plus
#100Lovely. Verbosity aside, now on top of knowing CSS you need to learn another hierarchical system within class names.
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
This sort of thing is objectively ugly and takes a minute to learn. The advantages of this approach I found is two-fold
1. You can be more confident that the changes you are making apply to only the elements you are interested in changing
You are modifying an element directly. Contrast with modifying some class that could be on any number of elements
2. You can change things around quite quickly
Once you're well familiar with your toolset, you know what to reach for to quickly reach a desired end state