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

Tailwind vs. Semantic CSS

nuejs.org

Post reply on HN
Print view View original

151–160 of 211 posts

Re: Tailwind vs. Semantic CSS

#151

Post by porridgeraisin »

It's quite simple in my view.

The "separate markup and styling" paradigm with shared css will lead to refactors having a large blast radius. When you've organised your team by mapping people -> features(components), this makes this paradigm completely unviable. Tailwind wins there, that's it.

For web apps, having separate markup and styling makes absolutely zero sense, while it does for textual, reading content like blogs.

So, web apps like to use tailwind/bootstrap.

Reaaaaalllly large web apps (e.g GitHub) swing the pendulum all the way around, and make their own little bootstrap which adheres to their design language.

Re: Tailwind vs. Semantic CSS

#152

Post by jongjong »

progx wrote: post #133
jonwinstanley wrote: post #89

Earlier quoted context omitted.

Presumably tools only get popular if people find them useful though? As in, if no-one saw value in them then no-one would use them?

People normally use not the best things, they use things they understand. Then they are so happy, that they understand it, they write blog article about it, other read it and think "it must be a good thing", then more and more use it. And if more people use it, other think "it must be a good thing, cause many use it". Self runner.

I think that doesn't adequately explain what's going on. A lot of tools that are popular are horrible to use. They just got a lot of exposure and that was enough to gain adoption.

The inequality of exposure of projects is massive and hard to overstate. Even if a bad project is exposed to 10 million developers over a few months, it will become a standard.

On the other hand, a project which only got 100K views over 10 years will never be adopted no matter how good it is. People can talk about how good it is, but that doesn't matter at all; the only thing that matters are the algorithms used by the big tech platforms and they have all been corrupted.

Re: Tailwind vs. Semantic CSS

#153

Post by philreinking »

I think we all can agree that this article is not based on a proper comparison between Tailwind CSS and what the author calls “semantic CSS”. I understand, from authors’ comments here, that it does not aim to be a perfect copy. But arguing that it is 1-3% off, is just BS.

The big problem for me, that the author also argues that the Tailwind CSS version is an official template and, therefore, it has to follow best practices.

I think this logic is flawed, since in production (and especially if I sell templates online) I aim for readable code, which may result in more markup used. Anyone, who knows Tailwind CSS well, could copy the author’s version of the site with the same HTML markup and achieve the same output. Only then it would be a fair comparison, and I bet the results would not be the same at all.

Re: Tailwind vs. Semantic CSS

#154

Post by tipiirai »

porridgeraisin wrote: post #151

It's quite simple in my view. The "separate markup and styling" paradigm with shared css will lead to refactors having a large blast radius. When you've organised your team by mapping people -> features(components), this makes this paradigm completely unviable. Tailwind wins there, that's it. For web apps, having separate markup and styling makes absolutely zero sense, while it does for textual, reading content like…

Again. This is purely a matter of taste. I personally prefer the semantic approach.

Re: Tailwind vs. Semantic CSS

#155

Post by tipiirai »

philreinking wrote: post #153

I think we all can agree that this article is not based on a proper comparison between Tailwind CSS and what the author calls “semantic CSS”. I understand, from authors’ comments here, that it does not aim to be a perfect copy. But arguing that it is 1-3% off, is just BS. The big problem for me, that the author also argues that the Tailwind CSS version is an official template and, therefore, it has to follow best pra…

I'm arguing that Tailwind requires _significantly_ more markup to produce the same look and feel. There is no way anyone could implement the semantic version with less code using TW.

And I personally find less code more readable than more code. Particularly with Tailwind where the difference can be 10x or more. I'm talking about this real-world scenario:

https://nuejs.org/blog/tailwind-vs-semantic-css/img/markup-b...

Re: Tailwind vs. Semantic CSS

#156

Post by porridgeraisin »

tipiirai wrote: post #154
porridgeraisin wrote: post #151

It's quite simple in my view. The "separate markup and styling" paradigm with shared css will lead to refactors having a large blast radius. When you've organised your team by mapping people -> features(components), this makes this paradigm completely unviable. Tailwind wins there, that's it. For web apps, having separate markup and styling makes absolutely zero sense, while it does for textual, reading content like…

Again. This is purely a matter of taste. I personally prefer the semantic approach.

Of course. From each person's POV, it is a matter of taste.

But in real life, in the 80% case, a true software "team" doesn't exist. Instead, you have a bunch of individuals working on a product, who won't be ready to fix issues in another person's feature.

It is very common to map features/components to people when managing software teams, in the obvious case with react,etc, and even in Ruby on rails type stuff to a certain extent.

From a political point of view, aaas much as possible, you want changes to page A, to only involve pageToPerson.get(A).

So, the first thing companies want to avoid is people stepping over each other. Again, healthy collaboration does not exist in the 80% case.

It's the same pattern with other things that are questionable from a technical point of view.

- using docker, microservices, etc where not required, so no cross-team, common dependencies, or even common database in the extreme case. - making each part of your codebase its own npm package

N.B

My definition of "exist" is "present and dependable upon to such an extent you will risk your job on it".

Re: Tailwind vs. Semantic CSS

#157

Post by philreinking »

tipiirai wrote: post #155
philreinking wrote: post #153

I think we all can agree that this article is not based on a proper comparison between Tailwind CSS and what the author calls “semantic CSS”. I understand, from authors’ comments here, that it does not aim to be a perfect copy. But arguing that it is 1-3% off, is just BS. The big problem for me, that the author also argues that the Tailwind CSS version is an official template and, therefore, it has to follow best pra…

I'm arguing that Tailwind requires _significantly_ more markup to produce the same look and feel. There is no way anyone could implement the semantic version with less code using TW. And I personally find less code more readable than more code. Particularly with Tailwind where the difference can be 10x or more. I'm talking about this real-world scenario: https://nuejs.org/blog/tailwind-vs-semantic-css/img/markup-b...

The intention is clear, but you are exaggerating your argument by comparing a plane with a car. The Tailwind example is a much more feature complete product, then your „lightweight“ copy. Also, as I said it might be written with another intention then being super small. You use body > header > nav > a. You could write an example in Tailwind that uses the same markup structure, which then would be a valid starting point for an article like this, despite I assume you could not come up with the same conclusions.

Re: Tailwind vs. Semantic CSS

#158

Post by tempmac »

sbergot wrote: post #148
tempmac wrote: post #127

Earlier quoted context omitted.

hmm maybe IDE plugins can solve this? (eg. add a 'hover to show css' or 'expand css if I press ctrl+alt') as for tailwild, I just can't bare its wide-ness - too many className attribute string going over 150~300 char widths, with some ternary operators mixed on top... (seems vanilla-extract / ete have better DX, with occasional inlining for immediate deadlines)

The only way to know is to go to the page and inspect it using devtools. No Ide will be able to infer which rule is going to apply to any given element. But the problem is that you need to make sure that a given css change is going to affect only a specific set of component. So you need to check all components. Since it will be too time consuming, you will probably skip this step and hope for the best (and do some QA…

hmm it might be possible with enough tooling:

- read from webpack's output

- read from css-in-js: emotion / vanilla-extract / etc

Re: Tailwind vs. Semantic CSS

#159

Post by tipiirai »

sbergot wrote: post #109
tipiirai wrote: post #54

Earlier quoted context omitted.

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.

It is still coupled because the css will need to know the html structure in order to work. If you update the html, you probably need to update the css.

It is _loosely_ coupled. I can switch the design completely without touching HTML.

If I modify the HTML structure, the component specification changes and CSS obviously needs to be updated.

Re: Tailwind vs. Semantic CSS

#160

Post by flagrant_taco »

Timon3 wrote: post #118
bryanrasmussen wrote: post #98

Earlier quoted context omitted.

>Similarly, I haven't seen a pattern where good CSS authors do not like Tailwind. well I haven't used Tailwind but from the examples I've seen I would hate it, and from what I can see I would hate it for the same reason that I hate all CSS abstractions I've worked with - because they limit what I can do with CSS in the interest of making it easier for other people who are not that good with CSS to get their work done…

> well I haven't used Tailwind but from the examples I've seen I would hate it, and from what I can see I would hate it for the same reason that I hate all CSS abstractions I've worked with - because they limit what I can do with CSS in the interest of making it easier for other people who are not that good with CSS to get their work done OR it will require me to do things in a particular way when I believe I know a…

There are a few important limitations, Tailwind can't fully support logical properties for example because `mb-8` could mean margin bottom or block. Any use case that requires styling one element based on another gets a bit hairy too.

Both of these can be technically worked around. Config may be able to disable existing margin/padding classes and replace them with a custom set, and the groups feature helps especially for simple cases of referencing other elements.

In my experience though, as soon as config is meaningful modified or you elan on the more obscure features for groups, pseudo selectors, etc. the learning curve has just been moved from the dev who doesn't know CSS to the dev who doesn't know Tailwind.

Post reply on HN