Thanks for explaining more, appreciate it and hopefully others will find this as useful as I did.
> Performance suffers whenever any native API gets called from a JS loop, as exporting Java's objects into JS, and accessing them is very resource intensive. The only way around it was to move loops to Java side of the code.
One of the gotchas around nativescript (and react native) was that trying to do intensive calcuations was never supposed to happen on the main thread. Nativescript was first to add support for background workers[0] which alleviate this.
I do believe of course that you found CPU intensive tasks/looping to be slower on the JS side of things though.
> Flutter is not much better, though feels to be a bit more professionally done. It's too a memory hog, it's too a CPU hog, and it's still gets way more issues over a native app to warrant its use just for economic reasons.
This I'm somewhat surprised to hear, I thought it would have been way better on the memory side of things since Flutter is essentially a rebuild-the-world approach.
> RN also shares the same Java-JS interop issues as NS.
This is inline with what I expected -- the thing about RN when I tried it was that it just didn't have the ability to access native objects from JS as if they were JS objects. Maybe that's changed since I last tried it.
> Performance suffers whenever any native API gets called from a JS loop, as exporting Java's objects into JS, and accessing them is very resource intensive. The only way around it was to move loops to Java side of the code.
One of the gotchas around nativescript (and react native) was that trying to do intensive calcuations was never supposed to happen on the main thread. Nativescript was first to add support for background workers[0] which alleviate this.
I do believe of course that you found CPU intensive tasks/looping to be slower on the JS side of things though.
> Flutter is not much better, though feels to be a bit more professionally done. It's too a memory hog, it's too a CPU hog, and it's still gets way more issues over a native app to warrant its use just for economic reasons.
This I'm somewhat surprised to hear, I thought it would have been way better on the memory side of things since Flutter is essentially a rebuild-the-world approach.
> RN also shares the same Java-JS interop issues as NS.
This is inline with what I expected -- the thing about RN when I tried it was that it just didn't have the ability to access native objects from JS as if they were JS objects. Maybe that's changed since I last tried it.
[0]: https://docs.nativescript.org/core-concepts/multithreading-m...