4 ms·

One thing I would like to see is a re-implementation of the button in your style of CSS to strengthen your position. I'm not siding with either approach, I just

One thing I would like to see is a re-implementation of the button in your style of CSS to strengthen your position. I'm not siding with either approach, I just think it would make the article better. Your, "don't make things cleaner"/"make clean things", images show part of the Tailwind classes used to make the black button on one side and the class "primary" on the other. Elsewhere in the article you define "primary" as only setting the text color to white. I believe the specific example is a strawperson argument - you're asserting that semantic CSS (as you've defined in the article) is better than Tailwind's approach. However, you don't show an alternative. --- On a personal note, I've never seen custom (S)CSS written in a maintainable way in my ~decade writing it professionally. Encapsulating styles by colocating them with the markup (Button.jsx and button.css, styled-components, Tailwind, etc) is the most maintainable way. I think Tailwind works really well because it eliminates collisions at the global level and makes it really easy to see what a piece of markup will look like without having to change contexts. As a fan of Tailwind's approach, I like to hear the other side.

tipiirai 3y ago
Hey. Thanks for the comment. I could add that, but wanted to focus on the title of the article: the technological origin, vendor lock-in, and their messaging scheme. I have written a different article about Tailwind vs semantic CSS, which compares the amount of code needed to implement the same thing and how the resulting site is order of magnitude smaller with the semantic approach: https://nuejs.org/blog/tailwind-vs-semantic-css/ https://nuejs.org/blog/tailwind-vs-semantic-css/
- rahkiin 3y ago
  I dismissed most of the content because you’re missing a full css re-implementation of your primary class. It would have at least as many lines as the Tailwind classes and have extra blocks for before, for example. Either way, all these classes/css end up in a Button component for my site.
  - tipiirai 3y ago
    > at least as many lines as the Tailwind classes Have you ever used vanilla CSS? Please try to replicate that black button! You'd be surprised how much less it requires. No &>[data-slot=icon]]:-mx-0.5 or anything like that needed
    - rahkiin 3y ago
      I have for many years! And this block needs media queries and stuff for active and other states. That line you quote is .primary>[data-slot=icon] { margin-left: -0.5rem; margin-right: -0.5rem: }
      - tipiirai 3y ago
        And you still need 60+ lines to create a button like that?
        unculture 3y ago
        Come on - your turn. Come back with your version of that Catalyst button that does everything that’s being done by those Tailwind styles.
        tipiirai 3y ago
        I've written an entire article that about Tailwind's "don't clean things up" attitude: https://nuejs.org/blog/tailwind-vs-semantic-css/ https://nuejs.org/blog/tailwind-vs-semantic-css/ The bloat takes several forms 1. The amount of source HTML/CSS needed 2. The code complexity (class & DIV/SPAN "soup") 3. The weight of CSS & JS on the resulting website Happy to write a comparison to Calypso, which is on a whole new level. Betting 10-20x bloat differences to semantic CSS.
        lawn 3y ago
        Both this and the post you linked are great. I do think it would be great to make a follow-up post on Calypso, even if only on the button. Looking forward to it.
- oxidant 3y ago
  I think it's important to add to the article. Like I said, the one bit of CSS you added is nowhere near the functionality of the Tailwind example you were comparing it to. Without an apples to apples comparison showing _how_ Tailwind should've done it, your words have less power. --- I read your other article and it still feels superficial and missing details. You compare a demo of a commercially available (effectively "closed source") template against a page you built, but don't provide the source for the page you built. Apologies if it's in the article, but I couldn't find it. I did find the simple blog template on the Nue site, but it had considerably less functionality than the Tailwind demo. It's still not an apples to apples comparison, because you're comparing a site built with Nextjs to whatever you built. Of course static HTML without JavaScript is going to load faster than an SSG site. I think the ending quote in the second article is completely unrelated to Tailwind and I'm not sure why it was your conclusion. > The fact is that Tailwind's popularity will eventually fade. CSS-in-JS is trending now, but standards are forever. Tailwind isn't CSS-in-JS. You don't need a build step to write it. You need a build step for important features like tree shaking and dynamic properties, but it's not CSS-in-JS. Including that hurts your position because it sounds like you don't understand what you're arguing against. Lastly, why so much hate against Tailwind? Positioning your framework as "Nue and semantic CSS vs Tailwind" doesn't make me want to try your framework. Show me why your framework is good and let me bring my own solutions to it.

tipiirai 3y ago

Hey. Thanks for the comment. I could add that, but wanted to focus on the title of the article: the technological origin, vendor lock-in, and their messaging scheme. I have written a different article about Tailwind vs semantic CSS, which compares the amount of code needed to implement the same thing and how the resulting site is order of magnitude smaller with the semantic approach: https://nuejs.org/blog/tailwind-vs-semantic-css/ https://nuejs.org/blog/tailwind-vs-semantic-css/

rahkiin 3y ago
I dismissed most of the content because you’re missing a full css re-implementation of your primary class. It would have at least as many lines as the Tailwind classes and have extra blocks for before, for example. Either way, all these classes/css end up in a Button component for my site.
- tipiirai 3y ago
  > at least as many lines as the Tailwind classes Have you ever used vanilla CSS? Please try to replicate that black button! You'd be surprised how much less it requires. No &>[data-slot=icon]]:-mx-0.5 or anything like that needed
  - rahkiin 3y ago
    I have for many years! And this block needs media queries and stuff for active and other states. That line you quote is .primary>[data-slot=icon] { margin-left: -0.5rem; margin-right: -0.5rem: }
    - tipiirai 3y ago
      And you still need 60+ lines to create a button like that?
      - unculture 3y ago
        Come on - your turn. Come back with your version of that Catalyst button that does everything that’s being done by those Tailwind styles.
        tipiirai 3y ago
        I've written an entire article that about Tailwind's "don't clean things up" attitude: https://nuejs.org/blog/tailwind-vs-semantic-css/ https://nuejs.org/blog/tailwind-vs-semantic-css/ The bloat takes several forms 1. The amount of source HTML/CSS needed 2. The code complexity (class & DIV/SPAN "soup") 3. The weight of CSS & JS on the resulting website Happy to write a comparison to Calypso, which is on a whole new level. Betting 10-20x bloat differences to semantic CSS.
        lawn 3y ago
        Both this and the post you linked are great. I do think it would be great to make a follow-up post on Calypso, even if only on the button. Looking forward to it.
oxidant 3y ago
I think it's important to add to the article. Like I said, the one bit of CSS you added is nowhere near the functionality of the Tailwind example you were comparing it to. Without an apples to apples comparison showing _how_ Tailwind should've done it, your words have less power. --- I read your other article and it still feels superficial and missing details. You compare a demo of a commercially available (effectively "closed source") template against a page you built, but don't provide the source for the page you built. Apologies if it's in the article, but I couldn't find it. I did find the simple blog template on the Nue site, but it had considerably less functionality than the Tailwind demo. It's still not an apples to apples comparison, because you're comparing a site built with Nextjs to whatever you built. Of course static HTML without JavaScript is going to load faster than an SSG site. I think the ending quote in the second article is completely unrelated to Tailwind and I'm not sure why it was your conclusion. > The fact is that Tailwind's popularity will eventually fade. CSS-in-JS is trending now, but standards are forever. Tailwind isn't CSS-in-JS. You don't need a build step to write it. You need a build step for important features like tree shaking and dynamic properties, but it's not CSS-in-JS. Including that hurts your position because it sounds like you don't understand what you're arguing against. Lastly, why so much hate against Tailwind? Positioning your framework as "Nue and semantic CSS vs Tailwind" doesn't make me want to try your framework. Show me why your framework is good and let me bring my own solutions to it.