5 ms·
This is one of the main reasons why I've become so skeptical about best practice advice, especially if it doesn't come with a plain logical explanation for the
by spion 11y ago
This is one of the main reasons why I've become so skeptical about best practice advice, especially if it doesn't come with a plain logical explanation for the reasoning behind it. Its similar to the problems with outdated laws - if we don'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)
While I'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:
1. PHP was embedded in HTML, not the other way around.
2. The preprocessor basically concatenated everything as strings without caring about what DOM would end up being a result.
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 "placeholders" in HTML and what kind of data should be allowed within them.
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.
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.
- ChrisArgyle 11y agoThe big reason I remember from my PHP days (late 90s early 2000s) is that you want to separate design from development. Graphic designers were expected to know HTML/CSS while developers focus on PHP.
- mattmanser 11y agoThat's never really been true. Graphic designers rarely knew HTML/CSS in the old days.
- ChrisArgyle 11y agoI remember this well. Especially when it came to browser compatibility.
- Moru 11y agoI still get everything as a .jpg. Or a photoshop image if I'm lucky.
- Can_Not 11y agoI have given up on graphic designers that know HTML/CSS. I consider myself lucky if they use some GUI program that outputs clean HTML.
- andreyvit 11y agoActually, the issue with spaghetti PHP is not (only) string concatenation; it's mostly that view logic, domain/business logic and database boilerplate code are intermixed in a single file. React components only ever contain view logic, which already solves a part of the problem. Furthermore, you typically split that logic into multiple components, many of which are stateless, independent and small.
- taytus 11y agoIn all fairness this is ancient history on the PHP world.
- mattmanser 11y agoThat's the point that pkrumins/andreyvit are making, code where logic and presentation are mixed turn into a nightmare to maintain. And the practice is now ancient history. Apart from here it is again...
- andreyvit 11y agoI explicitly do _not_ state that it applies to React, because there's no domain logic in React components. (Or at least there shouldn't be. It is certainly possible to write a spaghetti component that would do everything.)