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

Tailwind CSS v4.0

tailwindcss.com

Post reply on HN
Print view View original

251–260 of 296 posts

Re: Tailwind CSS v4.0

#251

Post by [deleted] »

aembleton wrote: post #145
vim-guru wrote: post #119

CSS has become significantly more user-friendly than in the past, with most browsers now behaving consistently. It's worth learning as there is no build step involved, and it avoids cluttering your markup with excessive code. You could opt to use style attributes directly within your HTML. Historically, we avoided this to maintain a separation of concerns, but it's puzzling why some prefer reintroducing similar metho…

> I simply don't see the appeal. - Not having to name CSS classes - Easier to read as it's inline with the rest of your HTML - Standardised way of naming so that everywhere uses the same conventions - Not having to manage a separate file and remove unused components - Being able to use media queries, which I couldn't do in a style tag - No risk of changing a class that is used elsewhere. CSS has global scoping which…

[deleted]

Re: Tailwind CSS v4.0

#252

Post by lenkite »

tipiirai wrote: post #64
jaredcwhite wrote: post #39

As a once-strident critic of Tailwind for its many failings and incompatibilities with the state of the actually-modern "vanilla" web art, I am very pleased to see the huge strides they've made with v4. Being able to access the Tailwind theme through native CSS variables (they even have an example in the docs of a button component written in native CSS in an external stylesheet using native variables! Oh happy day!)…

> I suspect many of the pro/anti-Tailwind arguments are no longer relevant I feel there are two issues with Tailwind for me as a designer / design engineer. * First, JavaScript/Tailwind engineers have hijacked the conversation on design. Instead of "utility-first," "dead code elimination," and "type-safe CSS" I focus more on desing systems. Whether to use Perfect Fifth or Perfect Fourth in typography for example. * S…

Man their very playground at https://play.tailwindcss.com/ gives this unreadable crap (sorry for swearing) for the very first `div` on the first line:

    relative grid min-h-screen grid-cols-[1fr_2.5rem_auto_2.5rem_1fr] grid-rows-[1fr_1px_auto_1px_1fr] bg-white [--pattern-fg:var(--color-gray-950)]/5 dark:bg-gray-950 dark:[--pattern-fg:var(--color-white)]/10
How can anyone prefer this gobbledygook over a nice CSS class declaration with line-separated standard CSS properties ? How can one even maintain this ?

Maybe the modern generation of web developers have IQ 200 and 20/20 vision with eidetic memory and I should just put myself to pasture.

Re: Tailwind CSS v4.0

#253

Post by orf »

lenkite wrote: post #252
tipiirai wrote: post #64

Earlier quoted context omitted.

> I suspect many of the pro/anti-Tailwind arguments are no longer relevant I feel there are two issues with Tailwind for me as a designer / design engineer. * First, JavaScript/Tailwind engineers have hijacked the conversation on design. Instead of "utility-first," "dead code elimination," and "type-safe CSS" I focus more on desing systems. Whether to use Perfect Fifth or Perfect Fourth in typography for example. * S…

Man their very playground at https://play.tailwindcss.com/ gives this unreadable crap (sorry for swearing) for the very first `div` on the first line: relative grid min-h-screen grid-cols-[1fr_2.5rem_auto_2.5rem_1fr] grid-rows-[1fr_1px_auto_1px_1fr] bg-white [--pattern-fg:var(--color-gray-950)]/5 dark:bg-gray-950 dark:[--pattern-fg:var(--color-white)]/10 How can anyone prefer this gobbledygook over a nice CSS class d…

Terrible take.

Take a guess at what “dark:bg-gray-950”, “bg-white” or “min-h-screen” means. You get them from context.

Imagine if you put a little bit of effort into learning Tailwind. You’d get the more complex declarations as well.

As to why it’s better than a class declaration, a lot has been written about using atomic, composable utility classes over reams of “write-once” class declarations.

Re: Tailwind CSS v4.0

#254

Post by lenkite »

orf wrote: post #253
lenkite wrote: post #252

Earlier quoted context omitted.

Man their very playground at https://play.tailwindcss.com/ gives this unreadable crap (sorry for swearing) for the very first `div` on the first line: relative grid min-h-screen grid-cols-[1fr_2.5rem_auto_2.5rem_1fr] grid-rows-[1fr_1px_auto_1px_1fr] bg-white [--pattern-fg:var(--color-gray-950)]/5 dark:bg-gray-950 dark:[--pattern-fg:var(--color-white)]/10 How can anyone prefer this gobbledygook over a nice CSS class d…

Terrible take. Take a guess at what “dark:bg-gray-950”, “bg-white” or “min-h-screen” means. You get them from context. Imagine if you put a little bit of effort into learning Tailwind. You’d get the more complex declarations as well. As to why it’s better than a class declaration, a lot has been written about using atomic, composable utility classes over reams of “write-once” class declarations.

I do not disagree that there are one or two recognizable elements in that encoded line-noise. Not sure what is the "terrible take" about it - if you take a poll, most would agree that it requires far too much eye-strain to read, far too much cognitive burden to parse, decode and mentally map to concepts.

Its like deciding to code your entire your app using regexes - all in long single lines without comments.

Re: Tailwind CSS v4.0

#255

Post by thiht »

lenkite wrote: post #252
tipiirai wrote: post #64

Earlier quoted context omitted.

> I suspect many of the pro/anti-Tailwind arguments are no longer relevant I feel there are two issues with Tailwind for me as a designer / design engineer. * First, JavaScript/Tailwind engineers have hijacked the conversation on design. Instead of "utility-first," "dead code elimination," and "type-safe CSS" I focus more on desing systems. Whether to use Perfect Fifth or Perfect Fourth in typography for example. * S…

Man their very playground at https://play.tailwindcss.com/ gives this unreadable crap (sorry for swearing) for the very first `div` on the first line: relative grid min-h-screen grid-cols-[1fr_2.5rem_auto_2.5rem_1fr] grid-rows-[1fr_1px_auto_1px_1fr] bg-white [--pattern-fg:var(--color-gray-950)]/5 dark:bg-gray-950 dark:[--pattern-fg:var(--color-white)]/10 How can anyone prefer this gobbledygook over a nice CSS class d…

Because your not thinking of styles practically. You don't review style declarations, you review the rendered page/component. You see with your eyes that a component has the wrong border color, and AFTER THAT you go to your component code, find the border color declaration (if any), and update it/add it. Sometimes you'll even inspect the element in browser, and find the faulty class directly, making it even easier to target in code.

The Tailwind classes are "unreadable crap", that's true, but it's not a problem because you don't "read" it, no one does. You roughly parse it and edit it.

Re: Tailwind CSS v4.0

#256

Post by Aeolun »

arkh wrote: post #120
Aeolun wrote: post #103

Earlier quoted context omitted.

I think it’s because now your entire component is contained in a single file. No more separately messing around with CSS. The styles are right there on the element they apply to without having to cross reference anything. You could do this with just the css attribute, but that has the issue that everyone has always been taught it is wrong to do that, and a list of strings that contain a bunch of utility is easier tha…

> You could do this with just the css attribute, but that has the issue that everyone has always been taught it is wrong to do that But why is it wrong to use the style attribute? What makes using tailwind to do the same thing "not wrong"? Also this https://tailwindcss.com/docs/hover-focus-and-other-states#us... and https://tailwindcss.com/docs/hover-focus-and-other-states#st... look like reinventing the Cascading of…

> But why is it wrong to use the style attribute? What makes using tailwind to do the same thing "not wrong"?

The time people were taught it was wrong is thr time when all your elements were rendered on the server and the style was duplicated for every component it applied to.

Client rendered JS only sends it over the wire once and then duplicates it on the client.

Tailwind only allows a few options, so it’s less likely you have slightly different styles everywhere.

I think the awful syntax you talk about is really nice, since it covers 99% of everything I ever need to do with it. The cascading part of CSS is really cool, but 99% of the time it’s confusing when I don’t need it.

Re: Tailwind CSS v4.0

#257

Post by presentation »

thiht wrote: post #255
lenkite wrote: post #252

Earlier quoted context omitted.

Man their very playground at https://play.tailwindcss.com/ gives this unreadable crap (sorry for swearing) for the very first `div` on the first line: relative grid min-h-screen grid-cols-[1fr_2.5rem_auto_2.5rem_1fr] grid-rows-[1fr_1px_auto_1px_1fr] bg-white [--pattern-fg:var(--color-gray-950)]/5 dark:bg-gray-950 dark:[--pattern-fg:var(--color-white)]/10 How can anyone prefer this gobbledygook over a nice CSS class d…

Because your not thinking of styles practically. You don't review style declarations, you review the rendered page/component. You see with your eyes that a component has the wrong border color, and AFTER THAT you go to your component code, find the border color declaration (if any), and update it/add it. Sometimes you'll even inspect the element in browser, and find the faulty class directly, making it even easier to…

Personally I prefer how PandaCSS does it - similar end result with atomic css at compile time but it just lets you write your styles as readable objects instead of as insane strings.

Re: Tailwind CSS v4.0

#258

Post by presentation »

agos wrote: post #160
aembleton wrote: post #145

Earlier quoted context omitted.

> I simply don't see the appeal. - Not having to name CSS classes - Easier to read as it's inline with the rest of your HTML - Standardised way of naming so that everywhere uses the same conventions - Not having to manage a separate file and remove unused components - Being able to use media queries, which I couldn't do in a style tag - No risk of changing a class that is used elsewhere. CSS has global scoping which…

no, a single html attribute containing "relative before:absolute before:top-0 before:h-px before:w-[200vw] before:bg-gray-950/5 dark:before:bg-white/10 before:-left-[100vw] after:absolute after:bottom-0 after:h-px after:w-[200vw] after:bg-gray-950/5 dark:after:bg-white/10 after:-left-[100vw]" is not "easier to read" (example taken at random from the Tailwind homepage)

Use PandaCSS, the result is similar but the syntax is a readable object instead of… that

Re: Tailwind CSS v4.0

#259

Post by meiraleal »

brightball wrote: post #250
threatofrain wrote: post #240

Earlier quoted context omitted.

The Tailwind library names grades of colors and sizes for you, but the book is ultimately about iterating design so that you can create your own design system. From the perspective of the book, the Tailwind defaults are inadequate as a design system.

But the Tailwind configuration provides a solid structure for your own though.

just like CSS

Re: Tailwind CSS v4.0

#260

Post by yurishimo »

mablopoule wrote: post #196
skeletal88 wrote: post #147

Earlier quoted context omitted.

The problem is that with bootstrap I have card, table, etc. With tailwind I have an unreadable alpabet soup when I am not a designer but a developer and am not familiar with tailwind.

This is the big one for me. In any big enough or unfamiliar frontend project, my go-to way to explore the codebase is to launch the front-end, and use the inspector to check the elements, and then search-back in the codebase the relevant classes to see what page/component display that, and how does it fetches the data. If there is only an alphabet soup, I no longer have a simple set of classes I can grep the codebase…

This is just not true. You can absolutely grep the soup (I do it daily). Most UI components share a lot of common baselines but include a specific modification for use in place (often a color or extra spacing). That means most of the time, the entire class string is unique to that element, even if the classes themselves are not. At most, you might have a couple of duplications, but then you should probably be looking at a template level component if the functionality is related.

`mx-4 py-2 rounded-xl shadow bg-green-500` is just as easy to global-search for as `notice--success`

Post reply on HN