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

Tailwind CSS v4.0 Beta 1

tailwindcss.com

Post reply on HN
Print view View original

131–135 of 135 posts

Re: Tailwind CSS v4.0 Beta 1

#131

Post by Vinnl »

naasking wrote: post #128
Vinnl wrote: post #127

Earlier quoted context omitted.

Well, Tailwind doesn't really solve that for you either - you pretty much have to know CSS to be able to use it effectively, in my experience. Technically, you may not really be writing CSS, but in practice, I think all the reasons you might have for not wanting to write CSS still apply to writing Tailwind.

Not quite, with Tailwind: 1. you need to know the specific effects of the individual directives but you don't need to deal with the cascading behaviour and other complexities. 2. you don't need to leave your local markup to make styling changes. 3. you don't need to synchronize selectors across multiple files (non-locality). And because Tailwind involves a lot of repetition of the same CSS classes for the same markup…

That's fair enough, but I do still expect that someone who really wants to avoid CSS will still be put off by the extent to which Tailwind still is, in essence, CSS. I think Tailwind has advantages (the ones you note), but "being able to not learn CSS" is not it.

Re: Tailwind CSS v4.0 Beta 1

#132

Post by Vinnl »

emmacharp wrote: post #129
Vinnl wrote: post #126

Earlier quoted context omitted.

> I address the problem of relevance by inserting the CSS right into the component with a link tag. If the component is not used, the CSS isn't either. Do the selectors in those style tags not apply globally? How do I prevent contributors (including myself) from accidentally writing a selector that affects HTML in other components? I see ECSS allows plain tag selectors for example? Isn't the design token variable fil…

1. The stylelint config will flag any selector not scoped (be it a class or an attribute) to the filename. This way you'll be notified if any selector could be misapplied essentially preventing these global accidents. 2. You could use a build step for this, yes. Personally, I don't because the theme files more or less contain always the same tokens. I rarely add any (colors being the most frequent) and if I do, the c…

That generated some more question :)

But on the ECSS homepage I see selectors like `html`, `.flex-module` or `.is-loading` (I'm assuming `flex-module` and `is-loading` aren't components - if they are, then that sounds like being pushed towards a layer of indirection that I'd like to avoid?) - aren't those likely to affect other components?

What's the disadvantage of not being able to stop using Tailwind at any time? How likely is that to play out?

Why does it matter if something's "not optimal" if it doesn't make much of a difference in performance? (See also: not removing unused styles from your theme files :)

Re: Tailwind CSS v4.0 Beta 1

#133

Post by emmacharp »

Vinnl wrote: post #132
emmacharp wrote: post #129

Earlier quoted context omitted.

1. The stylelint config will flag any selector not scoped (be it a class or an attribute) to the filename. This way you'll be notified if any selector could be misapplied essentially preventing these global accidents. 2. You could use a build step for this, yes. Personally, I don't because the theme files more or less contain always the same tokens. I rarely add any (colors being the most frequent) and if I do, the c…

That generated some more question :) But on the ECSS homepage I see selectors like `html`, `.flex-module` or `.is-loading` (I'm assuming `flex-module` and `is-loading` aren't components - if they are, then that sounds like being pushed towards a layer of indirection that I'd like to avoid?) - aren't those likely to affect other components? What's the disadvantage of not being able to stop using Tailwind at any time?…

Great!

1. some simple selectors can be used in specific contexts (like `html` for type inheritance, for instance). `flex-module` is a component name (albeit a very generic one only used for example purposes...) and `is-loading` is a "state class". I use simple prefixes to distinguish between selector types and `is` is one of them.

2. Breaking changes could be introduced through the Tailwind dependency tree. Some update could be necessary to patch an exploit, again breaking functionality. Updates become routinely necessary. Which is not the case for native code. Also, using new CSS features can be more taxing within the TW ecosystem than in with vanilla CSS. In a nutshell, it's about simplicity, maintenance and the perenniality of your code. On the other hand, you may be "lucky" and never experience something like the above. But I'd wager there's more chance that you will than not. At least, my own dev experience tells me this.

3. Well, I'd say it's a matter of scale... I see 60kb of CSS on Tailwind's homepage. If more than 80% is unused, that's something like 45kb of CSS. I think at this amount, you could see marginal improvements in rendering and loading. At least, more than with comething like 2-3kb of unused CSS. Hehe. But yeah, as I said, marginal. BUT! hehe, with a less monolithic approach to bundling CSS, as with links in components, for instance, there's a real gain to be had: the browser delays reading the files not being used in the current viewport. So, if you footer is not displayed in the first screem it's CSS won't be read, accelerating overall rendering. This, in my experience, makes a palpable difference.

Hope I'm being clear, english is not my first language. And thanks for the mental workout! Hehe.

Re: Tailwind CSS v4.0 Beta 1

#134

Post by meiraleal »

quantadev wrote: post #115
phist_mcgee wrote: post #113

Earlier quoted context omitted.

I get where you’re coming from, but I think it oversimplifies the challenges front-end developers face, and it feels a bit dismissive of their expertise. Front-end development isn’t just about chasing frameworks—it’s about crafting intuitive, performant, and accessible user experiences in a landscape that’s constantly evolving to meet user needs. Backend stability has its advantages, but the rapid evolution on the fr…

It's not "dismissive" or a "disservice" to say which things I found harder in my 35yrs experience. I also say C++ is "harder" than Java, and that's not "dismissive" of Java devs. lol. I AM a Java dev. I did C++ for 10 years followed by Java for 25 yrs after that, so I feel justified to have opinions. I could also say Assembly Language was hardest of all but I won't because it might be "dismissive" of any easily-offen…

It is an interesting concept that backend is harder while so much easier. Maybe frontend is harder and it is difficult because you lack the necessary knowledge to make it as easy as you think backend is.

Re: Tailwind CSS v4.0 Beta 1

#135

Post by Vinnl »

emmacharp wrote: post #133
Vinnl wrote: post #132

Earlier quoted context omitted.

That generated some more question :) But on the ECSS homepage I see selectors like `html`, `.flex-module` or `.is-loading` (I'm assuming `flex-module` and `is-loading` aren't components - if they are, then that sounds like being pushed towards a layer of indirection that I'd like to avoid?) - aren't those likely to affect other components? What's the disadvantage of not being able to stop using Tailwind at any time?…

Great! 1. some simple selectors can be used in specific contexts (like `html` for type inheritance, for instance). `flex-module` is a component name (albeit a very generic one only used for example purposes...) and `is-loading` is a "state class". I use simple prefixes to distinguish between selector types and `is` is one of them. 2. Breaking changes could be introduced through the Tailwind dependency tree. Some upda…

Thanks! (Not a native English speaker here either, but was perfectly clear.)
Post reply on HN