Hacker News new | ask | show | jobs
by dna113 2784 days ago
Lol here we go again. Why does this get people so riled up?

I suspect people who immediately dislike this maybe are not using some type of component-based UI. CSS classes are all about code-reuse. If you have the concept of say a "button" in your UI, and you are copying your button markup every where you use that "button" then it certainly makes sense to have a class for your button markup that encapsulates the styles for that button in a style sheet somewhere.

If using a button component however, you've already created a place for the concept of your button to exist. At that point if you go on making a class in some style sheet that also represents the concept of your button, now your button concept exists in multiple places, linked together by one or several class names. That seems a lot messier to me than using utility first styles, but I don't think it really makes a huge difference one way or another.

4 comments

It's easy to understand why it gets people "riled up." For 20+ years the entire industry has been pounding the table about why inline styles are so bad. Thousands of articles have been written espousing this idea, and likely hundreds of thousands of hours have been spent devising better alternatives in the form of CSS frameworks.

Whether Tailwind is functionally and pragmatically better than inline styles isn't even important. It looks like inline styles, so the first reaction of almost any experienced designer/developer that looks at it is to make that association and squirm in discomfort at its mere appearance.

After doing a project with this I think Tailwind is great! There is no need to choose either BEM or Tailwind, they can co-exist in the same project and they both makes a lot of sense (for different use cases). Typically, I’ll start with tailwind classes and extract simple tailwind components when those classes start to repeat. If the component is clearly reusable and has enough complexity, I’d switch to BEM.
This can easily be accomplished with SASS and a methodology like BEM. And it makes the markup a lot easier to read.
If you prefer that great, which is why I said that I don't think it makes a huge difference one way or another.

.i-dont__find-bem--very-readable.

Sass makes it a lot nicer to write BEM notation. The long class names used to bother me too, but it is actually much nicer than not knowing where a class came from. Is `.right-button` a global button style, or unique to this component?
I agree that sass enables nice readable BEM, but I don't really think that BEM makes markup any easier to read than something like tailwind.

If you're into knowing where your class came from, it seems tailwind would be even better for you because now you have access directly to your styles right there in your markup. Skip the class step altogether!

Wouldn’t you know that if the Sass is indented?

I treat my name spacing the way I do in most source code. All the code for a unit is in the same file or in files called out from that file.

If you’re not nesting in Sass you’re missing out on some of the better parts.

after doing a project with tailwind I have completely abandoned the idea of BEM. while it was nice having clean classes, having the styles directly in the html is way easier to reason about.
We're back to filling in style attributes on each tag, aren't we?
Not quite, because you can still define thematic defaults and change those globally to suit any changes to your style book.
I have the same experience. After working four years with BEM, we switched to atomic css. We only use BEM for big components. It has been a delight.
If you're interested, I wrote a short blog post recently with some very similar thoughts on the role of classes vs inline CSS in the component paradigm.

https://medium.com/@davnicwil/how-i-learned-to-stop-worrying...

Tldr: for me, classes make more sense for reuse in simpler content-heavy scenarios. For anything remotely complex or webapp-like, I think they are the wrong abstraction.