For those who are looking for an alternative to Flutter/React Native, please check out Nativescript @ https://docs.nativescript.org!
It's different in a few key ways:
- Draws native components (Flutter draws every pixel)
- Pure JS native (i.e. JNI powered) shim layer (you can write stuff like `const intent = new Intent()`)
- Typescript as first-class (not quite so with React Native, and IMO Typescript > Dart as far as type systems and ergonomics are concerned)
- Ability to use both Angular and Vue to structure your app (there's also projects out there like Svelte-Native, which is extremely promising from the performance perspective)
- More community driven project (with Progress standing behind, following the open-source & extra features business model)
Nativescript has supported the web worker paradigm for multi-threading for a while now[0]. Also, I'd like to point that for a lot of applications (especially the ones that are basically informational without much interaction or client-side work, this actually isn't an issue early in the development process.
I've used Nativescript on client projects, and it is fantastic for prototyping, with well demarcated paths to performance optimization. Since you can easily use native screens/controllers/etc with it, at the very least you can use it for fast prototyping then drop all your custom code in.
Do you know of any hybrid frameworks that are not running JS code on the main thread by default? And by JS code I assume you mean display-related code, because Flutter suffers from this same issue, do too much hard work on the main thread and it stalls (as anything would). Even on android itself[1] you need to do some extra work to make sure your UI-related heavy lifting happens off the main thread:
> However, when the main thread’s messaging queue contains tasks that are either too numerous or too long for the main thread to complete the update fast enough, the app should move this work to a worker thread
I wouldn’t necessarily write this off. Doing UI-related work directly in the main thread has a lot of benefits -- your click listeners can take effect immediately and make all the necessary UI updates before the next event is processed. With event handling in a separate thread, it can be harder to make things robust (filtering out double taps, preventing flashes of unfinished/unstyled content, etc).
Of course you do need to make sure that everything that could be even slightly expensive is shipped out to a background thread. JS is weak in that respect.
Moving everything to a background thread does fix that problem, but I think it’s overkill. A lot of mobile apps would be faster and more responsive if they used the main thread more. You just have to use it right.
I personally think the best way to learn it is to get your hands dirty and use it to build something, so I'd recommend that, but there are certainly resources out there as well.
This sounds like an excellent bug report for their playground feedback[0] repository, I'll make a ticket for you[1], please feel free to go in and fill out more information to help them help you.
Please note that the links in the issue you submitted need to be changed because you copied the link text, which are only partial, rather than copying the link target URLs.
It's different in a few key ways:
- Draws native components (Flutter draws every pixel)
- Pure JS native (i.e. JNI powered) shim layer (you can write stuff like `const intent = new Intent()`)
- Typescript as first-class (not quite so with React Native, and IMO Typescript > Dart as far as type systems and ergonomics are concerned)
- Ability to use both Angular and Vue to structure your app (there's also projects out there like Svelte-Native, which is extremely promising from the performance perspective)
- More community driven project (with Progress standing behind, following the open-source & extra features business model)