Live data from Hacker News

Tailwind vs. Semantic CSS

nuejs.org

71–80 of 211 posts

Re: Tailwind vs. Semantic CSS

#71

I just moved our website from semantic to tailwind after I didn’t understand the semantic bits anymore. Main problem was: the semantic css was elegant, but understanding it again after half a year of not editing the page took super long. Tailwind is clear. The code looks uglier but I instantly know what’s going on. No hidden things. And no fear in editing a piece of html that it will break sth else. Huge upside.

Copy paste for styling isn't as bad as it sounds. Obviously with React you get components you can reuse. But manually chucking out mb-2, mx-2, my-3 to get it to look nice to the eye and having the same things repeat in different spots without a "meaning" or "semantics" can be quite nice. For small-medium size projects of course.

That quickly falls apart when I add an mb-2 to a Thingy, but fail to check that Thingy is also used inside SideThings (which we all forgot existed at all) wich already has whitespace (but somehow uses mt-2 because the developer preferred to declare intermediate whitespace at the top instead of the bottom). So when the communication dept calls me on friday, I add quickly add an #main div.nth-child(2).mb-2 { margin-bottom: 0 !important } to overrides.css and call it a day.

Point being: manually sprinkling mb-2s throughout your codebase is a recipe for disaster: an sure way to an unmaintainable frontend.

Re: Tailwind vs. Semantic CSS

#72

Earlier quoted context omitted.

The Tailwind markup vs Semantic markup example just straight sucks. - There are useless empty elements in the tailwind example - There are so many different breakpoints, paddings and margins in the depths of the tailwind DOM, that can not be achieved with the minified semantic markup as it is simply lacking the DOM structure necessary for it. Substituting just html > body > header > nav > a with html > body > div > d…

Bear in mind that the Tailwind example is the official template made by the Tailwind developers themselves. It is the prime example of Tailwind and it's benefits and best practises. (Should be at least)

Why do you think this example is supposed to be the pinnacle of what the most performance and optimized tailwind can be?

Re: Tailwind vs. Semantic CSS

#73
post #52

Earlier quoted context omitted.

This section is what I am talking about. You compare two methods of writing components and then declare that the tailwind version is tightly coupled but the semantic version is loosely coupled. In programming lingo this means tailwind is bad and semantic is good. But you don't explain why the tailwind version is tightly coupled and the semantic version is loosely coupled. And you don't do it because it is simply not…

So ` ` is loose coupling, because the styling is not coupled directly into the element. You can completely switch the gallery design, by switching (or overriding, or modifying) the external stylesheet.

I have rarely seen this work in practice in 20 years of CSS, but maybe in CSS Zen Garden. Yes, you can freely change the CSS. But usually changes are triggered by the HTML, like some information is added. This then requires you to change the CSS and likely break all sorts of other uses, which is not a problem with Tailwind.

Re: Tailwind vs. Semantic CSS

#74

Tailwind excels when it’s used on reusable components. Anyone handcoding Tailwind for a full page will start to hate it quickly. But you can have the best of both worlds with apply: .card { @apply p-2 rounded shadow text-gray-700; }

Exactly. This is a non-issue if you use @apply (as people should).

But if you make extensive use of @apply then you're just writing normal CSS with an unnecessary preprocessing step.

Re: Tailwind vs. Semantic CSS

#75

Tailwind excels when it’s used on reusable components. Anyone handcoding Tailwind for a full page will start to hate it quickly. But you can have the best of both worlds with apply: .card { @apply p-2 rounded shadow text-gray-700; }

Exactly. This is a non-issue if you use @apply (as people should).

@apply is an antipattern.

Re: Tailwind vs. Semantic CSS

#76
post #23

In my experience, it isn't black or white. I've used tailwind along with components, e.g. .button-primary { @apply rounded-full focus:ring focus:ring-orange-500 ring-offset-4 outline-none px-6 py-3 etc... and it gives you the best of both worlds. You refactor common css code into components and still have the amazing flexibility of utility classes.

This is not the best of both worlds. This is an antipattern and discouraged by the Tailwind core team and the Tailwind community at large.

Re: Tailwind vs. Semantic CSS

#77
> Where is the source code? > I’m working on it!

Presumably the author must have already written the code in order to draw the conclusions in the article.

Not releasing this code, makes me question (1) the conclusions, and (2) whether the HN comments will prompt him to update the code, but not the article or conclusions.

The author mentions "not wanting the overhead of an open source project" to delay publication, which doesn't make a whole lot of sense to me. Code in support of a blog post isn't something that would require ongoing effort, or even documentation.

Re: Tailwind vs. Semantic CSS

#78
post #71

Earlier quoted context omitted.

Copy paste for styling isn't as bad as it sounds. Obviously with React you get components you can reuse. But manually chucking out mb-2, mx-2, my-3 to get it to look nice to the eye and having the same things repeat in different spots without a "meaning" or "semantics" can be quite nice. For small-medium size projects of course.

That quickly falls apart when I add an mb-2 to a Thingy, but fail to check that Thingy is also used inside SideThings (which we all forgot existed at all) wich already has whitespace (but somehow uses mt-2 because the developer preferred to declare intermediate whitespace at the top instead of the bottom). So when the communication dept calls me on friday, I add quickly add an #main div.nth-child(2).mb-2 { margin-bot…

Until someone else edits your code and doesn't understand why the layout suddenly broke. nth-child(2) is very prone to this.

Re: Tailwind vs. Semantic CSS

#79
post #2

Author here. I implemented the commercial Tailwind "Spotlight" template with Semantic CSS and compared the differences in weight, amount of HTML and CSS, rendering speed, and best practices. I was surprised to find _that_ much overhead in Tailwind. Curious to hear your thoughts.

Hello, well done on your article!

I have a few questions:

- What exactly do you mean by "Semantic CSS"? I've never heard this terminology before (might just be OOTL). I get the parallel between this and Semantic HTML, but I guess it's not as clear what it is supposed to mean for a styling language to me. Is it just native CSS (or "pure" CSS)? At least, as a result, I have no idea what this means, or by what measures you decided what constitutes "semantics" in Tailwind's CSS:

  The most surprising thing is that Tailwind uses more global/semantic CSS than the semantic approach itself ¯\_(ツ)_/¯
- A small nitpick, maybe: could you somehow replace the top links to the two versions you compare with actual HTML links instead of JS events? This prevents middle-clicking and the location is replaced so it's tough to compare the two sites while reading your article. I have to click on your link, copy the url, and open that in a new tab. At least, opening the page in a new tab would be nice.

Re: Tailwind vs. Semantic CSS

#80
post #71

Earlier quoted context omitted.

Copy paste for styling isn't as bad as it sounds. Obviously with React you get components you can reuse. But manually chucking out mb-2, mx-2, my-3 to get it to look nice to the eye and having the same things repeat in different spots without a "meaning" or "semantics" can be quite nice. For small-medium size projects of course.

That quickly falls apart when I add an mb-2 to a Thingy, but fail to check that Thingy is also used inside SideThings (which we all forgot existed at all) wich already has whitespace (but somehow uses mt-2 because the developer preferred to declare intermediate whitespace at the top instead of the bottom). So when the communication dept calls me on friday, I add quickly add an #main div.nth-child(2).mb-2 { margin-bot…

> #main div.nth-child(2).mb-2 { margin-bottom: 0 !important } to overrides.css and call it a day

And then 100 times doing the same later... We all know how it ends up looking because we all did it.

Post reply on HN