As if "losing track of your own Javascript" is something that:
a) does not happen
or:
b) is OK?
Might as well have written your sneer like: "All in the name of writing code that makes it easier to do what? Simplify development?"
a) does not happen
or:
b) is OK?
Might as well have written your sneer like: "All in the name of writing code that makes it easier to do what? Simplify development?"
On the contrary, it's very clean.
The real separation of concerns is between business logic and view code, and React does that perfectly.
Not between HTML, CSS, DOM etc which are artificial inflated concerns due to how the browser ended up as an ad-hoc application coding platform (from it's "document" viewer beginnings, which is where the "D" in the DOM comes from).
(And of course nothing stops you from using CSS and external styles with React, separating style from behavior).
>This is why Webcomponents are now part of the living standard.
Web components only solve the non-interesting parts of what React does. Namely, isolated components. All the state and management mess for the entire app is still yours to deal with. Even React alone does more, nevermind React+Redux/FLUX etc.
Which is also the reason React caught like wildfire, and nobody much cares for Webcomponents (e.g. not any statistically significant numbers).
Having to deal with shouldComponentUpdate is a blessing compared to having to juggle 4-5 different concepts and web technologies, plus manage state, plus separate logic yourself, etc.
Heck, in Backbone, which is as bare as it gets, and you needed to wrap your data in specific classes...
And that's IF (and it's a big IF) you have some very complex performance case. In most cases I never needed it, and tons of stuff can just be a pure render function.