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

Tailwind CSS v4.0

tailwindcss.com

Post reply on HN
Print view View original

281–290 of 296 posts

Re: Tailwind CSS v4.0

#281

Post by threatofrain »

brightball wrote: post #270
meiraleal wrote: post #259

Earlier quoted context omitted.

just like CSS

Not really the same, although I realize it can seem that way. If you go low level enough everything technically fits that bill, it’s just a matter of how much work you have do to put the structure in place and what the burden is for other people to learn it. It’s akin to raw Perl vs Ruby on Rails. You can do it that way, nothing is stopping you…but there are compelling reasons not to.

That's exactly the argument I'm making about Tailwind. Inadequate as a design system. You have these bundles of rules just a thin step above CSS and there's nothing obvious about how things should look.

Re: Tailwind CSS v4.0

#282

Post by jakubmazanec »

nejsjsjsbsb wrote: post #124
mythz wrote: post #123

Earlier quoted context omitted.

Yep `npx tailwindcss@v3` is the solution we ended up with. Just had to change this in all our Apps and project templates.

I wish @-less wasn't be allowed. Like you can do @latest but then human confirm is needed. That way you don't get this problem in scripts.

> then human confirm is needed

"Suppress this prompt with the -y or --yes option" [1]

[1] https://docs.npmjs.com/cli/v11/commands/npx

Re: Tailwind CSS v4.0

#283

Post by tipiirai »

threatofrain wrote: post #83
tipiirai wrote: post #81

Earlier quoted context omitted.

I'm a designer, so I absolutely think in terms of design systems where typography is just one part of the puzzle. There are, of course, many ways to set type — but the point was: no Tailwind engineer talks about typographic scales in the first place. Systematic thinking is absent, which is naturally built in CSS.

I'm kind of surprised why this is even relevant to you. The designers I know work in Figma. The designer and the engineer collaborate to make sure the design isn't too hard to implement, but other than that the designer shouldn't care about whether developers are using Tailwind, StyleX, Sass, vanilla, or whatever. I hardly expect a designer to take responsibility for something as transient and idiosyncratic as "oh, b…

I'm (not) surprised typographic scales are non-relevant for Tailwind developers

Re: Tailwind CSS v4.0

#284

Post by 8n4vidtmkvmk »

jitl wrote: post #263
8n4vidtmkvmk wrote: post #249

Earlier quoted context omitted.

Have y'all not heard of css modules or BEM?

pointless make-work compared to inline-styles-like workflow like tailwind, if you have a component framework

You might like Styled Components then, if you're using React anyway. Not sure if there's similar systems for other frameworks. I don't consider it pointless make-work to develop a consistent stylesheet to use throughout your app though.

Re: Tailwind CSS v4.0

#285

Post by joks »

rglullis wrote: post #27
kyleyeats wrote: post #23

Earlier quoted context omitted.

As someone who made a competing product along these lines (that got no attention or traction): Tailwind gives CSS a "place" in the codebase. It benefits orgs, not necessarily apps. I didn't get it at first either. But it's very useful to the people to whom it's useful.

> Tailwind gives CSS a "place" in the codebase. It benefits orgs, not necessarily apps. That is a better argument. But couldn't we be able to achieve that by, e.g: - Create one standard HTML document with a predefined structure and including all the web components needed by your product. - Having all designers and frontend developers developing their CSS (or SCSS) against this single base document This would be basic…

As others have said, this is exactly what many large orgs do, but in a slightly higher-tech / more polished way with tools like Storybook, essentially creating their own CSS libraries and component libraries.

IMO a decent analogy is that Tailwind is to the above as something like Shopify is to being large enough to build your own ecommerce platform from scratch.

Re: Tailwind CSS v4.0

#286

Post by Parfait__ »

I'll stick with 3, not rewriting so much of the codebase because taking away features is now an improvement. Not sure where dogma and performance overlap but it isn't in making @apply a hassle.

Re: Tailwind CSS v4.0

#287

Post by 0xblinq »

Francute wrote: post #280
0xblinq wrote: post #273

There's a clear pattern in every "Tailwind or not tailwind" conversation (which happens everytime Tailwind is mentioned). There's those that never used it for more than 30 minutes, that just tried it out or just skimmed through the docs. Those are the people that hate it and prefer "vanilla CSS" or similar. Then there's the people that actually used it for a real project, within a team with more than 1 single person.…

I think I don't fit in either of your groups. I’m not against Tailwind, but I didn't used it yet because I struggle to see why it's a better approach compared to other options like Web Components or React Styled Components. The biggest issue I have with Tailwind is how it clutters the HTML with a ton of utility classes making the HTML harder to read and maintain. Of course I see Tailwind being better than using large…

> I’m not against Tailwind, but I didn't used it yet because I struggle to see why it's a better approach compared to other options like Web Components or React Styled Components.

> The biggest issue I have with Tailwind is how it clutters the HTML

You're 100% clearly in the first group. Maybe I shouldn't have said "hate" in that group, just people that don't like it or see its benefits.

> Like Web Components

That's a nice solution, but in practice as of today and relatively speaking: nobody is using them.

> and Styled Components

Except the performance is a lot worse. And you still have to come up with names for every single div that needs a minimal one line style.

And both of these solutions end up with huge CSS files. Huge CSS files are worse than having larger HTML markup, because CSS is a blocking resource and HTML is not.

> I really value keeping HTML very short and readable by not mixing presentational styles directly in the markup

People used to say this about React, they preferred their HTML separate from their JavaScript, all nice and clean. I'm now 150% sure you're in the first group.

> Yes, I've read the docs but never tried it out, I don't hate it, but I can't understand why I would choose it over other options. The fact of having a million classes in the middle of plain HTML makes them both unreadable for me.

Alright, now you've recognized it.

> These two approaches allows me to not have to read presentational things in the middle of my html, and allow my html to be more clear and readable.

That's a non issue. There are extensions that will just hide classnames. You're just blending your mind looking for reasosn to justify your "I don't like it".

I promise the day you use it in a real life project where you're working with > 3 other people you will understand it's benefits, and how having "large class lists" is a non-issue and a totally acceptable trade off over the practical benefits it provides. Both on performance of the resulting CSS and maintainability over a large period of time. And think in the insane amount of discussions you'll avoid regarding if we're calling this div "styledDivWrapper" or "WraperContent" or "CardWrapper" or ".card__item--dark". Not an issue if you work alone, but when working with others this becomes a real annoyance that tailwind completely removes.

Tailwind is not for your, don't use it.

Tailwind is not for purists and architecture philosophers.

Tailwind is for pragmatic people, working on real life projects within teams where they have to ship and spend less time philosophizing on the purity and beauty of things.

Re: Tailwind CSS v4.0

#288

Post by jitl »

8n4vidtmkvmk wrote: post #284
jitl wrote: post #263

Earlier quoted context omitted.

pointless make-work compared to inline-styles-like workflow like tailwind, if you have a component framework

You might like Styled Components then, if you're using React anyway. Not sure if there's similar systems for other frameworks. I don't consider it pointless make-work to develop a consistent stylesheet to use throughout your app though.

Styled Components is too low-level (let’s name every div!!!) and comes with a substantial performance cost. Tailwind is a much better option.

Re: Tailwind CSS v4.0

#289

Post by rglullis »

joks wrote: post #285
rglullis wrote: post #27

Earlier quoted context omitted.

> Tailwind gives CSS a "place" in the codebase. It benefits orgs, not necessarily apps. That is a better argument. But couldn't we be able to achieve that by, e.g: - Create one standard HTML document with a predefined structure and including all the web components needed by your product. - Having all designers and frontend developers developing their CSS (or SCSS) against this single base document This would be basic…

As others have said, this is exactly what many large orgs do, but in a slightly higher-tech / more polished way with tools like Storybook, essentially creating their own CSS libraries and component libraries. IMO a decent analogy is that Tailwind is to the above as something like Shopify is to being large enough to build your own ecommerce platform from scratch.

What is stopping from someone just turning all those utility classes into a single CSS file and completely get rid of the post-processor stuff?

Re: Tailwind CSS v4.0

#290

Post by 8n4vidtmkvmk »

jitl wrote: post #288
8n4vidtmkvmk wrote: post #284

Earlier quoted context omitted.

You might like Styled Components then, if you're using React anyway. Not sure if there's similar systems for other frameworks. I don't consider it pointless make-work to develop a consistent stylesheet to use throughout your app though.

Styled Components is too low-level (let’s name every div!!!) and comes with a substantial performance cost. Tailwind is a much better option.

> a substantial performance cost

I believe the Babel plugin eliminates most of the performance cost.

The naming is double-edged. Often you want to re-use your styled element, so the fact that it has a name from the get-go makes that really easy. But you're right, sometimes it's annoying to pull bits out that you didn't really want to.

Ultimately I went back to CSS Modules. I just don't understand why I'd want to the appeal of Tailwind.. I'd have to learn a new DSL that ultimately gives me less control.

Post reply on HN