[t1amat]

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?

[hammerandtongs]

https://docs.nativescript.org/runtimes/android/advanced-topi...

Perhaps I'm misunderstanding your concern, but it doesn't look like js allocates for the actual object just a proxy for the java.

[t1amat]

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.