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

201–210 of 296 posts

Re: Tailwind CSS v4.0

#201

Post by jitl »

rglullis wrote: post #179
jitl wrote: post #90

Earlier quoted context omitted.

CSS has become more confusing over time, not less confusing, so the upside of a utility class approach like Tailwind is also improving over time rather than decreasing. Tailwind solves css confusion by presenting a “paved road” for many tasks. Want to do “thing”? Just look up “thing” in the tailwind docs, add “thing-2” to your class, done in 2 minutes. Rather than look up “thing” on google, skim several articles, the…

> With tailwind, just add 2 classes, done. But you can do that with a library of SASS mixins as well. Going through some of the answers I'm noticing that another "issue" I have with the tailwind approach is that it works by providing a post-processor when in reality most people just need a simple preprocessor and macro system.

Sure? I don’t see how that’s an argument for CSS “being advanced enough” - SASS ain’t CSS.

I like SASS (I wrote a lisp in SASS in 2011 lol) and that’s actually how I think about Tailwind utilities - it’s just using SASS mixins directly in your HTML. I would rather use Tailwind because it will take 1/3 the levels of abstraction, 1/4 the keystrokes and 1/2 the files to do the same job to:

1. Pick a class name (myclass) if people are using BEM or something this requires some algebraic thinking.

2. Write the class in file.scss to define the class and include mixins A, B, C

3. Add class=myclass in my html.

Vs tailwind:

1. Add class=“A B C” to my html.

I don’t really get pre processor vs post processor, it’s a build step to run at some point before I deploy with either tool that will produce some css files. ¯\_(ツ)_/¯

Re: Tailwind CSS v4.0

#202

Post by jitl »

mythz wrote: post #133
preisschild wrote: post #126

Earlier quoted context omitted.

But why not though I also use tailwindcss in a non-node project, but use npm package / lock files to easily lock javascript / css dependencies and make renovate able to update them for me.

I've linked to why. We prefer #NoBuild solutions where we'd only use local npm deps/node_modules if we absolutely have to, and for non JS Apps we don't.

The node_modules folder is still somewhere on your system (~/.npm/_npx probably?) containing the same tailwindcss dependency files, but if it helps you sleep easier at night it’s okay to pretend it doesn’t exist.

Re: Tailwind CSS v4.0

#203

Post by jitl »

dankobgd wrote: post #192
crummy wrote: post #4

Earlier quoted context omitted.

What did you need Tailwind for before that you couldn't do in normal CSS? Doesn't Tailwind map pretty much 1:1 to CSS?

It's a horrible way to do what css can do but in a dumber way with added tooling. It is used by people that don't know css and this is where the problems start

I’ve been writing css/scss/stylus/linaria/whatever styling stuff for 18 years and I think tailwind improves life much more for css knowers than for css noobs. I prefer it over raw css for sure - I’ve written the same shit enough times that I’m happy to take some shortcuts and more than willing to pay for some tooling to do so. Tailwind hands out less abstraction rope compared to vanilla css and sass and all the rest, so much lower chance I open up a file and find some convoluted special little kingdom of abstractions that need to be handled carefully. Reduced cognitive load in the long run for a small up front learning/setup cost.

Re: Tailwind CSS v4.0

#205

Post by jitl »

asimpletune wrote: post #144

I used tailwind for my site and ended up liking it a lot, but maybe for reasons that are not often mentioned? The real value of tailwind is being able to read all the styles that affect a an element in one place. Sure the classnames can get long, but it’s still a lot faster to read that long line, than open the browser tools each time or scroll up and down one (or many) stylesheets. Then when you come back to that co…

I think that is exactly why tailwind is good and nice. Although I also like that it makes “how do I do X?” a quick doc search instead of a 30 minute research project

Re: Tailwind CSS v4.0

#207

Post by floydnoel »

homarp wrote: post #71
loxs wrote: post #68

Earlier quoted context omitted.

They are cryptic but the learning curve is not that steep. Once you get the idea, it becomes much easier (and quite pleasant for a CSS hater like me). For example px-3 means "padding on the x axis 3 (spacing values)" and gives you padding on both left and right. There is a (rather simple) language that you need to learn and at least for me it made things much, much better. You can probably get the feel for it in seve…

ia that really easier than learning css directly? since you have to understand 'paddding'and 'px' ? see https://developer.mozilla.org/en-US/docs/Web/CSS/padding vs https://tailwindcss.com/docs/padding

it's quicker to write, though. and many of these class names are the same in bootstrap, so I've been seeing stuff like 'p-0 m-1' in frontend projects for decades.

another huge benefit these days is with the styling living alongside the markup, it is very easy to use chatGPT or other AI tools to copy/paste and have changes made, etc. it is much less work with one file vs multiple. you can give the context super easily and take the results very quickly.

Re: Tailwind CSS v4.0

#208

Post by jitl »

vim-guru wrote: post #119

CSS has become significantly more user-friendly than in the past, with most browsers now behaving consistently. It's worth learning as there is no build step involved, and it avoids cluttering your markup with excessive code. You could opt to use style attributes directly within your HTML. Historically, we avoided this to maintain a separation of concerns, but it's puzzling why some prefer reintroducing similar metho…

These days tailwind is often paired with a component abstraction system that takes place of css classes as an abstraction system. Component abstraction achieves an even more powerful separation of semantics from styling, compare:

    Cool page
vs:

    Cool page
In both cases you need to go find the “hero” abstraction, but in component world we are also abstracting over the HTML tag name in addition to whatever styling stuff.

When it comes to defining the “stylistic detail” in either case, it has been separated from the “content” which is our page source file. I am happy to pay a build step to get better separation of concerns - content from presentation.

Re: Tailwind CSS v4.0

#209

Post by whstl »

christophilus wrote: post #180
whstl wrote: post #170

Earlier quoted context omitted.

I don't know. In 20+ years I have seen way more abominations and spaghetti CSS using other every CSS technique. With Tailwind at least I know what to expect, and the code in practice rarely deviates from what it's supposed to look like. I'm all for "not building up technical debt" and "thinking about things first" but in my personal experience the anti-Tailwind crowd doesn't have much to show here in this regard. Sur…

Same. Been doing this for 20+ years. I’ve worked at companies whose names are recognized and respected. My current Tailwind project is by far the most maintainable one I’ve worked on when it comes to CSS.

Exactly.

I don't know why, and perhaps in theory it should suck indeed! But in the end it just works.

Re: Tailwind CSS v4.0

#210

Post by rglullis »

jitl wrote: post #201
rglullis wrote: post #179

Earlier quoted context omitted.

> With tailwind, just add 2 classes, done. But you can do that with a library of SASS mixins as well. Going through some of the answers I'm noticing that another "issue" I have with the tailwind approach is that it works by providing a post-processor when in reality most people just need a simple preprocessor and macro system.

Sure? I don’t see how that’s an argument for CSS “being advanced enough” - SASS ain’t CSS. I like SASS (I wrote a lisp in SASS in 2011 lol) and that’s actually how I think about Tailwind utilities - it’s just using SASS mixins directly in your HTML. I would rather use Tailwind because it will take 1/3 the levels of abstraction, 1/4 the keystrokes and 1/2 the files to do the same job to: 1. Pick a class name (myclass)…

> I don’t see how that’s an argument for CSS “being advanced enough”

That's a separate argument.

I hear mostly two justifications for tailwind:

1. It is (or used to be) hard to do things in CSS like variables, calculated properties, themes, scoped rules / namespacing. (Pre/Post) Processors are going to be required anyway, so we might as well use Tailwind

2. It gives frontend developers and designers a common language (the utility classes) which makes it easier to establish workflows.

My argument for (1) is that CSS already supports a lot of things that used to require processors, and (2) could be achieved with a simple "library" that could just be imported directly.

Post reply on HN