Also, did you try either Flutter or React Native afterwards or go straight to native? Did you find them better?
Back when I tried it, it also had a much more incomplete ecosystem, though the google marketing machine was in full swing. I remember not being able to even use the sqlite library without actually spinning up an emulator (as in, I couldn't use it with just plain dart). Dealing with generics was actually difficult/painful (as in just something simple like printing JSON). BLoC seemed like a hack and was more complex than I was comfortable with for using at large scale. Maybe it's better these days.
I will take Typescript over Dart all day every day. I would even take JS with all it's warts over Dart.
That said, Flutter I think is amazing because it is probably going to be hands-down the easiest way to write apps that hit a large number of screens. I think Google will get there first-ish (they have a lot of money and a lot of platforms to support).
Sure, very simple react and vue apps regularly run into memory leaks upon navigating views, with most memory being leaked in UI part managed by nativescript, and not in the JS logic. NS does not do it's job freeing memory from UI.
The natural JS leakiness gets amplified if a leaked part references any JS object.
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.
> Also, did you try either Flutter or React Native afterwards or go straight to native? Did you find them better?
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.
RN also shares the same Java-JS interop issues as NS.
> 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...
* The natural JS leakiness gets amplified if a leaked part references any Java object.