I've dabbled with NativeScript a bit. It does seem a bit closer to the underlying platform but from my experience of it, it felt incomplete.
I first tried the Angular version before the final version of Angular was released and I recall occasions where the documentation for NativeScript was behind the actual API. I had to look at the actual code samples to figure out the correct APIs.
The next time I looked at it, I tried the regular JavaScript version and I recall having trouble deciphering the API for the SideBar plugin.
This left me feeling a bit insecure about the product. It looks to have a lot of potential though but it could use a bit more polish and better documentation.
The NativeScript site says that I can use their cross-platform wrappers like Button, which delegates to UIButton on iOS and android.whatever.Button on Android. So far, so good. But suppose I now want to invoke some method on Button that exists only on iOS. Can I do that? If not, it's the least-common-denominator, which I'm not interested in using to build an app. I'm thinking about something like:
I'm liking the idea of NativeScript as well, though when doing large image work (or audio or video work), you might still want to drop into native code in a plugin.
So that, for instance, you can be sure exactly when the resources for an image have been deallocated.
For the types of problems the author is describing, NativeScript would not be there to support you. NativeScript surfaces the device API's across the JS bridge, and the serialization across this bridge and pressure on it will always lead to less performant code. You would have to drop to native modules all the same, and then what have you solved?
I think you found my concern. When you are in your app code playing with native API's on the JS-side of the bridge, you are playing with mostly thin proxy objects. These proxy objects serialize your intent across the bridge, evaluate, serialize the response, and send it back to you over the bridge.
This is exactly what React Native does too. The difference is how much of this is done. NativeScript encourages you to stay on the JS side of the bridge- that's why they surfaced those API's. React Native encourages you to cross the bridge to do heavy lifting and then bring the final answer back. This means you typically end up utilizing the bridge a lot more for similar features in NativeScript than you would for React Native. Of course, you pay for this in React Native by having to write Native modules. (I'm purposefully ignoring some of the work I've seen in the RN community to surface these API's in the same way that NativeScript does).
At the bottom of that article there are suggestions on how to mitigate some of these problems, and just about all of them relate to minimizing unnecessary trips across the bridge.
I've played around with NativeScript a fair bit. It's very, very clever, but I'm not really sure what it gives you beyond just doing native development. Sure, you get to use JavaScript, but you have to write separately for each platform if you break out of their custom UI components, and debugging, testing, etc. etc. is more complicated and annoying that just writing in (my case) Swift and using native tools.
I first tried the Angular version before the final version of Angular was released and I recall occasions where the documentation for NativeScript was behind the actual API. I had to look at the actual code samples to figure out the correct APIs.
The next time I looked at it, I tried the regular JavaScript version and I recall having trouble deciphering the API for the SideBar plugin.
This left me feeling a bit insecure about the product. It looks to have a lot of potential though but it could use a bit more polish and better documentation.