Hacker News Reader

Comment by montroser | Hacker News Reader

Tailwind is both great and terrible. The trick is to take just the good parts and not let it poison the rest. Let it make easy things easier, but don't let it take over and make the hard things impossibly difficult.

Here's how to do it: use Tailwind only for layout (margin, padding, flex) and brand consistency properties like text size, line height, colors etc. Beyond that, anything that requires changing presentation based on state, embrace CSS. It was meant for this, and remains the best solution. Invest in learning CSS because it will still be here in 20 years.

View on HN

Further down the thread I've left some lengthy comments arguing for exactly this.

There are two concerns in defining and maintaining design systems that are (so far) hard or impossible to manage well with vanilla CSS & decoupled styles:

1. Design Token & "swatching" to make integration accessible and maintainable for non-designers 2. Declaration of anything that is neither a concern of this core design system, nor part of explicitly scoped component-styles

Tailwind patches both, and this is the foundation of it's success -- the issue causing any App that relies purely on Tailwind to end up FUBAR beyond a certain scale/complexity, is that the bulk of Tailwind users seem to misappropriate those tools (specially the utility shorthands) to declare ALL the styles.

It's not completely on them either, since Tailwind needs to solve a conundrum: which utilities are meant to be utilities?

Drawing a line while retaining universal applicability is impossible, so Tailwind ended up just wrapping all of the available rules into utilities ... which then requires to extend the syntax to pass design tokens to any of those.

The result is a Framework that originated in trying to provide those 2 missing links, but ended up looking like a complete replacement of CSS.

And since these are precisely the challenges that used to be blockers for anyone whose primary scope is NOT the styling/design layer, and who therefore can't be expected to concern themselves with design system theory or good knowledge of CSS, it quickly ended up in the current ubiquity of UIs getting implemented using a misguided kind of "html style attribute only" paradigm in their entirety -- despite Tailwind originally following a much more nuanced and sensible idea.

This is refreshing to hear. The DSL provided by this plugin feels like an entire new language to learn. My experience with Tailwind has been positive but I'm not sure I want to learn new ways of doing the same things just to stay within a pure Tailwind framework.

I’m a strong advocate for Tailwind, and I believe that this approach is truly effective. In my experience, this subset of Tailwind has been sufficient for every project I've worked on that used it. Moreover, I've observed that it often converts skeptics into supporters.

Curious about your expectations: Do you rely on utility classes only in your workflow, or do you split reusable patterns into "original CSS"-like @apply blocks?

And how would you categorise the complexity of the Apps/UIs you build like this?

I'm very interested in the specifics of successful applications of Tailwind that the maintainers keep deeming a good solution, since CSS as a whole is one of my main scopes and I've had quite some projects that where basically some variation of writing custom brand-lib frameworks for teams who embraced Tailwind at first, but in time ended up hard locked when needing to refactor or iterate their UI

Great question. We rarely rely on shared utility classes these days. Historically we'd end up going the @apply route, but lately we just add a new style to the root-level css file and call it a day. We may prefix it with "@layer" so that it gets tree-shaken, but that's about it.

I've found that in component-driven UI, the need for these kinds of utility classes becomes less and less necessary. The utility CSS may be defined in the component, and the component is ultimately what gets reused.

Could you elaborate more on the reason for your interest? I've used Tailwind to implement several well-defined design languages, and always had great success. In fact, compared to other design systems, Material for example, I found it to be far simpler to manage over time.

Tailwind is CSS though? Like, it much more strongly maps to individual styles than most other popular style frameworks and systems.

This is the core fallacy though, imho: css ITSELF is already the tool for "mapping individual styles" to DOM elements.

Oldschool "CSS Frameworks" are libraries intended to bootstrap UI creation by providing abstractions of those mappings for a set of universally required UI patterns.

Tailwind pioneered the idea of "functional css" as a means to fix the "one-off classes" style bloat for anything that is NOT a specific component pattern (think "this specific archive view should be presented as a 3 column grid")

But when you end up aliasing all of CSS with such utilities, and then writing your styles to markup atts directly ... you aren't using a "framework" anymore, you simply "wrapped" most of CSS itself in a bunch of rainbow tables and littered it all over your markup, resulting in a highly illegible and unstructured style system

Can you elaborate on how to do that without duplicating style configurations?

Reply on news.ycombinator.com