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

201–210 of 211 posts

Re: Tailwind vs. Semantic CSS

#201

Post by quickthrower2 »

berkes wrote: post #183
earthnail wrote: post #78

Earlier quoted context omitted.

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.

Hacks like this exist in non-tailwind projects where the classes have lost all meaning and the CSS is in a messy state.

On the other hand, in tailwind you could organize things well using your template/component system, be that ReactJS, Vue, ERB, EJS, CSHTML etc.

I agree there is subtlety though. A well organized and "benevolent dictator-ed" crop of CSS files is going to be more powerful than it's Tailwind equivalent due to having selectors etc. available.

Re: Tailwind vs. Semantic CSS

#203

Post by willdr »

arzke wrote: post #88
willdr wrote: post #76

Earlier quoted context omitted.

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.

Actually, the docs says it's perfectly fine to use @apply for highly reusable components like buttons and form controls: https://tailwindcss.com/docs/reusing-styles#avoiding-prematu...

Did you continue reading?

> even then only if you’re not using a framework like React where a component would be a better choice.

Re: Tailwind vs. Semantic CSS

#204

Post by MaxArt2501 »

sbergot wrote: post #111
HelloNurse wrote: post #68

Earlier quoted context omitted.

The coupling is in the right direction: designing possibly very advanced CSS to get a desired appearance from a given good markup, instead of compromising markup to simplify CSS.

The issue of this direction is if you need to update the markup, you will need to update the css, which is hard and risky because of css global scoping.

I can't, for the sake of me, understand how some frontend devs still complain about CSS' global scope when style encapsulation exists and is widely adopted in a form or the other, either native (Shadow DOM) or emulated.

You don't like global styles? Don't use global styles, period.

Even without adopting Nue and staying on React, CRA and Next comes out with CSS Modules out of the box. Angular and Vue have their own equivalent.

Re: Tailwind vs. Semantic CSS

#205

Post by tipiirai »

meiraleal wrote: post #196
tipiirai wrote: post #185

Earlier quoted context omitted.

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.

Do you see what I'm saying? You expected hate. You wrote it with the expectation of causing a reaction so you framed it in a way that could cause reactions to promote your framework as all your previous (also polemic) posts. This is against HN guidelines. > Please don't use HN primarily for promotion. It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity.

I mean that Tailwind cricitcisim gets heated very easily

Re: Tailwind vs. Semantic CSS

#206

Post by bryanrasmussen »

flagrant_taco wrote: post #160
Timon3 wrote: post #118

Earlier quoted context omitted.

> 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…

that is also a thing, when I look at tailwind, having spent my time learning CSS why would I want to learn another syntax to help me do what I can already do, and probably do better.

Re: Tailwind vs. Semantic CSS

#207

Post by HelloNurse »

sbergot wrote: post #146
HelloNurse wrote: post #126

Earlier quoted context omitted.

New and updated CSS rules should be usually needed for new "themes", exactly the type of change that semantic markup is robust against (e.g. placing image captions in a sidebar rather than below the respective images), and for backwards compatible extensions of the original design that add support for something new that will only be used in new markup in new pages (e.g. allowing small images inside paragraphs, meant…

A lot of applications have a long lifetime. They are not shipped only once. If I want to add a new feature, say allow users to perform a new operation in an existing screen, I will have to update a few components for this. You want to preserve the theme an consistency of the UI, but adapt its functionality. For this type of changes the semantic version is problematic.

Ordinary changes fall within the boundaries of the existing design system: for example, "a new operation in an existing screen" probably means adding instances of a few existing components (button, paragraph, title, section, pop-up submenu, etc.), with no impact on styles, not "updating" components.

Re: Tailwind vs. Semantic CSS

#208

Post by thom »

martypitt wrote: post #108
thom wrote: post #39

Earlier quoted context omitted.

I’ve found myself wanting a Tailwind compiler that makes it easier to work like this. Iterate fast with maximum verbosity, but later extract common patterns to classes when things are more stable. Anyone aware of any tooling like this?

I love that idea, and would definitely use it. In fact, if there's enough interest, I'd probably build it too...

Go for it! At the very least there are some interesting algorithmic problems in there. I was leaning towards calling it "Leaf Blower", because it's a form of wind that tidies things up. Take it or leave it. :P

Re: Tailwind vs. Semantic CSS

#209

Post by tobr »

sbergot wrote: post #142
tobr wrote: post #125

Earlier quoted context omitted.

Both of them need to conform to the same allowed patterns of markup. I think we lack a kind of markup schema or type system that everything can be validated against, where we can verify that our design takes every state and permutation into account, and that both styling and content implements their part of it correctly.

tailwind doesn't need to know anything about your components.

[delayed]

Re: Tailwind vs. Semantic CSS

#210

Post by TheHiddenSun »

Author is using tailwind wrong

Complaining about a technology (tailwind) while not using its surrounding ecosystem is not really a good way to build things.

How to do it:

- encapsulte/extract react/jsx components - for readability, so you do not have a wall off endless meaningless divs. Examples: Article, ArticleHeader, ArticleContent, ArticleSummary, etc...

- use cva https://github.com/joe-bell/cva to style generic ui components (like buttons) to archive same grouping as in semantic css

- use https://github.com/dcastil/tailwind-merge to merge/overwrite tailwind classes (like in css)

- result: separated react/jsx components with only a few lines of tailwind classes - are very readable and easily maintainable

Post reply on HN