The article is interesting but really feels unfair sometimes, it doesn't help:
- The whole "amount of CSS" part is unfair when the Semantic CSS implementation isn't responsive at all, so of course it will be lighter, it does less.
- The part about the big number of HTML elements is a bit frustrating too; tailwind doesn't require you to use more HTML tags at all. It's totally possible to redo the Semantic CSS example with tailwind by not adding any HTML tags.
Besides that, it's still interesting to try and compare what is the best between big HTML (atomic, tailwind) vs big CSS (semantic).
Tailwind is not perfect, and sure, sometimes, you can get more performant code by writing it the semantic way. Sometimes.
But tailwind sure is a great way to easily write maintainable CSS in a team with different skill sets, producing really performant code by default, on large web apps.
- compare the tailwind example and yours, they don't have the same behavior. The tailwind one has a specific mobile menu for example. And that is just one example.
- sure, but since the tailwind page does more things, it's logical it has more code. Your base for comparison is production used code, sold to people. So of course it's polished, it must handle browser bugs and other things you might not expect in a quickly implemented alternative for a tech article. So I'm not surprised the code is bigger. That doesn't say at all that tailwind == more HTML tags :)
Tailwind example indeed does more, but only slightly. Would increase the size of CSS by 1-3%. The semantic version has clearly enough to prove the point the article attempts to make: significantly less code is needed and the resulting site is leaner & faster.
If you really want to compare code snippet sizes, you must offer the same functionality. Otherwise, the comparison is meaningless.
You did the exact same thing before when you compared the Headless UI combobox with your nue.js implementation. Offering fewer features will result in less code. Shocker.
Besides, I don't really care for these comparisons. If something is 2x longer code but more maintainable, it is 100% worth it. Just because something is short doesn't make it better.
I know what you are talking about. Projects tend to slow down at the end of it. But responsiveness is not one of those things, at least on this project. My honest guess is 3%, the menu being the biggest piece. It can also be lazily loaded so that it doesn't increase the amount of primary CSS. Just like the dark mode was implemented.
Having said that, I promise 100% feature parity on my next article. Thanks for the heads up!
Features that look easy to implement and are not a big deal can turn out to be massive problems and require a large amount of code to actually pull of. I would, in some cases, count responsiveness to be one of those things. Stuff like that may seem like 5% of the
functionality but actually makes up a large chunk of the code. This is why you must always have feature parity if you really want to compare code size.
Is comparing the markup of an html page with all the style in html attributes, to an html page which imports style from a CSS file (which is not displayed) a fair comparison?
- The whole "amount of CSS" part is unfair when the Semantic CSS implementation isn't responsive at all, so of course it will be lighter, it does less.
- The part about the big number of HTML elements is a bit frustrating too; tailwind doesn't require you to use more HTML tags at all. It's totally possible to redo the Semantic CSS example with tailwind by not adding any HTML tags.
Besides that, it's still interesting to try and compare what is the best between big HTML (atomic, tailwind) vs big CSS (semantic).
Tailwind is not perfect, and sure, sometimes, you can get more performant code by writing it the semantic way. Sometimes.
But tailwind sure is a great way to easily write maintainable CSS in a team with different skill sets, producing really performant code by default, on large web apps.