Hacker News Reader

Comment by victorbjorklund | Hacker News Reader

That is pretty much what it has always been. The reason I like it is

1) it is more standardised (since it is written in html rather than custom classes) which means you can pretty much copy a component from one project to another without worrying that maybe the css naming overlaps etc. It just works.

2) it limits the decisions you need to make. No need to decide exactly how many pixels the padding should be. Just pick p-4. And if that is too much take p-3.

3) You dont need to worry that something in a totally different part of the app will break if you change the css to change the styling of a component

4) It is just faster to write and in my opinion easier to reason about (im sure this is personal) since I can see directly in the html what styling is applied and i dont need to go and dig in different stylesheets to find out what "custom-button-large" does

View on HN

Except for 2, I think these points could similarly advocate for just using the `style` attribute. Even then, `1em` is a pretty good "default" for "I just want padding" in vanilla CSS.

Or SCSS variables. Which is what I’ve gone back to after a brief love affair with Tailwind.

Not bashing Tailwind. It’s amazing. But I found myself making thatsamefuckingwebsite.com again and god damn if I didn’t want something to look different.

And as soon as you’re writing your own CSS, you might as well just write your own CSS.

Like literally the first time you write your own particularly uniquely styled component and have to mash your own classes in with Tailwind’s you think, hang on, why don’t I just…

Edit: like this site. Just found it via elsewhere. https://www.usebubbles.com/ First thought: justanotherfuckingtailwindwebsite.com

You can change Tailwind configuration. For example, it's entirely possible to design 1:1 iOS-like UI using Tailwind with custom style config. The default style is overused, but it's cool to have a pretty base for small projects that don't have their own corporate identity yet.

I would argue that the tailwind.config is actually the single most important feature tailwind has. Making the framework your own and being locked to your style guide is fantastic.

Yes, fully agreed. I saw someone call it "the API for your design system".

inline css does not allow for pseudo selectors like "hover:". It does not allow media queries either. Browser are also slower to process them. So there are a few good reasons to use tailwind appart from standardization of spacing and colors.

The real benefit of TW comes from the configuration. You never need to put actual values into your class names like you would with inline styles. For example, let's say you have a specific background color. You define it in the TW configuration, and TW generates a specific class for that color. So, instead of doing `style: background-color: "#123456"` a thousand times, you do `class="bg-my-color"`, and if you want to change what `bg-color` is you just change it in one place.

That’s just CSS variables, you don’t need Tailwind for that.

I’m our use, we have a hardcore design system that our designers use to build designs. Our Tailwind config is exactly set to the values in that design system. This takes the padding values from being any value to only sizing valid in the design system, generally p-1 or p-2 for anything smaller. This lock-in really helps make things consistent.

Tailwind is similar to using the style attribute directly, but it’s got a less verbose syntax and it buckets the possible style values for a more consistent result.

Reply on news.ycombinator.com