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

151–160 of 202 posts

Re: Vanilla JavaScript support for Tailwind Plus

#151

Post by elktown »

Jaygles wrote: post #100
AstroBen wrote: post #97

Earlier quoted context omitted.

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'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" seems to still apply, but are much rarer now with grids/flex etc. But the structure of CSS itself is very straight-forward to me and has almost always been?

Is what's really going on that when people are trying to use vanilla CSS they go overboard with keeping CSS DRY? Which ofc ends up with an interdependent mess that's becomes increasingly harder to change. Just stop that? Start namespacing and copy pasting? CSS doesn't need to be compact.

Re: Vanilla JavaScript support for Tailwind Plus

#153

Post by MrJohz »

owebmaster wrote: post #149
MrJohz wrote: post #135

Earlier quoted context omitted.

:has doesn't require JS, I think the previous poster was just confused about which selector `group` is equivalent to.

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

Based on other replies, I believe they understood CSS well enough, but didn't understand the exact behaviour of the `group` class in Tailwind. Given neither of your comments seem to have made much sense given the context of the discussion, I wonder if you're just looking for confirmation of things you already 'know'.

EDIT: I'm sorry, I mixed you up with the other user who was replying criticising other people's CSS knowledge.

Re: Vanilla JavaScript support for Tailwind Plus

#154

Post by MrJohz »

owebmaster wrote: post #148
MrJohz wrote: post #105

Earlier quoted context omitted.

It's not even :has, it's just how child selectors in CSS have always worked. // Not actually needed, here // for competition .group {} // Child selector .group:hover group\/hover\:bg-black { background-color: black; } // Which is essentially the same as .group:hover child { background-color: black; }

is it possible to add the hover to the parent without also adding it to the child ?

What do you mean? It's possible to apply attributes to any element in an arbitrary state: `hover:bg-black` would give an element a black background on hover. It's also apparently possible to apply attributes based on whether a state is fulfilled for a child element (i.e. the :has selector). E.g. `has-[:hover]:bg-black` would give an element a black background if any child is hovered.

Re: Vanilla JavaScript support for Tailwind Plus

#155

Post by doytch »

ricardobeat wrote: post #150
omnimus wrote: post #128

Earlier quoted context omitted.

Tailwind goes into crazy extreme so people can copy paste whole complex components and they work. That’s why you can dunk on these verbose examples. This is not how custom functional css codebase looks. In custom projects you change the system/configuration to fit the project. You create your own utilities for example you wont have “text-lg sm:text-xl font-semibold tracking-tight” but will have class “font-heading-2”…

> will have class “font-heading-2” At that point, why not write these in CSS instead? There is little advantage in using the tailwind shorthand classes in your own class definitions. - You can use plain CSS variables for theming - You're bringing back the supposed downsides of cascading and shared classes - simple Gzip compression will achieve similar size reduction as the utility classes Working on your codebase now…

You’re right - if you only used it for ‘font-heading-2’, you wouldn’t need it.

But like the person you’re responding to said, the ergonomics improve for the majority of cases that are just ‘flex items-center gap-2’.

And yes, you could write it all yourself but Tailwind is a good set of defaults for those classes and minimizes bike-shedding and improves consistency. These are useful things in lots of teams.

I don’t really use Tailwind on smaller personal projects because I love CSS, but in an org of mixed skill levels, it’s pretty damn useful.

(Also, Tailwind uses CSS variables. It had solid support for them in the last major and first class support for it in the current one.)

Re: Vanilla JavaScript support for Tailwind Plus

#156

Post by omnimus »

ricardobeat wrote: post #150
omnimus wrote: post #128

Earlier quoted context omitted.

Tailwind goes into crazy extreme so people can copy paste whole complex components and they work. That’s why you can dunk on these verbose examples. This is not how custom functional css codebase looks. In custom projects you change the system/configuration to fit the project. You create your own utilities for example you wont have “text-lg sm:text-xl font-semibold tracking-tight” but will have class “font-heading-2”…

> will have class “font-heading-2” At that point, why not write these in CSS instead? There is little advantage in using the tailwind shorthand classes in your own class definitions. - You can use plain CSS variables for theming - You're bringing back the supposed downsides of cascading and shared classes - simple Gzip compression will achieve similar size reduction as the utility classes Working on your codebase now…

I was unclear. Yes of course you write these classes “font-heading-2” in CSS. Tailwind is essentialy big list of premade classes to dynamically pull from. I think the functional approach/structure is the interesting part why people like Tailwind. On very small projects i even make “Tailwind by hand” creating those utilites as i go.

> There is little advantage in using the tailwind shorthand classes in your own class definitions.

There are few massive advantages. I dont have to figure out how to name these classes. Other people in the team know them too. And when they see class they dont know they know its something custom probably for a reason.

> You're bringing back the supposed downsides of cascading and shared classes

I never said cascade is bad. Creating new flat class with 0-1-0 specificity doesn’t break Tailwind. I’ve been through enough of - everything has specific class that’s nested/scoped… from my experience and usecase it’s harder for little benefit except neater html.

> simple Gzip compression will achieve similar size reduction as the utility classes

I meant custom css that you write by hand and have to scroll trough. Not the result pushed to browser. With functional css you manage to do most of the work in html and what doesn’t make sense you can do traditionaly. For example i dont like doing complex hover interactions in Tailwind so the html has all the layout utilities but also custom class that only has this custom interaction behaviour.

> Working on your codebase now requires full knowledge of the Tailwind utilities, layers, directives, pseudo-classes, theming, and all the complexity that comes along with them.

Is knowing Tailwind naming conventions worse than not having any convention at all? My experience is that Tailwind are just classes that are documented. Without it we would have classes that are undocumented.

There are cases where functional css is not that beneficial. Like in long running products which have single file component workflow where css is scoped and html/css live in same file. But in work i do in small team we just found it to solve many our painpoints.

Re: Vanilla JavaScript support for Tailwind Plus

#157

Post by omnimus »

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.

Tailwind has few :has tools but it’s imho terrible. They keep inflating the system to nonsense.

Re: Vanilla JavaScript support for Tailwind Plus

#158

Post by bmare »

JoeyJoJoJr wrote: post #137
reactordev wrote: post #86

Earlier quoted context omitted.

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.

Can you point to any example projects or a todo list app that shows how modern web component can be utilized.

Here's a great one: https://plainvanillaweb.com/pages/components.html

Re: Vanilla JavaScript support for Tailwind Plus

#159

Post by jtickle »

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 have seen this sentiment on HN a lot recently. Any good resources for that? I was quite the accomplished web developer 15-20 years ago and want to catch up without having to learn a new library or framework every six months.

Re: Vanilla JavaScript support for Tailwind Plus

#160

Post by smac__ »

jtickle wrote: post #159
AstroBen wrote: post #97

Earlier quoted context omitted.

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 seen this sentiment on HN a lot recently. Any good resources for that? I was quite the accomplished web developer 15-20 years ago and want to catch up without having to learn a new library or framework every six months.

https://www.manning.com/books/css-in-depth is an excellent option. This book helped fill in the gaps for me when it comes to modern CSS.
Post reply on HN