Comment by Julesman | Hacker News Reader

Comment by Julesman | Hacker News Reader

Parent Full thread

To me, CSS frameworks break the whole point of CSS, generally add a lot of bloat, and aren't useful except in some instances where rapid prototyping is needed.

Tailwind exists largely because programmers don't like CSS. We no longer need frameworks for compatibility. The era of browser testing is over. And we don't need them to do things CSS can't do, as in the past couple of years nearly all browsers are handling the newer features.

My big gripe is simply that it makes a lot of sense to keep your structure, styles, and scripts separated. If something looks off I don't want to have to wonder whether it's classes, CSS, or scripts.

And ultimately, I don't think Tailwind does make things faster. I could come up with custom CSS helper classes AS NEEDED, and avoid all the problems I mentioned above. And the one I didn't mention is that this makes your code look like incomprehensible garbage. Tailwind HTML files using BEM are just not OK.

Keeping my html and CSS separate make everything I do faster and lighter. Most importantly, CSS is now mature and finally does all the things for all the browser that make the frameworks just enough less useful that they become bloat.

My two cents. I'm sure Tailwind is helpful for many. But I gotta preach the basics.

A lot of people seem to approach Tailwind as a set of helper classes, but I think this is a misunderstanding of what Tailwind is doing.

It's clearer to think about Tailwind as a DSL for writing CSS directly in your templates. If that sounds like a thing you don't want to do in the first place, then Tailwind probably won't add anything useful for you, but for a lot of developers, it's a very convenient way of encapsulating style, structure (and potentially behaviour) in a single unit. You can then compose these units together to create larger systems.

Like I say, that's not the only way to develop for the web, you can also take the approach of separating out style, structure, and behaviour, and there you're not really going to see much benefit from Tailwind directly.

Specifically, I think a lot of the success of Tailwind comes from the fact that it's very agnostic about how you build your units. A lot of tools for CSS encapsulation have typically either been bound to a single framework, or at least very bound to the Javascript ecosystem. For example, CSS Modules do in many way a very similar thing to Tailwind, but they're heavily connected to the JS concept of importing and bundling - they can't easily be used in Python, for example. On the other hand, Tailwind is just text - if the Tailwind compiler finds a file where you're using its DSL, it can build the correct CSS files from that, regardless of how the file has been written. This allows you to use Tailwind from HTML, JS, but also from arbitrary custom templating formats, or even other programming languages.

I don't think Tailwind has so much to do with "basics vs helper methods". To do a lot of useful things in Tailwind, you need to know CSS in the first place, and it really is just a DSL around arbitrary CSS declarations (although the more complex those declarations become, the less pleasant Tailwind becomes to use - it is by no means perfect, or even my favourite tool for encapsulated CSS). It's more a question of how you want to write your CSS: do you want to write it coupled to HTML in components, or so you want to write it decoupled as a whole-page stylesheet?

Reply on news.ycombinator.com