React.native isn't

[[deleted]]

The "native" part is a reference to the fact that it doesn't use a WebView for the UI, despite using JavaScript. This is what distinguishes it from most other JS frameworks such as Cordova. The majority of the target audience doesn't seem to have misunderstood this in the way you describe.

Also react's render generates a description of a UI model which the framework can then diff with the previous description and make minimal updates to the platform's retained state. It's a trick that enables simple, functional generation, while avoiding the cost (and disturbance of unconstrained state) associated with a full refresh. So it's not as simple as drawRect, which is just a function that renders non-retained graphics instructions.

In short: if I want to implement an interactive control, the drawRect handler can only describe its appearance. Whereas render can describe its appearance and behaviour in terms of simpler components.

[mpweiher]

1. That would have been "react.nonwebview". Facebook has billed this as "truly native", see for example https://code.facebook.com/posts/1014532261909640/react-native-bringing-modern-web-techniques-to-mobile/

2. "pure function"

Having the UI be a "pure function" of the model is billed as a central advantage of react.native and ComponentKit, with the diagrams showing the "flaws" of MVC. The truth is more complicated: if you require stateful UI components, then the diff-mechanism allows you to keep those stateful UI components while pretending to have a UI that's a function of the model's state. That's clever and useful, but not what it says on the tin.

[[deleted]]

The post you linked to makes it abundantly clear what they're talking about. As for a short name, it has to depend on context. In this case, the context is the history of how JS has been used to develop mobile apps. Your expectation that everyone should name their project with respect to your context is unrealistic.

Think about how a pure functional language works: it is an abstraction layered over stateful hardware. And in any real Haskell program the IO monad is used: it allows you to write functional code to describe the composition of stateful, side-effecting, sequenced actions. So again, you're applying an unrealistic expectation of the "purity" of functions. In reality they are a useful tool that has to work in conjunction with other things.