I'll identify as in the "not yet convinced" category on Tailwind (though, I have evolved on other paradigms, which I will now discuss). JSX felt wrong (at first) due to co-mingling HTML and JS, however, I realized that's the wrong application of concerns because 1. JSX isn't HTML, it's a sugared syntax for the React.createElement API and 2. that separation wasn't meaningfully improving my architecture and in retrospect was clearly holding us back. Could anyone evaluate if these are analogous 'separation of concerns' (SoC) fallacies?
I will admit, I think I never fully appreciated the intent of SoC.
Agreed. We got used to thinking of any Javascript as "business logic" rather than "presentation" because it's an imperative language, but React/JSX are tailored to using JS in a way that acts more like presentation. If you write it imperatively, it won't be idiomatic React, and sooner or later something will break.
So it may help to think of JSX as using a functional subset of Javascript. It's not, and that veil gets pierced pretty often, but the better you contain it, the more you can effectively use both Javascript and HTML together as part of a single concern.
Using Redux with sagas even further separates out the most side-effecty parts of it, though sagas are really heavyweight and I'm still not certain if I think they're worth it.
Sagas are a great power tool, but most Redux apps don't need them. That's why we opted to include thunks out of the box as part of our official Redux Toolkit package:
You could tie CSS/JS event handlers to HTML elements, but if someone edited the HTML file and changed the hierarchy, things broke.
You could tie CSS/JS event handlers to class and id attributes in the HTML file, but you'd have to add those attributes into the HTML file to target the right elements.
Web SoC always felt more SoF (Separation of Files) to me. There is no advantage in putting the HTML/CSS/JS into separate files if making routine changes requires visiting multiple files. React puts it all in one file, which makes me think that the concern is the Component and not the individual browser parsing libraries.
I will give an example that I am facing right now.
I am working on a open source payment gateway for crypto and one of the things that I am providing is a javascript library for those that want to provide a Stripe Checkout-like experience on their sites.
I started doing this in vue.js, which has the idea of the components where you define the html, code and style together in one single file.
My problem is, I want the user to be able to have the styling of the checkout widget similar to their own website. So I want to have my HTML as simple as possible and let them provide the CSS. I could even try to help and provide some different ready-made CSS (to be used directly) or SASS files (if they want to customize) but I've given up on trying to do that inside of vue component definitions.
There's another approach that is more rooted into react paradigm - styled-components. I still don't understand what people see in tailwind as most of the arguments I see in this thread could also be applied to it, but you also get type-checking (typescript), theming, ecosystem of plugins and a lot of other cool things.
I agree that styled-components takes care of a bunch of issues that make some of us reach for Tailwind.
However, aside from requiring a very specific tech stack, it doesn't solve the problem of every component potentially having slightly differing styles. There's ways to handle this, but one thing I like about Tailwind is that the defaults are stronger across components, while still leaving space to deal with all the one-offs.
I believe in some environments (when you have designs already) building off normalize+react-aria(for logic) and thought-out architecture could be as productive as tailwind, especially if you already have some helper functions on-hand. For me, storing mixins for common behaviours inside theme allows to construct lightweight variations where I need them, and you can dynamically modify it in react.
I will admit, I think I never fully appreciated the intent of SoC.