5 ms·

> But that's kind of the point. Tailwind is a layer on top of CSS, but it doesn't actually hide any complexity in the layer below. You still need to know CSS.

> But that's kind of the point. Tailwind is a layer on top of CSS, but it doesn't actually hide any complexity in the layer below. You still need to know CSS. This completely misses the point of Tailwind. The point is not to hide the complexity of CSS, but to provide access from the markup to enough of capabilities of CSS that you don't have to edit your stylesheets 95% of the time, when you alter the styling of a document. When Tailwind does fall short because it doesn't provide the exact CSS feature that is needed to solve the problem, it still provides a template for how to solve the problem: Using one-rule utility classes, that are named for what they do, not for how they are meant to be used.

deleted 4y ago
[deleted]
the_other 4y ago
> The point is not to hide the complexity of CSS, but to provide access from the markup to enough of capabilities of CSS that you don't have to edit your stylesheets 95% of the time, when you alter the styling of a document. This makes Tailwind seem like a lot of machinery (in the sense of bundle size, running code, and pseudo-language) just to avoid opening a file at dev time. Layouts are often "collaborations" - the effect of multiple items interacting. You'd still need to open multiple files to understand what was going on. Or read the DOM in the browser. When I read component code, I almost always prefer it when the style _isn't_ in the same file as the JS. It takes up space on the screen and gets in the way of reading about the behaviours. I don't get the propertied benefits. Granted, I've still not used it.
- BigJono 4y ago
  Really? Tailwind sucks but that's literally the only good part of it. Locality is one of the most important things in code. If I'm reading line 38 of foo.js and something elsewhere in the app effects that line, I want that something to be on line 37 of foo.js, not line 158 of bar.js. The problem with Tailwind isn't the co-locating of HTML and CSS. It's that it does it by adding an entire new layer of complexity that's basically a copy paste of an large standardised API with the names of everything changed. It's barely even an abstraction.
- adamlett 4y ago
  > This makes Tailwind seem like a lot of machinery (in the sense of bundle size, running code, and pseudo-language) just to avoid opening a file at dev time. It’s not about avoiding opening a file. It’s about avoiding the risk and/or cost that comes from editing a stylesheet that applies globally. If you change existing rules, you risk breaking the layout somewhere you didn’t anticipate. Or, to avoid that, you treat the stylesheet as append-only, leaving you eventually with enormous files and selectors of ever increasing specificity. Tailwind (or Tachyons) makes for ugly markup, but it solves a real problem, and it does it better than anything else.
  - emmacharp 4y ago
    But can't you do the same with CSS ? If every selector in a file begins with the component class, isn't it the same as writing styles in the component JS file ? I mean, the only real benefit I see is the forced encapsulation in JS compared to "soft" encapsulation in CSS. But, it's something so trivial to learn and practice that the soft part shouldn't be an issue. And if it is, then it is time to learn some rigour, no ?
nailer 4y ago
Instead of editing styling in CSS you edit styling in element classes. You’re still editing styling.
viddi 4y ago
Maybe I'm going out of a limb here, but wasn't the whole point of CSS to not have to touch the markup when changing the styling? Not trying to talk Tailwind down, I have just missed a lot of the evolution of web design in the past 15 or so years.
- xyzzy_plugh 4y ago
  Yes. Tailwind inverts that axiom to great effect. It's leaky on purpose.
- chrischen 4y ago
  Yes but the way we do HTML has also changed–for example by using JSX and reusable components. The issue of having to change markup in a lot of places to change styling doesn't exist anymore if you abstract that away in reusable components.
  - luxcem 4y ago
    And using tailwind without a reusable components system is cumbersome to say the least. What is suggested in the documentation is to use editor features (multi-cursor, research and replace, ...) https://tailwindcss.com/docs/reusing-styles#using-editor-and-language-features https://tailwindcss.com/docs/reusing-styles#using-editor-and...
- dageshi 4y ago
  Everything on the web became a lot more dynamic. Stuff like web apps obviously but even relatively straight forward info pages end up with dynamic filtering and elements of app like functionality often. Given that, the separation becomes more of a pointless burden than actually doing anything useful.
- hbn 4y ago
  I've never understood the point of separating markup from the design. I've seen CSS Zen Garden and... neat? But I don't get the point in real-world use. I've never had to redesign a UI in a way where I'd only change CSS and not also be moving around markup in the process. And once you're changing both of those things, there's the overhead of cross-referencing and keeping names and hierarchy in sync. At that point I don't know why I'd want the 2 separate. The most magical moment for me when I started using Tailwind was realizing you can simply cut-and-paste an arbitrary block of HTML from one place to another and have it just render exactly as you'd expect. You don't have to additionally copy-paste a block of CSS, and then fudge around with the selectors because in the previous place it expected to be in some parent container or what have you.
e12e 4y ago
> The point is not to hide the complexity of CSS, I think one could argue that the raison-d'être of tailwind is to hide the Cascading part of CSS, and along with it a lot of the complexity of actually using CSS.
simonsarris 4y ago
And in a way that same paragraph/criticism could have been written about Geocities in the early 2000's. Yet the simplified but imperfect onramp made a hundred thousand people more quickly understand their way into web development (including myself), than they would have without it.
EMM_386 4y ago
> that you don't have to edit your stylesheets 95% of the time, when you alter the styling of a document And the problem with editing style sheets when dealing with document style, is?

deleted 4y ago

[deleted]

the_other 4y ago

> The point is not to hide the complexity of CSS, but to provide access from the markup to enough of capabilities of CSS that you don't have to edit your stylesheets 95% of the time, when you alter the styling of a document. This makes Tailwind seem like a lot of machinery (in the sense of bundle size, running code, and pseudo-language) just to avoid opening a file at dev time. Layouts are often "collaborations" - the effect of multiple items interacting. You'd still need to open multiple files to understand what was going on. Or read the DOM in the browser. When I read component code, I almost always prefer it when the style _isn't_ in the same file as the JS. It takes up space on the screen and gets in the way of reading about the behaviours. I don't get the propertied benefits. Granted, I've still not used it.

BigJono 4y ago
Really? Tailwind sucks but that's literally the only good part of it. Locality is one of the most important things in code. If I'm reading line 38 of foo.js and something elsewhere in the app effects that line, I want that something to be on line 37 of foo.js, not line 158 of bar.js. The problem with Tailwind isn't the co-locating of HTML and CSS. It's that it does it by adding an entire new layer of complexity that's basically a copy paste of an large standardised API with the names of everything changed. It's barely even an abstraction.
adamlett 4y ago
> This makes Tailwind seem like a lot of machinery (in the sense of bundle size, running code, and pseudo-language) just to avoid opening a file at dev time. It’s not about avoiding opening a file. It’s about avoiding the risk and/or cost that comes from editing a stylesheet that applies globally. If you change existing rules, you risk breaking the layout somewhere you didn’t anticipate. Or, to avoid that, you treat the stylesheet as append-only, leaving you eventually with enormous files and selectors of ever increasing specificity. Tailwind (or Tachyons) makes for ugly markup, but it solves a real problem, and it does it better than anything else.
- emmacharp 4y ago
  But can't you do the same with CSS ? If every selector in a file begins with the component class, isn't it the same as writing styles in the component JS file ? I mean, the only real benefit I see is the forced encapsulation in JS compared to "soft" encapsulation in CSS. But, it's something so trivial to learn and practice that the soft part shouldn't be an issue. And if it is, then it is time to learn some rigour, no ?

nailer 4y ago

Instead of editing styling in CSS you edit styling in element classes. You’re still editing styling.

viddi 4y ago

Maybe I'm going out of a limb here, but wasn't the whole point of CSS to not have to touch the markup when changing the styling? Not trying to talk Tailwind down, I have just missed a lot of the evolution of web design in the past 15 or so years.

xyzzy_plugh 4y ago
Yes. Tailwind inverts that axiom to great effect. It's leaky on purpose.
chrischen 4y ago
Yes but the way we do HTML has also changed–for example by using JSX and reusable components. The issue of having to change markup in a lot of places to change styling doesn't exist anymore if you abstract that away in reusable components.
- luxcem 4y ago
  And using tailwind without a reusable components system is cumbersome to say the least. What is suggested in the documentation is to use editor features (multi-cursor, research and replace, ...) https://tailwindcss.com/docs/reusing-styles#using-editor-and-language-features https://tailwindcss.com/docs/reusing-styles#using-editor-and...
dageshi 4y ago
Everything on the web became a lot more dynamic. Stuff like web apps obviously but even relatively straight forward info pages end up with dynamic filtering and elements of app like functionality often. Given that, the separation becomes more of a pointless burden than actually doing anything useful.
hbn 4y ago
I've never understood the point of separating markup from the design. I've seen CSS Zen Garden and... neat? But I don't get the point in real-world use. I've never had to redesign a UI in a way where I'd only change CSS and not also be moving around markup in the process. And once you're changing both of those things, there's the overhead of cross-referencing and keeping names and hierarchy in sync. At that point I don't know why I'd want the 2 separate. The most magical moment for me when I started using Tailwind was realizing you can simply cut-and-paste an arbitrary block of HTML from one place to another and have it just render exactly as you'd expect. You don't have to additionally copy-paste a block of CSS, and then fudge around with the selectors because in the previous place it expected to be in some parent container or what have you.

e12e 4y ago

> The point is not to hide the complexity of CSS, I think one could argue that the raison-d'être of tailwind is to hide the Cascading part of CSS, and along with it a lot of the complexity of actually using CSS.

simonsarris 4y ago

And in a way that same paragraph/criticism could have been written about Geocities in the early 2000's. Yet the simplified but imperfect onramp made a hundred thousand people more quickly understand their way into web development (including myself), than they would have without it.

EMM_386 4y ago

> that you don't have to edit your stylesheets 95% of the time, when you alter the styling of a document And the problem with editing style sheets when dealing with document style, is?