I did no such thing. That you see such is an example of front end developers seeing everything through emotionally tinted glasses. If you want to talk numbers we can talk numbers, but it doesn't matter if the first matter is whether or your not the numbers offend you.
it's not a really unbiased view. React's team has made very clear that they won't even start considering a different approach, and this (and other) is just their narrative to support their stance (which never seemed under discussion), and it borders on gaslighting the community which still has to deal at least with the two giant issues of:
1) knowing why something rendered is almost impossible
2) even for skilled developers who know what they are doing it's quite easy to introduce performance regressions. In other words, it's not a pit of success performance wise
Meanwhile (and this is also never addressed by the React team) if you use other frameworks some issues (for one: effect dependencies) simply are not issues
"widely available" has a precise meaning that includes Firefox (both desktop and Android). it might be irrelevant for some, but let's not twist industry definitions
This website says certain features work on firefox. But they don't. You can disregard firefox if you like. But if this "Modern CSS Code Snippets" website explicitly tells me their snippets work in firefox, I expect the snippets to work in firefox. Many of them do not.
again, "widely available" should not be intended in the general sense but as a much more precise industry term. "Baseline widely available" is defined[1] as a feature which has been available on all the core browsers (Chrome desktop and Android, Edge, Firefox desktop and Android, Safari on Mac and iOS) for two and a half years
I don't really care about someones phony definition of widely available. If it runs on 90% of user's browsers, it's widely available. I'll gladly make a web page that puts this definition online so that you can also reference it in discussions, if you want.
I think your point has very little to do with tailwind and everything to do with CSS. Tailwind is optimized for modification and maintainability. We could replace your example with
<div class="hero-header hero-header--large">...
but now any time we want to modify hero-header, we're trolling through the whole site to find where else these classes might be used so we know what to test to avoid breaking anything
Sure it's easy to look at the element you shared and say it's too complex (it's really not, it's very declarative), but the complexity must live somewhere, and I'd choose Tailwind over any other prevailing system because it's isolated and safe to modify
You can fold it, format it, and IDEs preview it. This is like me posting the equivalent CSS in one big line. But even without all that I still prefer this over dealing with cascading styles in stylesheets. Never again.
I thought it was being done for web apps like Google Docs now, and I thought one of Microsoft's cross-platform toolkits used <canvas> too (though I don't think this toolkit itself will see broad adoption).
reply