3 ms·

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

Man their very playground at https://play.tailwindcss.com/ 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.

orf 2y ago
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.
- lenkite 2y ago
  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.
thiht 2y ago
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.
- presentation 2y ago
  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.
- isleyaardvark 2y ago
  Exactly, it's not like a novel where you are trying to read the entire thing. And it's an advantage because it is easier to parse. If I'm trying to change the color on that element, I have a very good idea what controls that. As opposed to something like "card_wrapper card_wrapper--striped". That certainly looks better, but if I'm just there to change the grid, now it's a more complicated change. In Tailwind, I can just look, see "grid-cols-[1fr_2.5rem_auto_2.5rem_1fr]" and know that not only that's where to change it, but that I can also change the classname there without worrying about a regression in some other element somewhere else. Whereas with "card_wrapper card_wrapper--striped", well what controls the grid? I have to look in another file, and I also have to be concerned about every other place those classes are used. (Or I have to add new one-off classnames, at which point the complaint about long classnames holds less weight.)

orf 2y ago

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.

lenkite 2y ago
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.

thiht 2y ago

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.

presentation 2y ago
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.
isleyaardvark 2y ago
Exactly, it's not like a novel where you are trying to read the entire thing. And it's an advantage because it is easier to parse. If I'm trying to change the color on that element, I have a very good idea what controls that. As opposed to something like "card_wrapper card_wrapper--striped". That certainly looks better, but if I'm just there to change the grid, now it's a more complicated change. In Tailwind, I can just look, see "grid-cols-[1fr_2.5rem_auto_2.5rem_1fr]" and know that not only that's where to change it, but that I can also change the classname there without worrying about a regression in some other element somewhere else. Whereas with "card_wrapper card_wrapper--striped", well what controls the grid? I have to look in another file, and I also have to be concerned about every other place those classes are used. (Or I have to add new one-off classnames, at which point the complaint about long classnames holds less weight.)