Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vanilla JavaScript support for Tailwind Plus

tailwindcss.com

Post reply on HN
Print view View original

181–190 of 202 posts

Re: Vanilla JavaScript support for Tailwind Plus

#181

Post by owebmaster »

jlukic wrote: post #78

Working on a new version of semantic ui for authoring ui with web components and signals based reactivity without a compilation step. 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

This is the future of web development!

> 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.

Re: Vanilla JavaScript support for Tailwind Plus

#182

Post by Rapzid »

AstroBen wrote: post #97
ricardobeat wrote: post #67

Lovely. 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

I was a Tailwind skeptic for a long time but I've used it on a few projects now at my full discretion.

However I use it in a much more blended way than the authors probably prefer. I use it with Tailwind Variants and to quickly hack out components. However depending on the project, component, and etc I may also construct BEM-based CSS files to live along side the component.. I use "@apply" in the CSS files, something the author(s?) are on record saying they regret. However I'd counter them by saying if it weren't for "@apply" Tailwind wouldn't be where it is today..

Re: Vanilla JavaScript support for Tailwind Plus

#183

Post by Rapzid »

reactordev wrote: post #173
owebmaster wrote: post #149

Earlier quoted context omitted.

Which is a indication they might not know CSS that well.

I’m sorry but :has is new. 2023. Forgive this grey beard that built the world you know.

Baseline 2023 meaning all major browsers supported it in their latest versions sometime in 2023.. Like all new CSS stuff it's probably been a very long time coming. Everyone can't pay attention to everything though, regardless of their beard color.

Re: Vanilla JavaScript support for Tailwind Plus

#184

Post by murukesh_s »

gloosx wrote: post #119
ricardobeat wrote: post #67

Lovely. Verbosity aside, now on top of knowing CSS you need to learn another hierarchical system within class names.

Oh yeah, when I open a typical big project with Tailwind I always love to see some: Team Settings Manage your team permissions, invites, roles, and integrations here. Changes apply instantly across all team workspaces. Cancel Save Changes

This is like repeating code without using a function. If you have a nice abstraction - the same becomes cleaner like below.

  
    Team Settings
  
  
    Manage your team permissions, invites, roles, and integrations here. Changes apply instantly across all team workspaces.
  

  
    Cancel
    Save Changes

Re: Vanilla JavaScript support for Tailwind Plus

#185

Post by phatskat »

bernawil wrote: post #49
notpushkin wrote: post #29

Earlier 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…

> Truth is that it's winning over because it works best with LLMs. Inline soup works better than looking for styling on different files in the context of the project, so here we are.

I saw this on another recent tailwind thread and I’m not sure I agree. LLM might be helping adoption, but I’ve been seeing and using tailwind for years without really going near LLM coding

Re: Vanilla JavaScript support for Tailwind Plus

#186

Post by notpushkin »

bernawil wrote: post #167
notpushkin wrote: post #93

Earlier quoted context omitted.

> how can it spill out onto the page? it's inline css. 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 her…

[I'm assuming styled-components was the preferred css-in-js solution until recently] > If you do UI components with [insert your favourite CSS-in-JS solution], it stays in the same file. I mean you can but "best practice" all around has been to put them separate and that's reflected in the majority of github repos in the training data of the LLMs. > Maybe the proximity to markup within the file is important? that's m…

Yeah, I mean, with either Tailwind or styled-components you want to contain them to “UI components” – e.g. or . You could mix in some logic, and you’re right, looks like many styled-components folks will split it into two files then – but honestly I would just do in one.

Personally, I’m a Svelte fan, and I think they got it right – you just write in your component and that’s it. I think Vue works in a similar way, too.

Re: Vanilla JavaScript support for Tailwind Plus

#187

Post by [deleted] »

MrJohz wrote: post #136
luckylion wrote: post #129

Earlier quoted context omitted.

That doesn't affect the parent (.group) based on the child though.

No, but `group` doesn't affect the parent in Tailwind. You put `group` in the parent to mark it, and then use the `group/...` syntax to apply different properties to the child, depending on the different states of the parent. This doesn't require `:has`. I don't think Tailwind has a built-in `:has` tool, but I suspect it would be easy to add one as a custom class.

[deleted]

Re: Vanilla JavaScript support for Tailwind Plus

#188

Post by sensanaty »

elktown wrote: post #151
Jaygles wrote: post #100

Earlier quoted context omitted.

I've worked in many different FE codebases with a variety of CSS "strategies". 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…

When people complain about CSS being hard I'm not sure what parts of it really? It's rarely explained further too. As someone that did a lot of CSS like 15 years ago when fullstack was the norm, then just sporadically for various non-public tooling, is that yes, the old ways of trying to position things really sucked and had a lot of hacks and some of those trail-n-error "how-does-this-change-the-elements-position" s…

The hard part isn't just placing the correct styles, that is trivially learnable, it comes in when you have multiple people touching the same code, or even in small teams with a large enough project. In a large enough project, and IME that "large enough" point gets hit very quickly, things become messy and it becomes difficult to figure out why something is rendering in the way it is.

Every non-tailwind project I've ever worked on inevitably devolved into a mess where you have 50 billion CSS files scattered all over the place, many containing classes that contradict and override other existing classes, often in completely unclear ways as it's hard to know in which order things will get compiled ultimately. As time passes, you'll see BEM done in various ways, you'll see cursed SCSS functions that generate styles dynamicslly, you'll see a bunch of !importants, and eventually you end up in a state where making a change to a legacy page becomes an exercise in dodging specificity and ordering minefields.

Meanwhile with Tailwind, everything is localized to the element it's affecting, and very importantly the entire team has a "standard library" of properties and patterns they can pull from, so you don't end up with people in different teams naming similar UI patterns differently, and you straight up never have to think of specificity ever again (which in my view is a boon, despite what CSS purists might say). Yes, the HTML is more verbose, but this is just such a non-issue after the first 5 minutes of discomfort, plus all the other benefits.

Hot take, but the Cascading part of CSS has proven itself to be a massive drawback, and not a benefit. Tailwind obviates that completely.

Re: Vanilla JavaScript support for Tailwind Plus

#189

Post by sensanaty »

timeon wrote: post #138
ricardobeat wrote: post #67

Lovely. Verbosity aside, now on top of knowing CSS you need to learn another hierarchical system within class names.

Not to mention that for every class here there is also definition in CSS that client needs to download.

Tailwind tends to be smaller bundle-wise because it will only compile the styles you actually use in the final bundle. The old app I work on, the BEM classes are staggering in their size all combined, whereas the tailwind portions are tiny and importantly barely ever grow in size since the majority of code, old and new, will be using the same "building block" classes like flex p-4 or whatever.

Re: Vanilla JavaScript support for Tailwind Plus

#190

Post by sensanaty »

paradox460 wrote: post #75
skydhash wrote: post #71

Earlier quoted context omitted.

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

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

On the site I maintain at work, if I check literally any of the old components that don't use tailwind, what I see in the styles list of the devtools is 75 different variants of .card__wrapper or whatever all overriding each other, and it's often an abject nightmare trying to figure out which of the 75 different .card__wrapper (or is it .card { &.__wrapper} ?) classes is the one I care about at the moment.
Post reply on HN