A useful trade-off for the separation of concerns between JS and HTML is type checking. It can be a game changer for some types of applications to have type checking of templates, especially if that type checking happens in a fast compile cycle or automatically in the background of an IDE.
I personally wasn't sold on JSX until I engaged with it through the lens of TSX. Having Typescript check that my templates make sense and variables are passed in correctly and unlikely to be `undefined` fixes a lot of the problems I've had in most other ways to template HTML.
As for styling, yes I'm also a big fan of letting CSS cascade, be the province of the designer, if possible, and that templates and scripting should focus on CSS classes and good selectors over inline styles as much as possible.
In JSX/TSX you can get some of the same linters that warn "no inline styles" even if using off-the-shelf React. Some projects turn those off for "CSS-in-JS" alternatives or Tailwind, but those are still options that I find uncomfortable. In my opinion: good templates produce good markup that a designer can use the "Cascade" in CSS to do wonders with, and components shouldn't need to micro-manage their own styles.
When I built my own React-like library with TSX I was also sorely tempted to remove inline styles and/or binding changes to them, but eventually was convinced that there are still some things that are more convenient that way (including if you are copy/pasting someone else's components or vanilla JS code). My library tries to stay "close to the vanilla wire" so to speak, so I needed inline styles and style bindings just because otherwise it would be done directly to the DOM object anyway, vanilla style. So in the end I was convinced to include them, but it was definitely something I thought long and hard about as someone who believes classes and the Cascade should be the first tool to hand, not inline styles.
Comments
A useful trade-off for the separation of concerns between JS and HTML is type checking. It can be a game changer for some types of applications to have type checking of templates, especially if that type checking happens in a fast compile cycle or automatically in the background of an IDE.
I personally wasn't sold on JSX until I engaged with it through the lens of TSX. Having Typescript check that my templates make sense and variables are passed in correctly and unlikely to be `undefined` fixes a lot of the problems I've had in most other ways to template HTML.
As for styling, yes I'm also a big fan of letting CSS cascade, be the province of the designer, if possible, and that templates and scripting should focus on CSS classes and good selectors over inline styles as much as possible.
In JSX/TSX you can get some of the same linters that warn "no inline styles" even if using off-the-shelf React. Some projects turn those off for "CSS-in-JS" alternatives or Tailwind, but those are still options that I find uncomfortable. In my opinion: good templates produce good markup that a designer can use the "Cascade" in CSS to do wonders with, and components shouldn't need to micro-manage their own styles.
When I built my own React-like library with TSX I was also sorely tempted to remove inline styles and/or binding changes to them, but eventually was convinced that there are still some things that are more convenient that way (including if you are copy/pasting someone else's components or vanilla JS code). My library tries to stay "close to the vanilla wire" so to speak, so I needed inline styles and style bindings just because otherwise it would be done directly to the DOM object anyway, vanilla style. So in the end I was convinced to include them, but it was definitely something I thought long and hard about as someone who believes classes and the Cascade should be the first tool to hand, not inline styles.