I can second this. I'm working on two projects, one paid and one volunteer. One is using vanilla css/html (requirement to work without js) and the other is using react. Doesn't matter which is which.
To set the context for the following statement, I've discovered that I prefer developing the nojs site. This mainly comes down to all the things that the browser does for me, but I have to handle manually in React, but it also includes something fun about figuring out the right css selectors to accomplish pseudo-interactivity without js. The point here is that I'm not personally inclined to avoid css.
And yet, when I work in react, I find myself writing less css, and the css I do write is closer to utility classes, something I never used in the nojs project.
I'm writing this on mobile but it's getting too long, posting and will move to desktop and edit in the reasons why I think React pushes me in the direction.
e: got here just as the edit window is closing, will reply to self instead.
The first reason is what ricardobeat mentioned — with JSX, I'm writing my display "html-ish" code at the same time as the business logic. If I'm managing the state of, say, a form, and I want the submit button to be disabled when (condition), the obvious solution is to add `disabled={condition}`, rather than a conditional className or attribute to then match on in css. When I'm doing everything in one file, switching to a different file feels out of place and breaks me out of my normal flow.
This is also why I tend to think in terms of utility classes. When I'm writing JSX, I'm also visualizing how the final page will look (or actually looking at it, side-by-side). So, it's natural to be thinking about the actual styles I want to apply, not classes that hold several related styles. Sometimes I'm almost tempted to write inline styles, but thankfully the syntax is awkward enough to dissuade me.
The second reason has to do with how the html part of JSX is structured. When writing css for plain html, it's easy enough to see how the page is structured and go through it writing css classes for each block (or applying existing classes). Then you refactor as you notice common patterns and to put different style in the right places (oops, that margin should have been padding on the parent element…), like with any code. But with React, js is often changing bits and pieces of the dom itself, so it can be hard to look at and see the structure in the same way. Thus, it's easier just to apply the styles in the same place as everything else. (In React's defense here, I think if I were doing a similar amount of dom mutation using vanilla js, jquery, etc, it would be even harder to write css for it… but on the other hand, vanilla js doesn't encourage me to do nearly as much of it in the first place.)
> If I'm managing the state of, say, a form, and I want the submit button to be disabled when (condition), the obvious solution is to add `disabled={condition}`, rather than a conditional className or attribute to then match on in css.
I'm confused, are you saying you would prefer to disable the submit button without adding the `disabled` attribute?
Hmm, good point. I was trying to simplify a real-world example to shorten it, but ended up with something nonsensical. I was starting to share a better example but then realized I have other things I ought to do right now… I have it saved, will come back if I have more time later.
To set the context for the following statement, I've discovered that I prefer developing the nojs site. This mainly comes down to all the things that the browser does for me, but I have to handle manually in React, but it also includes something fun about figuring out the right css selectors to accomplish pseudo-interactivity without js. The point here is that I'm not personally inclined to avoid css.
And yet, when I work in react, I find myself writing less css, and the css I do write is closer to utility classes, something I never used in the nojs project.
I'm writing this on mobile but it's getting too long, posting and will move to desktop and edit in the reasons why I think React pushes me in the direction.
e: got here just as the edit window is closing, will reply to self instead.