You tell React that you'd like to Render component X inside DOM element Y, and that's really all React does. There's no architecturing your project around React.
[1] https://facebook.github.io/react/docs/react-component.html
Yes, if use react, you need an architecture compatible with the reactive paradigm.
I'm not sure how I feel about this. One one hand he's clearly biased. On the other hand, for a new project if he doesn't promote it no one will. It's important to market your product even if that product is an open source project.
Although if this was a serious journal or newspaper there would be a very clear disclaimer somewhere. Which is lacking in this article.
You call a library.
A framework calls you.
I don't know React, so can't say which it is.
On the flip side, it's nowhere near as all-encompassing as Angular or Ember. No built-in AJAX handling, no complex data model manipulations, no preferred project architecture. So in that sense, it's much closer to the library side of things.
People[1] who were there when it started seem to be OK with calling it framework:
http://queue.acm.org/detail.cfm?id=2994373
[1]Pete Hunt, who at the time was an engineering manager at Instagram as well as one of the more prominent members of Facebook's React core team, is willing to shed some light on React's beginnings.
Also helping to tell the story is Paul O'Shannessy, one of the first engineers at Facebook to be dedicated to React full time.
The author writes off solutions such as Redux which are designed to solve nearly all of the "problems" the author assigns to React because they add extra layers to the application, however in reality, separating your data and your views is EXACTLY the point - that's what helps to make complex applications manageable.
The article is really an advertisement for the authors own framework Binding.scala, rather than a critical look at React.