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.
> 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.
The reality is that while it may ease the transition a bit, your front-end developer will be having to dip into Swift/Obj-C often enough that eventually the supposed benefits here are moot.
Personally I think it's worth just taking the hit and learning the framework. A good book will have you productive within a week. The learning curve these days is easier with Swift and now that front-end developers are used to things like React, Flex Box, and so on, the concepts behind making iOS apps are not as different and alien as they once were.
I can tell you, from experience building multiple apps in production from scratch, that that's not the case.
You practically never get to touch Obj-C or Java, and if you do it's usually to tweak a line or two in some third-party library which requires little to no knowledge of Obj-C or Java.
Good summary, one addition to the corrections others already made:
Android Instant Apps are not web apps. They are normal native apps, but limited in size (4MB), can be launched from a weblink and don’t get installed permanently on the device.
Correct. It does interoperate with it though, and the built-in components are indeed in native code but called via the JS bundle. Of course, a lot of external libraries are just Views-within-Views and give up some of the nice performance benefit of the native code underneath, sadly...
This is what I meant, and also what I meant when I mentioned that React Native pushed the boundaries (that I laid out above) -- it's a weird in-between of near-native, webview and native.
- 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/