> getting rid of inheritance altogether and settling for this interface boundary sharing
You claim it is "settling" but I'll try to explain why its not only not "settling" but actually encouraging best practices. I'm not sure what language you're most familiar with but since you're talking about inheritance I'll try to provide Java analogies.
Hierarchal components => Hierarchical composition of classes
Mixins => Interfaces with default implementations (possible as of Java 8)
Inheritance, as defined by the OO paradigm, is very rarely the correct solution. Even in a language like Java, when it comes to classes, the best practice is to use composition over inheritance. If you haven't heard this before, or you don't agree, sorry but I'd rather not get into this myself. There are a ton of really good resources online about this, they will do a far better job explaining than I would.
I aint no traditionalist or a Java supremacist :). I'm just an ordinary guy with passion for anything web development and I happen to like javascript a lot.
So, I'm okay with non classical inheritance or any other non conventional constructs that would make our lives easier but I'm really skeptical about the direction that these frameworks is taking the industry as a whole in, and I believe that their lack of enthusiasm for established best practices and breaking the rules without offering well thought and coherent alternatives is worrisome.
React isn't about breaking rules or disregarding best practices. It's simply recognizing that other principles need to be applied for a certain type of application.
Those principles are in fact old, and originate in the desktop app. Every single desktop UI framework throughout history, from Xerox Star to Visual Basic to Swing to Delphi to Cocoa, has modeled the UI in terms of components (sometimes called controls or widgets) that can be contained within each other. Components are logically independent containers whose behaviour and rendering follow them around; drop a button onto a form, for example, and you get "button behaviour" without having to implement anything yourself. React follows this exact pattern.
The reason people are interested in "breaking" rules such as separation of style and markup is because those principles don't apply well to this way of doing things. Components aren't document markup to be styled, they're views that need to draw themselves. You can devise various ways to continue using CSS to "skin" these components, but this is ultimately the enemy of a good component. It turns out that for components to be true containers, they have to have complete control over their own rendering, and inserting global CSS that cascades into a component tends to violate that boundary. In other words, the component _is_ presentation, and therefore a "separation" makes no sense because there isn't much to separate.
You can debate the merit of modern single-page apps, but people are building them, and need the tools to do so. At the same time it's clear that people (not just developers) want both the power of the web, and the power of desktop apps, and developers are now trying to discover how this hybridization — the appification of the web browser and the webification of the desktop — can be attained. React is probably just one step in the search for some better converging structure.
You criticize React a lot in this thread, but I can assure that it's well thought and coherent. I've been a web developer for about 20 years, and this is the most productive and content I have been about working in a browser. I recommend trying it out.
One of the best rebuttals I have read on this thread. I'm no React hater and I honestly consider trying it out just to see what's all the buzz about but it won't still fit my definition of proper SoC.
