I'll try and boil it down to some points that hopefully build on each other:

- In the mobile development there are a few approaches, including but not limited to: full-native, near-native, and webview (these aren't official terms, I just made them up)

- "full-native" is using Java on Android, Swift/ObjC on iOS, generally implying using all the tooling/patterns/etc that come. This is the hardest in terms of learning curve, Swift concepts often do not translate to android, so it's like two steep climbs.

- "near-native" is using some library/tool that compiles down to JVM bytecode/native code but usually implies bringing in new/alternative tooling (integration levels vary) that holds the promise of having less warts. This is where tools like React Native[0], Vue Native[1], NativeScript[2] fit in (I'll explain how later).

- "webview" is when you just make a mobile-friendly webpage and embed it inside an app by simply displaying it fullscreen. Android/iOS also has features these days where you can pin webpages that act like mobile apps to screens, and IIRC android "instant" apps are the same concept. These have been criticized heavily for performance/platform integration issues. This is where tools like Cordova[3] and Ionic[4] fit in.

SIDENOTE: FirefoxOS (RIP) was a mobile OS that took this to the extreme, having everything just be a webview and investing in the browser ecosystem heavily.

- In terms of difficulty/ramp-up-time/vendor-lockin, webview < near-native < native -- assuming that you know web tech already, and that the near-native toolchain is indeed easier.

- While React[7] started by targeting the web exclusively (though I think it might have always been a goal to branch out), they built in enough generalization to support react-native, whose feature is that it moved the boundaries a bit -- it works using native platform code to run a JS processing thread, and offers interop to native features directly. So it's not a webview, and not completely native, it belongs in the near-native camp but it uses concepts that allows you to treat it almost like a webview app.

- The existence of React Native is a huge difference-maker for react. If you want to sell your team on react, the ability for a frontend developer to easily handle mobile application development is a strong selling point.

- Since react native's near-native mechanism is well known, other projects have started to incorporate it -- Angular[5] proponents (and actually any js app in general) can use NativeScript[2] and Vue[6] proponents has been working on Vue Native[1] for a while.

- React Native, Vue Native, NativeScript are all attempts to bring the render-in-a-thread, shim-to-native-code-where-possible paradigm to different frontend frameworks that have existed.

- There are differences between Angular, React, and Vue that make it difficult for one project to interface with all of them (theoretically NativeScript could do it, as it supports any old JS app), and those differences are often opportunities for tight integration and developer ergonomics/features.

- In the end, all this is meant to enable native-feeling application development with minimal vendor/SDK lock-in and difficulty.

- There are other interesting approaches in the near-native space like https://flutter.io/ (almost like web view except natively by drawing every pixel on the screen) and http://www.lambdanative.org/ (take a small lisp runtime with you)

[EDIT] - As pointed out in the subcomments on this post, React Native does not 'compile down' to native code -- that is true. What I should have written was that it integrates with native code, not Web/DOM driven integration points.

[EDIT2] - I forgot to include/mention nativescript-vue[8] which is my favorite.

[0]: https://facebook.github.io/react-native/

[1]: https://vue-native.io/

[2]: https://www.nativescript.org/

[3]: https://cordova.apache.org/

[4]: https://ionicframework.com/

[5]: https://angularjs.org/

[6]: https://vuejs.org/

[7]: https://facebook.github.io/react

[8]: https://nativescript-vue.org/