Live data from Hacker News

TailwindCSS v2.0

blog.tailwindcss.com

121–130 of 474 posts

Re: TailwindCSS v2.0

#121

Tailwind smells like using a style attribute but with properties that are fewer characters. It's fully embracing what everyone said to avoid. What am I missing?

You're likely missing 2 things: 1) you probably haven't delved into Tailwind on a non-trivial project and 2) the nuanced difference is between infinite possibilities (style attribute) vs. discrete, "hard-coded" options (Tailwind classes). Think of strings vs. enum values when describing "types" in an application.

Apologies if this seems snarky but it would be far more useful if you could explain your point rather than a generic condescending "[you] haven't delved into Tailwind on a non-trivial project".

Re: TailwindCSS v2.0

#122
post #110

"Incompatibility with IE11, so you can tell the man upstairs 'sorry boss it's out of my hands, blame Tailwind'..." I know it's said tongue-in-cheek, but popular frameworks taking this stance is valuable when convincing clients, leaders, authority, etc. to not require IE support. I've consulted on dozens of front-end projects, and showing the stance of "industry leaders" is the most convincing argument.

At this point even JIRA and Microsoft 365 have dropped support for IE11. The majority of big corporates have either moved to Chrome or are hurriedly doing so. However, there are presumably old computers in far-off corners of the world that still use IE11. I wonder what will happen there...

They can continue to use IE11 for that one, weird corporate intranet app that nobody likes using anyway, and they can also load a modern browser for everything else the user has to do. Browsers don't exclude each other.

Re: TailwindCSS v2.0

#124
post #49

that video is quite aggressive.

It's so cringe i was thinking thats joke at first. I guess that happens when you invest and hire some outside help and sometimes it ends up a bit... unsophisticated? I am big Tailwind user btw.

Framework author here, yep it is a joke. We literally had the music scored for us by a friend with the goal of making it as outrageous as possible. There's a real opera singer chanting "utility first" in Latin at the end. It's a parody of itself :)

Re: TailwindCSS v2.0

#125
post #27

For those complaining about dense HTML using Tailwind, the headline feature of 2.0 should be @apply for everything: https://tailwindcss.com/docs/functions-and-directives#apply It lets you move all of those excessive class attributes into your CSS, where it realistically belongs. And that makes your CSS look a little more like CSS. But you get guard rails on it by applying a known set of properties to each rule. It's…

Yes but you shouldn't do that really. You should use a view templating system instead to recycle the patterns you spot, e.g. button.tpl would contain the abstraction of classes.

The moment you collapse the classes in to a single class you're back to square one and the reason functional CSS arose be first place.

Adam Wathan promotes this pattern himself in this video.

https://youtu.be/J_7_mnFSLDg

Re: TailwindCSS v2.0

#126
I don't do front end dev, and haven't for a very long time, but can someone help me understand how this doesn't lead to inflexible hard to maintain soup? Just to take colours, for a moment. Ordinarily I might define semantic classes, let's say "primary-nav" or "prominent-action" and apply them to relevant things (and use relative selectors for things inside them, etc.). So if I want to change the colour of all prominent-actions across my web app, I just do it in one place. This seems to be demo-ing adding a particular colour class to everything I want to be that colour. So... If I change my mind, what now? I have to find all those places and change the applied class? Search and replace?

This seems like the literal opposite of the clean separation I always understood to be the point of styling being separate to markup...

Re: TailwindCSS v2.0

#127

I've gone through the following phases: 1. Write old school circa 2008 CSS. 2. Oh shit, it's a real pain in the ass to do layout and make a responsive grid. Let me use a framework. Sweet! 3. Hmm.. its kinda painful to write css selectors all day long. They're reusable but I am having to get out of comfy JS IDE setup to go change some CSS properties in a different file. 4. Tailwind arrives. OMG. This is awesome! Never…

You can use postcss and @apply tag to compose single classes that you can use in your html code like .btn-blue .btn-blue { @apply py-2 px-5 flex items-center bg-blue-500 text-white rounded } So I don't really see that as a problem. You are supposed to refactor your styles later to be more reusable. What tailwind provides is fast iteration and design. I love that.

Everybody makes @apply out to be the eventual solution to HTML soup, and a project I'm on uses it heavily—BUT the problem is you're now completely locked into a single framework. You can't ditch Tailwind and still use @apply bg-blue-500. If you used regular CSS properties, design tokens via CSS variables, etc. it would be completely portable. I've switched entire sites from one CSS framework to another and it's challenging but doable with standard approaches. With Tailwind, good luck with that…

Re: TailwindCSS v2.0

#128
Framework author here! Don't miss the new landing page, it is probably the part I was most excited to share :)

https://tailwindcss.com/

Crazy amount of effort went into building all of these interactive examples, so proud of how it turned out.

The trailer in the blog post is absolutely 100% a joke in case it's not obvious. The music was scored for us by a friend, and that's a real life professional opera singer at the end chanting "utility first" in Latin. It's completely absurd and absolutely outrageous, just laugh at it :)

Re: TailwindCSS v2.0

#129

I don't do front end dev, and haven't for a very long time, but can someone help me understand how this doesn't lead to inflexible hard to maintain soup? Just to take colours, for a moment. Ordinarily I might define semantic classes, let's say "primary-nav" or "prominent-action" and apply them to relevant things (and use relative selectors for things inside them, etc.). So if I want to change the colour of all promin…

Tailwind is completely flexible, if you would rather have your colors be `brand-light', `brand-dark`, etc you can. Just update your config however you want.

It just comes with a config out of the box that is highly usable for any app and any need without customizing. Purge then allows you to strip out all the extra unused CSS in production.

Re: TailwindCSS v2.0

#130

Tailwind smells like using a style attribute but with properties that are fewer characters. It's fully embracing what everyone said to avoid. What am I missing?

I think one key difference is the way people are developing re-usable components now. Since you only define it once, the benefit of re-usable class names isn't as important as co-locating and scoping your CSS for ease of use. You want as little cascading as possible in that circumstance so again, traditional benefits of classes aren't as compelling.

I use a flavour of BEM naming with an approach I call Contexts and Components to achieve concise, low inheritance CSS and I can see how Tailwind can get you similar benefits and solve for some stuff traditional CSS has a hard time solving within frontend frameworks.

I am still fighting picking it up, but that is the use case I see for it, component driven workflows.

Post reply on HN