3 ms·

Boilerplate? What do you mean? Any IDE can autocomplete 90% of any media query. And, on a sidenote, I was only talking about using Tailwind's default aesthetic

Boilerplate? What do you mean? Any IDE can autocomplete 90% of any media query. And, on a sidenote, I was only talking about using Tailwind's default aesthetics in pure CSS, here. That's what the 20 minutes refers to. And I think it was a conservative estimate. As for features, it took months before grid was included in Tailwind. New powerful and useful selectors aren't there. It took years for Tailwind to support "group hovers". And I can give even more examples if you're still not convinced. Or you can have a look at the changelog. As for performance, can Tailwind split its compiled CSS so that only rules used in the displayed components are loaded? And that's not even considering the weight difference between the "tailwinded" HTML and the one needed to support pure CSS. These things matter if performance is a goal (as it should be). If I'm missing something, go ahead and tell me, I'll be reading with great interest!

ethanbond 3y ago
What are you building where CSS and the "weight" of HTML is a real performance consideration?
- emmacharp 3y ago
  Well, I'm building websites and apps. And, as I'm sure you know, milliseconds are important in our craft. You can easily shave or add hundreds of milliseconds with HTML or CSS. And to be honest, I find your general line of inquiry here to be quite agressive and dismissive. I think, respectfully, a little more good faith could further our understanding of each other.
  - ethanbond 3y ago
    The question about what you're building such that you care about perf characteristics of CSS is an effort to understand you, I am sorry I failed to come across that way. Outside of consumer apps I am struggling to imagine a case where the HTML/CSS perf delta would be more important to capture than faster development time. I suppose part of why that doesn't seem like a good faith question is because you don't believe Tailwind dev time to be faster, so the tradeoff that I'm trying to evaluate is totally inane.
    - emmacharp 3y ago
      First, sorry for the response delay. I don't know why I didn't see your answer. As for the case in point, in fact, I think CSS can be as fast if not faster. But that's totally for me to prove. Hehe. That's why I'm working on a set of simple rules for efficient styling with CSS. A website with documentation, examples and tools is in the works. If you're interested, I can give you a heads up when it's online. Feedback from Tailwind users is important and would absolutely be welcomed! PS: thank you for the explanation.
troupo 3y ago
Boilerplate? What do you mean? :root { --gap-default: 2rem; --gap-large: 4rem; ... 30-40 more vars ... } .component1 { margin: var(--gap-default); padding: 0 var(--gap-large); ... more styles like this ... } @media (min-width: 640px) { .component1 { padding: 0 var(--gap-default); } } @media (min-width: 768px) { .component1 { ... other overrides } } /* potentially repeat for other breakpoints ...*/ /* repeat for all components */ /* repeat for some internals of some components */ There's a also a good (if contrived) example directly at Tailwind: https://tailwindcss.com/docs/utility-first https://tailwindcss.com/docs/utility-first > As for features, it took months before grid was included in Tailwind. New powerful and useful selectors aren't there. No one stops you from using whatever CSS you need alongside with Tailwind. I do that for the excellent layout breakout I found here: https://ryanmulligan.dev/blog/layout-breakouts/ https://ryanmulligan.dev/blog/layout-breakouts/ Can't see how this makes Tailwind "ant-CSS". > As for performance, can Tailwind split its compiled CSS so that only rules used in the displayed components are loaded? Tradeoffs. Most existing solutions can't even detect duplicated CSS. So if your existing component already has `width: var(--some-var)`, and you load a different component with the same style... You will still load that style hidden in a different (often auto-generated unique) class name. Meanwhile with Tailwind has a fixed number of classes that apply to all components equally. So, if you have a complex app with multiple component variations, of course you'll need to split your CSS and only load relevant CSS for displayed components. Because your CSS grows with the amount of variations, and each of those variations becomes its own unique class. For Tailwind though that growth slows almost immediately because... it's just a fixed set of classes.
- emmacharp 3y ago
  Thanks for the great reply. Here are my thoughts: In your code example, all that is in :root should be used from project to project. As it is Tailwind. Only values should change. Again, same as Tailwind. So I don't really see a problem. For .component1, you would do the same in Tailwind albeit with fewer characters but as I said, your IDE should pick up the slack here. mb<tab> --gap<tab> and it is done. As for your duplicate width problem, it can be solved easily with a linter that prevents styling across files. I'll give you an example if you're interested. At the same time, you would be repeating "width" across components in Tailwind too. So the duplication still exists, if I understand correctly. Same with the growth of CSS... In Tailwind you grow the HTML instead. Fixed clases or not. I don't see how it is better but, again, maybe I'm missing something. As for the media queries, same as above: your IDE should pick up the slack. BUT! The thing is that by writing modern CSS, you would not need most of these media queries! Do you know "clamp()[1]"? It's magical And unfortunately not supported in Tailwind at the moment .component1 { clamp(var(--gap-default), 1vw, var(--gap-large)) } the above will do what you want without media queries! clamp() solves a loooot of these use cases. Honestly I don't write much media queries anymore and yes, that's great. And if I may, I think Tailwind here prevents you from thinking about better and simpler solutions like this one. If it ain't included in what you're using, it's normal to not think about it. But really, this is a game changer. And it's been available for certainly three years. That's a lot. And in the end, I'd say using real CSS with Tailwind kind of defeats the purpose. You end up with different styling methods for different components. I don't think that's good. More like a "hack". But really, your example above is right on point: by excluding new approaches, Tailwind disincentivize you from using them when they would solve many of your problems elegantly and simply. [1] https://developer.mozilla.org/en-US/docs/Web/CSS/clamp https://developer.mozilla.org/en-US/docs/Web/CSS/clamp edit: the Tailwind example provided is bad CSS. As were the ones given in the first fundamental post by Mr Wathan. These are strawmen. If you're interested, I'll give you an example of good CSS producing the same output.

ethanbond 3y ago

What are you building where CSS and the "weight" of HTML is a real performance consideration?

emmacharp 3y ago
Well, I'm building websites and apps. And, as I'm sure you know, milliseconds are important in our craft. You can easily shave or add hundreds of milliseconds with HTML or CSS. And to be honest, I find your general line of inquiry here to be quite agressive and dismissive. I think, respectfully, a little more good faith could further our understanding of each other.
- ethanbond 3y ago
  The question about what you're building such that you care about perf characteristics of CSS is an effort to understand you, I am sorry I failed to come across that way. Outside of consumer apps I am struggling to imagine a case where the HTML/CSS perf delta would be more important to capture than faster development time. I suppose part of why that doesn't seem like a good faith question is because you don't believe Tailwind dev time to be faster, so the tradeoff that I'm trying to evaluate is totally inane.
  - emmacharp 3y ago
    First, sorry for the response delay. I don't know why I didn't see your answer. As for the case in point, in fact, I think CSS can be as fast if not faster. But that's totally for me to prove. Hehe. That's why I'm working on a set of simple rules for efficient styling with CSS. A website with documentation, examples and tools is in the works. If you're interested, I can give you a heads up when it's online. Feedback from Tailwind users is important and would absolutely be welcomed! PS: thank you for the explanation.

troupo 3y ago

Boilerplate? What do you mean? :root { --gap-default: 2rem; --gap-large: 4rem; ... 30-40 more vars ... } .component1 { margin: var(--gap-default); padding: 0 var(--gap-large); ... more styles like this ... } @media (min-width: 640px) { .component1 { padding: 0 var(--gap-default); } } @media (min-width: 768px) { .component1 { ... other overrides } } /* potentially repeat for other breakpoints ...*/ /* repeat for all components */ /* repeat for some internals of some components */ There's a also a good (if contrived) example directly at Tailwind: https://tailwindcss.com/docs/utility-first https://tailwindcss.com/docs/utility-first > As for features, it took months before grid was included in Tailwind. New powerful and useful selectors aren't there. No one stops you from using whatever CSS you need alongside with Tailwind. I do that for the excellent layout breakout I found here: https://ryanmulligan.dev/blog/layout-breakouts/ https://ryanmulligan.dev/blog/layout-breakouts/ Can't see how this makes Tailwind "ant-CSS". > As for performance, can Tailwind split its compiled CSS so that only rules used in the displayed components are loaded? Tradeoffs. Most existing solutions can't even detect duplicated CSS. So if your existing component already has `width: var(--some-var)`, and you load a different component with the same style... You will still load that style hidden in a different (often auto-generated unique) class name. Meanwhile with Tailwind has a fixed number of classes that apply to all components equally. So, if you have a complex app with multiple component variations, of course you'll need to split your CSS and only load relevant CSS for displayed components. Because your CSS grows with the amount of variations, and each of those variations becomes its own unique class. For Tailwind though that growth slows almost immediately because... it's just a fixed set of classes.

emmacharp 3y ago
Thanks for the great reply. Here are my thoughts: In your code example, all that is in :root should be used from project to project. As it is Tailwind. Only values should change. Again, same as Tailwind. So I don't really see a problem. For .component1, you would do the same in Tailwind albeit with fewer characters but as I said, your IDE should pick up the slack here. mb<tab> --gap<tab> and it is done. As for your duplicate width problem, it can be solved easily with a linter that prevents styling across files. I'll give you an example if you're interested. At the same time, you would be repeating "width" across components in Tailwind too. So the duplication still exists, if I understand correctly. Same with the growth of CSS... In Tailwind you grow the HTML instead. Fixed clases or not. I don't see how it is better but, again, maybe I'm missing something. As for the media queries, same as above: your IDE should pick up the slack. BUT! The thing is that by writing modern CSS, you would not need most of these media queries! Do you know "clamp()[1]"? It's magical And unfortunately not supported in Tailwind at the moment .component1 { clamp(var(--gap-default), 1vw, var(--gap-large)) } the above will do what you want without media queries! clamp() solves a loooot of these use cases. Honestly I don't write much media queries anymore and yes, that's great. And if I may, I think Tailwind here prevents you from thinking about better and simpler solutions like this one. If it ain't included in what you're using, it's normal to not think about it. But really, this is a game changer. And it's been available for certainly three years. That's a lot. And in the end, I'd say using real CSS with Tailwind kind of defeats the purpose. You end up with different styling methods for different components. I don't think that's good. More like a "hack". But really, your example above is right on point: by excluding new approaches, Tailwind disincentivize you from using them when they would solve many of your problems elegantly and simply. [1] https://developer.mozilla.org/en-US/docs/Web/CSS/clamp https://developer.mozilla.org/en-US/docs/Web/CSS/clamp edit: the Tailwind example provided is bad CSS. As were the ones given in the first fundamental post by Mr Wathan. These are strawmen. If you're interested, I'll give you an example of good CSS producing the same output.