Live data from Hacker News

Tailwind vs. Semantic CSS

nuejs.org

181–190 of 211 posts

Re: Tailwind vs. Semantic CSS

#181

This is a terribly done comparison and as you are the creator of the alternative framework it smells like marketing and intentionally targeting the HN audience. Your example isn't web semantic, isn't accessible, doesn't work in mobile which is from where the biggest audience connect from but you still have the courage to say that "the semantic version is 8 × smaller, renders faster, and is easier to modify and extend…

I have zero regrets/concerns claiming that the semantic version is 8 × smaller, renders faster, and is easier to modify and extend. Tailwind markup is clearly more bloated than semantic one. See: https://nuejs.org/blog/tailwind-vs-semantic-css/img/markup-b... There are many developers who agree with this. Luckily not my lonely fight :) Accessibility (attributes outside "style" and "class") are outside the topic (even…

> I have zero regrets/concerns claiming that the semantic version is 8 × smaller, renders faster, and is easier to modify and extend.

But you are wrong and your claims are misleading :)

Re: Tailwind vs. Semantic CSS

#182
post #176

I’m still looking for a lightweight solution (no react etc) that lets me write normal CSS but scoping it to an arbitrary part of my HTML tree. Most of the time I’ll be working in a partial where I know what generic names such as .container refers to And I don’t want to bother with coming up with unique names. The best I can think of is to use descendant selectors but that increases the specificity and is hard to main…

I am currently undoing nextjs out of a side project (where I spent 2 months learning react/next as it seemed like everyone knew something I didn't). I think I got pretty good at it and frankly the only useful thing I get about is it were - I think you referred to as - "isolated css". Frankly I found the whole shebang way too complicated and bloated and just was not worth being stuck to Node as a backend (I am fairly…

[deleted]

Re: Tailwind vs. Semantic CSS

#183
post #71

Earlier quoted context omitted.

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.

Yes. My point was that to "fix" a scattering of .mb-2 going astray, we often pull out even worse solutions. Making the software as a whole worse.

Re: Tailwind vs. Semantic CSS

#184

Earlier quoted context omitted.

The article focuses on Tailwind CSS vs Semantic CSS . HTML attributes, beside "class" and "style" are outside the scope. Both approaches are equally good: there is nothing extra that Tailwind provides for making websites more accessible.

It's an unfair comparison because Tailwind as a library is composed of tooling, documentation, design patterns, good practices and obviously CSS. The same is for other libraries, e.g., Bootstrap. I agree that using Tailwind--without extra effort--will end up with "meaningless" (not really) classes in the HTML. But semantics should be prioritized in HTML rather than CSS or class names. What's the benefit of having sem…

Accessibility is important. No question about it. But this article is not about the whole UI/UX stack. It focuses on benefits on what semantic CSS offers. aka "naming things" vs "not naming things".

Re: Tailwind vs. Semantic CSS

#185

Earlier quoted context omitted.

I have zero regrets/concerns claiming that the semantic version is 8 × smaller, renders faster, and is easier to modify and extend. Tailwind markup is clearly more bloated than semantic one. See: https://nuejs.org/blog/tailwind-vs-semantic-css/img/markup-b... There are many developers who agree with this. Luckily not my lonely fight :) Accessibility (attributes outside "style" and "class") are outside the topic (even…

> I have zero regrets/concerns claiming that the semantic version is 8 × smaller, renders faster, and is easier to modify and extend. But you are wrong and your claims are misleading :)

I'm actually quite relieved. I was expecting much more hate & resistance from the Tailwind community. Showing this to people who prefer the semantic approach obviously gives a whole different reaction.

Re: Tailwind vs. Semantic CSS

#186

Earlier quoted context omitted.

It's an unfair comparison because Tailwind as a library is composed of tooling, documentation, design patterns, good practices and obviously CSS. The same is for other libraries, e.g., Bootstrap. I agree that using Tailwind--without extra effort--will end up with "meaningless" (not really) classes in the HTML. But semantics should be prioritized in HTML rather than CSS or class names. What's the benefit of having sem…

Accessibility is important. No question about it. But this article is not about the whole UI/UX stack. It focuses on benefits on what semantic CSS offers. aka "naming things" vs "not naming things".

From this

> But this article is not about the whole UI/UX stack.

And this

> It focuses on benefits on what semantic CSS offers. aka "naming things" vs "not naming things".

That's the problem, you are focusing on giving semantic names to classes while giving an inferior UX on your example. If the inferior UX saves me a few KBs on size and a few milliseconds in load time, I'd still prefer good UX.

A fair comparison should be good UX with semantic CSS.

Re: Tailwind vs. Semantic CSS

#187
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.

So what does it mean? You want the structure of your HTML to say the browser, that here is anything? Does your designer just give you a design with a huge blank rectangle in the middle? When does it ever make sense?

Isn’t it much more meaningful to create a component (it can be done through a template-engine, react, whatever, that’s another point).

I mean, sure, we could just program with void pointers everywhere, but is it really a good idea?

Re: Tailwind vs. Semantic CSS

#188

Earlier quoted context omitted.

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

Then you avoid the browser, by emulating half a browser.. which is still useless, because you have plenty dynamic state you can’t test this way.

Re: Tailwind vs. Semantic CSS

#189

Earlier quoted context omitted.

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.

This is simply not true of any real-world application.

Re: Tailwind vs. Semantic CSS

#190

Earlier quoted context omitted.

The author is advocating for rules like "body > header" in separate css files.

Indeed! I'm a freak using CSS as intended :)

The problem is that CSS’s intended usage is broken, and never lived up to expectations.
Post reply on HN