I agree, but if we're talking about using a front-end framework like React here, wouldn't that mean we're only talking about the UI parts of the application anyway?
Personally I'm not a big fan of either big frameworks generally or some details of React in particular, but the people behind React do make reasonable arguments in favour of their more component-based separation of concerns.
I don't think so; when working on code for a web application there is always code, styling and html elements that deal ONLY with the presentation side of it but then there is also code that handles talking to the backend, negotiating with web sockets, etc. That code really needs to be separated and what I'm referring to.
> the people behind React do make reasonable arguments in favour of their more component-based separation of concerns.
I love component based separations and I get the feeling many of us are talking about similar things.
Right, but React isn't normally used for things like back-end comms. It's often loosely described as being for the "V" in "MVC", which makes sense given the whole declarative specification of DOM content angle and the one-way data binding style.
I agree and this is why I continued to iterate OP's word usage of separating logic and presentation. Separation of HTML, CSS and JavaScript isn't always useful or straight forward but separating business logic from the user interface is incredibly important, in my opinion.
Separation of HTML, CSS and JavaScript is more of an organizational thing in my mind. JSX makes the syntax awkward and more complex in my opinion especially when you're working with a group of designers who are constantly tweaking styles, element layouts, etc. But for a team of only developers it's not so bad. Still I personally find it easier to simply avoid JSX either way.