3 ms·

What would be the difference?

bongobingo1 4y ago
Performance, brevity. TW classes are a lot more concise and provide a "design system" vs raw values and browsers are good at applying classes vs parsing inline styles for every element.
- necovek 4y ago
  I am really curious about the performance claim. It seems to be mostly a matter of where the performance penalty is paid. Browsers either parse CSS (mostly) "ahead" of HTML (tailwind CSS classes), or as they parse HTML (inline CSS): they still got to parse a very similar amount of CSS, except if you've got the same "rule" applied in a number of places (though in that case, element-based CSS rules probably win-out). Do you perhaps know of any benchmarks where the actual real-world effect is visible?
  - bongobingo1 4y ago
    first google result https://www.sderosiaux.com/articles/2015/08/17/react-inline-styles-vs-css-stupid-benchmark/ https://www.sderosiaux.com/articles/2015/08/17/react-inline-... > parse HTML (inline CSS): they still got to parse a very similar amount of CSS, I have no idea how it works but I imagine there is a difference to parse class.css parse el1.html apply class to el1 parse el2.html apply class to el2 vs parse el1.html parse el1.css apply style to el1 parse el2.html parse el2.css apply style to el2 Honestly the argument pro/con performance is irrelevant to me, writing this 100 times class="text-lg" is immeasurably more ergonomic than writing this 100 times style="font-size: 1.125rem; line-height: 1.75rem;" Or even worse class="shadow" and style="box-shadow: 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1)" and that's only one style.
    - necovek 4y ago
      That benchmark tests something slightly different with a focus on repeated CSS rules (and all from JS even): it's not surprising that's faster, though it's interesting it's faster even from JS (I acknowledged expecting that, and that CSS rules per HTML element are likely even faster, eg. a td rule with all the styles on it would probably win over that too). I do get the terseness point, but unless you are completely happy with Tailwind definitions, it makes code less maintainable rather than more IMHO: instead of having a familiar place to look up the "shadow" definition (if that's not really doing what you want) in your own CSS or HTML file, you need to look at tailwind CSS inside your dependencies, or inside a debugging console in your browser. I am also unhappy about any code where you'd have to write even `class="text-lg"` a 100 times: perhaps I am still living in the foolish dream of semantic markup, and I would hope you can structure your document in a way where styling is context-dependent: so perhaps you put class="text-lg" on an "top-level" element, and then only adjust nested element text sizes where needed.

Performance, brevity. TW classes are a lot more concise and provide a "design system" vs raw values and browsers are good at applying classes vs parsing inline styles for every element.

necovek 4y ago
I am really curious about the performance claim. It seems to be mostly a matter of where the performance penalty is paid. Browsers either parse CSS (mostly) "ahead" of HTML (tailwind CSS classes), or as they parse HTML (inline CSS): they still got to parse a very similar amount of CSS, except if you've got the same "rule" applied in a number of places (though in that case, element-based CSS rules probably win-out). Do you perhaps know of any benchmarks where the actual real-world effect is visible?
- bongobingo1 4y ago
  first google result https://www.sderosiaux.com/articles/2015/08/17/react-inline-styles-vs-css-stupid-benchmark/ https://www.sderosiaux.com/articles/2015/08/17/react-inline-... > parse HTML (inline CSS): they still got to parse a very similar amount of CSS, I have no idea how it works but I imagine there is a difference to parse class.css parse el1.html apply class to el1 parse el2.html apply class to el2 vs parse el1.html parse el1.css apply style to el1 parse el2.html parse el2.css apply style to el2 Honestly the argument pro/con performance is irrelevant to me, writing this 100 times class="text-lg" is immeasurably more ergonomic than writing this 100 times style="font-size: 1.125rem; line-height: 1.75rem;" Or even worse class="shadow" and style="box-shadow: 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1)" and that's only one style.
  - necovek 4y ago
    That benchmark tests something slightly different with a focus on repeated CSS rules (and all from JS even): it's not surprising that's faster, though it's interesting it's faster even from JS (I acknowledged expecting that, and that CSS rules per HTML element are likely even faster, eg. a td rule with all the styles on it would probably win over that too). I do get the terseness point, but unless you are completely happy with Tailwind definitions, it makes code less maintainable rather than more IMHO: instead of having a familiar place to look up the "shadow" definition (if that's not really doing what you want) in your own CSS or HTML file, you need to look at tailwind CSS inside your dependencies, or inside a debugging console in your browser. I am also unhappy about any code where you'd have to write even `class="text-lg"` a 100 times: perhaps I am still living in the foolish dream of semantic markup, and I would hope you can structure your document in a way where styling is context-dependent: so perhaps you put class="text-lg" on an "top-level" element, and then only adjust nested element text sizes where needed.