Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Working with Tailwind CSS every day for 2 years

themosaad.com

Post reply on HN
Print view View original

121–130 of 215 posts

Re: Working with Tailwind CSS every day for 2 years

#121

Post by zupa-hu »

I think Tailwind is great but I agree with many of the issues raised.

I desperately needed a _language_ instead of a framework back when Tailwind was still a framework. As I could not get any response from them, I ended up rolling my own called Turbo CSS - this was like 2 years before their compiled version came out. Take a look if you want to consider alternatives.

https://developer.boomla.com/turbo-css

I'd compare the two as Tailwind being primarily a framework, a language second, while Turbo is a language first. For example, in Turbo you write libraries and reference class names in libraries via `my.btn` instead of polluting the global namespace. It also has first class support for classes, like you can do `hover:my.btn`, which Tailwind doesn't support (to my best of knowledge, it definitely didn't back then). Also, Turbo has zero global side-effects, which makes it great if you don't control the entire codebase (think CSS reset).

Re: Working with Tailwind CSS every day for 2 years

#122

Post by danielvaughn »

pupppet wrote: post #113
danielvaughn wrote: post #111

Earlier quoted context omitted.

I'm sorry but this is just a crazy thing to say. You cannot use Tailwind without understanding CSS. Take the example `block`. Ok so a junior FE dev is supposed to use this class without understanding CSS? How?! It just maps to `display: block;`. It hides literally none of the complexity.

>It hides literally none of the complexity. If it didn't hide any of complexity you'd be writing CSS.

Nope, it saves me (a) keystrokes and (b) design effort. The restricted subset of color options, for example, lets me use a predictable color system out of the box without having to think about it. It's not about removing "complexity" in the sense of understanding how CSS works.

Re: Working with Tailwind CSS every day for 2 years

#125

Post by naasking »

adwww wrote: post #35
734129837261 wrote: post #22

I hate Tailwind with the passion of a million suns. It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test. The best arguments against it: 1. Spamming utility classes causes horrible git commits, git history, git difference checks; 2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted; 3. Rep…

I'm not super up to date with frontend development trends, but when I used it recently it really went against everything I've ever been taught about separation of concerns. Like, I thought we were supposed to keep our content and styles separate, not mismatch them all together with a thousand utility class imports.

Consider whether those lessons were actually informed by evidence. Tailwind is not like inline CSS, the latter has a number of downsides because it doesn't permit you to access all of CSS, where Tailwind does.

Re: Working with Tailwind CSS every day for 2 years

#126

Post by atsjie »

eiiot wrote: post #80
734129837261 wrote: post #22

I hate Tailwind with the passion of a million suns. It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test. The best arguments against it: 1. Spamming utility classes causes horrible git commits, git history, git difference checks; 2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted; 3. Rep…

> Spamming utility classes causes horrible git commits, git history, git difference checks; As opposed to what? This is still an issue with any kind of utility class, where the alternative is inline styles or CSS-in-JS, both of which are substantially worse. > Conflicting utility classes aren't clear, and sometimes the order cannot be trusted; This is fixed in the IDE with tools like ESLint. I have VSCode setup to au…

> if you use tailwind correctly (with @apply) you only have to update it once.

"Whatever you do, don’t use @apply just to make things look “cleaner”. Yes, HTML templates littered with Tailwind classes are kind of ugly."

That is straight from the Tailwind docs: https://tailwindcss.com/docs/reusing-styles

Using @apply a lot just reinvents CSS; that's not the point of Tailwind.

I can write similar comments about the rest of your statements, but I think you're too narrow minded to accept any input so I won't bother.

Re: Working with Tailwind CSS every day for 2 years

#127

Post by mgkimsal »

danielvaughn wrote: post #108
waboremo wrote: post #98

Earlier quoted context omitted.

Because Tailwind is often suggested as a way for novices to implement design without having to really learn CSS. Simultaneously, allows people who don't care at all for CSS or design to create something functional. Tailwind does not require knowing CSS. It'll get you around tailwind faster if you do know it, but you do not have to care about what Tailwind is really up to when adding "outline outline-2 p-4 outline-off…

Tailwind absolutely requires knowing CSS. You cannot effectively use `outline-2` without understanding what an outline is.

Millions of people know what an 'outline' is without knowing what CSS is. You might need a better example than 'outline'.

Re: Working with Tailwind CSS every day for 2 years

#128

Post by danielvaughn »

mgkimsal wrote: post #127
danielvaughn wrote: post #108

Earlier quoted context omitted.

Tailwind absolutely requires knowing CSS. You cannot effectively use `outline-2` without understanding what an outline is.

Millions of people know what an 'outline' is without knowing what CSS is. You might need a better example than 'outline'.

They can't explain the difference between an outline and a border though, and especially can't explain when to use which. If you try to use Tailwind without understanding that, you're gonna have a Bad Time™.

Re: Working with Tailwind CSS every day for 2 years

#129

Post by dimmke »

mind-blight wrote: post #102
karaterobot wrote: post #58

Earlier quoted context omitted.

Pretty much every CSS framework I've ever seen (and certainly every CSS-in-JS solution I've ever seen) has as its underlying premise "we know you hate CSS, and want to avoid thinking about it as much as possible". For people like me (and perhaps you) who actually like CSS, our reaction is "why would I ever want to use something that abstracts away the power and flexibility of a thing I enjoy using?" The problem is th…

I actually think a lot of CSS-in-js frameworks became popular for the same reason that React became popular: css, html, and to some extent JavaScript can't really be decoupled. Things like CSS Zen garden made it seem like they were, but that was only a separation of control. If the HTML structure changes, then the CSS likely needs to change. That's a tight coupling. CSS-in-js embraces the coupling and makes it explic…

Agreed. I think he's completely misidentified why CSS-in-JS became a thing.

I've done a lot of thinking about this - like "How would we adopt what we have done in frameworks into web standards"? And the closest I have come up with is Svelte.

In Svelte your file is a component. It can have a tag which defines state that can be passed to it or any other arbitrary javascript. You can have a tag which scopes specifically to that component. And the rest is just regular HTML markup with the ability to do light interpolation for dynamic values.

That's how it should be, in my opinion. That's what we should be moving towards as an industry. I think CSS-in-JS was a side effect of JSX being in JavaScript. Hopefully we are moving away from that trend now.

Re: Working with Tailwind CSS every day for 2 years

#130

Post by atsjie »

adwww wrote: post #35
734129837261 wrote: post #22

I hate Tailwind with the passion of a million suns. It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test. The best arguments against it: 1. Spamming utility classes causes horrible git commits, git history, git difference checks; 2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted; 3. Rep…

I'm not super up to date with frontend development trends, but when I used it recently it really went against everything I've ever been taught about separation of concerns. Like, I thought we were supposed to keep our content and styles separate, not mismatch them all together with a thousand utility class imports.

This has changed a number of years ago.

Basically it's a component-mindset; create some file with everything in it so that in the rest of the app you can just use `...`.

The `` file takes responsibility for everything it does (logic, handlers, markup, style).

However; this does not mean these files should grow large. Instead when things become too big (say over 250 LoC) you split up responsibilities by sub-components.

It's basically dividing problems in ever-smaller problems, but NOT by separating by technology (html/css/js).

Separation of concerns is horizontal slicing of the app architecture, components however slice the architecture vertically.

Post reply on HN