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

CSS's problems are Tailwind's problems

colton.dev

Post reply on HN
Print view View original

141–150 of 179 posts

Re: CSS's problems are Tailwind's problems

#141

Post by gherkinnn »

p4bl0 wrote: post #134

I never liked Tailwind. The point of CSS was to separate content and presentation. Tailwind not only goes backward on that but does it a lot worse than HTML did before, because the presentation not only is mixed with HTML but is also just a long random string rather than structured into HTML attributes. It's just like CSS using only style="" attributes, only with a different, almost proprietary syntax that you have t…

Oh why can't this idea go away. That might or might not have been the idea, but it does not scale beyond a text document. It so does not.

If it did, we wouldn't have 15 years of Sass and Less and Stylus and CSS Modules and Styled Components and BEM and SMACSS and Tailwind. I have been through it all and Tailwind is the easy winner both for productivity and maintenance over 5 years.

I sort my cutlery by knife/fork/spoon, not handles and implements.

Re: CSS's problems are Tailwind's problems

#142

Post by gizzlon »

aeonfr wrote: post #111

The whole block about performance is just… not correct? Tailwind, and atomic CSS libraries, scale better, not worse! Look at how facebook leverages atomic CSS to reduce CSS by 80% https://devmohit.medium.com/facebook-generating-atomic-css-t... Even if we consider small codebases, the examples OP shows seem to ignore Zip compression and how it works, which is ironic for someone who is arguing about performance as if i…

I would not expect compression to help performance in the browser??

Bytes transferred, sure, but that's not what OP is talking about

Re: CSS's problems are Tailwind's problems

#143

Post by micromacrofoot »

pyman wrote: post #76
jakelazaroff wrote: post #49

Earlier quoted context omitted.

It's not quite apples-to-apples because the Tailwind code is using design tokens and the CSS is not. You should (for example) replace the long `box-shadow` value with `var(--shadow-md)`. Anyway, to me this question is kind of like asking "Is it easier to break your writing into paragraphs, or write everything in one long block?" Like, what would you think if I formatted my comment like this? > It's not quite apples-t…

This isn't something a web developer should be doing in 2025. The styling should be generated by the software used to design the UI. Why aren't the companies building design tools solving this?

Adobe has been trying to build this product for 30 years and still haven't figured it out. Figma is trying and the best you can get is partially usable copy and paste CSS.

This is a "why don't they just make self-driving cars" question. The answer is that there are too many edge cases.

Re: CSS's problems are Tailwind's problems

#144

Post by zelphirkalt »

Alupis wrote: post #32
micromacrofoot wrote: post #6

Earlier quoted context omitted.

I can't believe people find even half of this acceptable, do they never use a browser inspector in their work?

If you write enough CSS for a site... eventually you end up building utility classes anyway. Now, you re-invented Tailwind... but in your own proprietary way that nobody else understands. Tailwind takes the inverse approach. The example posted by the parent above is completely unambiguous - what you see is what you get, and it's done the same way everywhere Tailwind is used. You can read the component's styles and un…

When I write CSS, I think in layers:

(1) General CSS, global effect, like basic font size

(2) semantic components on my pages, like a special kind of list or something, that I give a well thought out name. These CSS definitions are always scoped, obviously to ".my-class-name something" selectors. They cannot affect anything that is not inside a semantic component. It is very simple.

(3) layouts/containers, that contain the components, like some flexbox or grid or something that behaves a certain way, which I also give a meaningful name

(4) A theme, a CSS file that contains CSS variables, which have values used in the other layers. Often when I need to change something, I only need to change my theme.

I do not understand, why web developers en mass are unable to cooperate with each other to develop their semantic units for CSS and then stick to those, instead of sprinkling stuff everywhere and using !important to make shoddy work. If they disagree about the semantic units, then that is the same problem as we have in any other software development arguing how to box things. Furthermore, the semantic units should be part of the design language of the business. The designer should realize "We have 3 kinds of buttons. Each has its own set of rules." and then what is easier than making 3 CSS classes? -- I am sorry, I do not understand where the difficulty is with just using CSS. Someone please, please explain to me, what is the problem in this day and age.

Re: CSS's problems are Tailwind's problems

#145

Post by huksley »

Tailwind is great for layouts. For configurable components, not sure. I also dislike the mess with colors.

Cursor IDE uses those navy-100, red-100 absolute colors, instead of using text-destructive, etc (for light/dark mode support), and it is also difficult to tell it does otherwise. So I need to fix this manually, and it is quite time-consuming.

Re: CSS's problems are Tailwind's problems

#146

Post by pier25 »

jackdh wrote: post #45
pier25 wrote: post #17

Earlier quoted context omitted.

> There is also nothing stopping you mixing and matching. Yes, common sense. Having multiple approaches to solve the same thing tends to be a bad idea.

My point is that there is no one CSS library to rule them all and likely never will be. The closest to that is going back to pure raw CSS which I highly doubt people will do. And yes while it's obviously not ideal to have a hundred competing libraries in your code, you can create what works for you / your team.

> The closest to that is going back to pure raw CSS which I highly doubt people will do.

Huh? Tons of people write vanilla CSS which is getting better every year.

Re: CSS's problems are Tailwind's problems

#147

Post by pier25 »

hugeBirb wrote: post #30
pier25 wrote: post #17

Earlier quoted context omitted.

> There is also nothing stopping you mixing and matching. Yes, common sense. Having multiple approaches to solve the same thing tends to be a bad idea.

This is an extremely limiting view. They are both CSS at the end of the day. If extracting the complicated inline TailwindCSS class to its own vanilla CSS class makes sense for readability then what's the harm? You could also just define your own variables. Tailwind gives you full control to do this.

The harm will be in a complicated project where you might have to figure out where some styles are coming from.

Re: CSS's problems are Tailwind's problems

#148

Post by zero_shift »

zero_shift wrote: post #80

I'm a bit of a luddite with CSS. I learned BEM about five years ago and I've more or less always stuck to component scoped CSS files. Sometimes I use CSS-in-JS if a component system demands it, like Material. I don't mind it as much as others do, I like that there's no CSS concatenation weirdness. But otherwise I feel quite happy with a component file and a style file. For Tailwind fans (or even detractors), what's t…

(not sure why I said "five years ago" - I learned BEM back in 2014)

Re: CSS's problems are Tailwind's problems

#149

Post by seanwilson »

lenkite wrote: post #4

If you go even minimally outside the beaten path, the tailwind CSS declarations can mutate into a frankenstein monster that makes regular CSS look like a friendly, cute koala Example: https://www.nikolailehbr.ink/blog/realistic-button-design-cs... shows an "old fashioned", 90's are back-in-vogue, 3d button. Tailwind CSS for it becomes After I got eye-strain and headaches after taking over maintenance of a tailwind ba…

I see buttons used as an example a lot but buttons are one of the most style heavy elements on many websites and are only a single element so it's not a good comparison imo.

For a lot of pages, you're often only adding maybe 1 to 5 styles to each element to change some flexbox settings, add some margin, set a background color, or change a font. With the traditional CSS approach, you're forced to come up with class names for each element and put the styling into a separate file, which makes iterating on style and layout really laborious compared to Tailwind.

That's a much bigger benefit to focus on rather than looking at how (single element) buttons are styled. It's not like the CSS for styled buttons is less verbose or even pretty either.

Re: CSS's problems are Tailwind's problems

#150

Post by sixtyj »

lenkite wrote: post #4

If you go even minimally outside the beaten path, the tailwind CSS declarations can mutate into a frankenstein monster that makes regular CSS look like a friendly, cute koala Example: https://www.nikolailehbr.ink/blog/realistic-button-design-cs... shows an "old fashioned", 90's are back-in-vogue, 3d button. Tailwind CSS for it becomes After I got eye-strain and headaches after taking over maintenance of a tailwind ba…

Last days I have spent with Tailwind. But honestly, even if I know all abbreviations now :), and it it eye-bleeding syntax, is there something better in the wild? I know that I could use vanilla CSS, but… how many times do you have enough time to build your own CMS when you can install WP… life is short. Most of us are not building a sustainable system that will be here in next 20 years. Life is short. Deliver fast.
Post reply on HN