I used to describe myself as a web standards evangelist ten years ago and my first instinct when I saw React (both because of JSX and because it was from Facebook) was to laugh and shake my head (until I decided to "give it five minutes" and found out I was wrong) so I hope my perspective could make some sense to you.

--

Just to clarify: React is not about killing the separation of concerns. React is about one thing: converting application state to a component tree and rendering that component tree to the DOM via highly optimised diffing.

At the base level, React turns state into component trees. Similarly, Redux is only about managing state and changes to that state. These are fairly straightforward ideas but having them as clearly defined building blocks with an extremely straightforward API (Redux moreso than React but in the trivial case a React component as of 0.14 can be a plain old pure function) radically simplifies application development.

I'll say it again: application development. I haven't said anything about HTML and CSS yet. This is as relevant to the web as it is to native application development and it's not an accident that React has been decoupled from ReactDOM with the latter now being merely the implementation detail of going the last mile and rendering things to the DOM (or to HTML strings) and maintaining DOM bindings and diffs.

--

A quick interlude: JSX is not HTML. It looks like XML and in many examples it has HTML tag names in it, but it's not HTML -- nor is it XML for that matter. It's just (entirely optional but very useful once you get over the initial visceral discomfort) syntactic sugar for defining component trees (not DOM subtrees). The syntax is obviously based on XML but it is a lot simpler and the familiarity obviously helps.

--

One thing most people don't understand about React (not least because React isn't vocal enough about it -- just like Flux wasn't vocal enough about certain concepts until Redux came along and showcased why they're important and useful) is that you can and should distinguish between presentational components and application logic.

If you use Redux (or Flux -- but with Flux there's the problem that most things called Flux aren't actually Flux because nobody really understood it) most of your components will be entirely presentational and the logic will live outside the components except for a few so-called "containers" which are just extremely thin wrappers.

So with React+Redux you then have your component structure living in React components and your logic living in a few functions that describe transitions of the immutable application state plus a few "containers" that just describe how the state is applied to the API of the few "smart" components that actually need interaction.

Sure, HTML strings intuitively feel more appropriate for describing these components and Web Components definitely look more "HTML-like" in that regard, but at the end of the day you're still writing something XML-like with made up elements (whether they're Web Components or React "components") that needs to be processed by JavaScript before being turned into the actual DOM.

--

One major change React brings to the table that isn't spoken nearly as much of as it should be is that React can be used to render applications to HTML, without the DOM, on the server. This usually gets mentioned in the context of "load times" or "SEO friendliness" but it's a pretty significant property of React.

Not only can React on the client "seamlessly" re-use the server-rendered DOM and attach itself like a jQuery plugin would but being able to render the application (and using Redux: render it with an arbitrary state) means you can truly embrace the idea of progressive enhancement without giving up the comfort of web application tooling.

Some years ago there was a lot of hype (well, not as much by a long stretch but some hype nevertheless) around the idea of making web apps work without JS (YUI[0] allowing server-side rendering of JS web apps and PJAX[1] enabling web sites to behave more like apps). Instead of mucking around with client-side templates you would render pages on the server and then intercept internal links to fetch and inject only the bits that changed between the current page and the next.

React+Redux is basically PJAX, but it's also the polar oppsite. Instead of rendering everything using server-side technologies, you render everything using client-side technologies. And instead of offloading re-renders to the server you keep them in the client when possible (where they can be further optimised thanks to DOM diffing).

Let me restate that: React+Redux allows you to build "Rich Internet Applications" in a way that makes it possible to support JavaScript-free fallbacks out of the box. There's nothing stopping developers from making the HTML output of their React apps richly semantic and accessible either (even though that represents the Eternal War of the web).

The idea is not new[2] but with React it's not only achievable but easily achievable. And unlike Web Components it only needs existing technologies that are widely supported (it even works in IE8).

--

The PandaStrike article you linked is not a rebuttal of React. It's a rebuttal of traditional client-side web applications. It doesn't matter whether they are built with Angular or Backbone or React -- the arguments are mostly universal. The difference is that React is the only option today that (despite not having HTML "templates") allows developers to do something smarter.

Of course React is a land grab. Every open source project is. But it's not an attack on the Open Web anymore than jQuery was an attack on the Open Web before querySelectorAll or XMLHttpRequest landed in a spec. That you're no longer writing straight-up HTML in a text file doesn't mean you're no better off than if you were using GWT[3].

And who says Web Components are the Right Choice just because they're becoming part of the native platform? Sometimes the thing we think we want[4] isn't what we really need[5], even if it's on track to become a standard.

--

[0] http://ajaxian.com/archives/server-side-rendering-with-yui-o...

[1] http://pjax.herokuapp.com/

[2] http://www.stevesouders.com/blog/2010/09/30/render-first-js-...

[3] http://www.gwtproject.org/gettingstarted.html

[4] http://readwrite.com/2014/07/24/object-observe-javascript-ap...

[5] http://www.infoq.com/news/2015/11/object-observe-withdrawn