This is one of the main reasons why I&#x27;ve become so skeptical about best practice advice, especially if it doesn&#x27;t come with a plain logical explanation for the reasoning behind it. Its similar to the problems with outdated laws - if we don&#x27;t keep track of the reasons why a law came into use in the first place, we might miss the moment where it might not apply anymore (we wont even know, really)<p>While I&#x27;m not entirely sure what the original reasons were, I can see a big difference between the way, say, PHP was embedded in HTML and now JSX is embedded in JavaScript:<p>1. PHP was embedded in HTML, not the other way around.<p>2. The preprocessor basically concatenated everything as strings without caring about what DOM would end up being a result.<p>Because of these two reasons it was extremely hard to protect against improper injection of data into the resulting HTML. There was no way to make the preprocessor understand the different types of &quot;placeholders&quot; in HTML and what kind of data should be allowed within them.<p>In contrast, JSX embeds HTML within JS. Furthermore, JSX (pretty much) compiles to function calls, not string concatenation. This means that the engine has great degree of control over the interpretation of the data: its impossible to get malformed HTML, or for an attribute value to escape the actual attribute and so on. Which in turn eliminates the original problem that was present in PHP.<p>As for separation of concerns, thats still possible with JSX. We have CommonJS (or ES6) modules and we can move the render functions anywhere we want. But now its up to us to decide whether it makes sense or not.