The value of cross platform toolkits is all about cost reduction. It is cheaper to staff up on a single skill set rather than to staff up on three entirely separate skill sets. As of 2022, that single skill set is most likely web SPA development.
Flutter and Dart are no where near as similar to React or Angular as Ionic or React Native. Even the most experienced web developer will need time to learn Flutter. There are also some positives to Flutter that you should consider. Of the three PoC apps, the Flutter app had the fewest lines of code and took the least amount time to develop (once you know Flutter).
> The value of cross platform toolkits is all about cost reduction.
what i want to know is, how do cross-platform tools lead to better software products (less bugs, faster iteration, higher quality features, smoother animation, higher performance etc) for customers?
From my experience anything you could have done natively you can bridge to RN.
So either create a native app if you have resources, otherwise, create a RN app and use either custom or community extensions.
That's the beauty of the flexibility and extensibility of React.
React Native Web works so well I use it as my main for even web-only projects.
You basically get a mobile and desktop site for free with your app. Or native apps for free, whichever way you look at it.
Non web-devs seeing the word "JavaScript" and running away. Or stated otherwise, having to learn React + the JS ecosystem (minimized within RN) on top of all the mobile specific stuff.
I had no previous experience with Android or iOS or the languages and was able to get caught up, but there was a curve to figuring out code signing, the app stores, deploying, permissions, etc.
For those non web-devs, they will have to learn some of web. You will need to learn the tooling like the other platforms. You don't really need CSS knowledge or HTML just basics. RNW implements RN stylesheets which is a streamlined subset of CSS.
The main thing is learning React, but SwiftUI was inspired by React so it should be easy for at least iOS devs to grasp it.
Type some CJK in here and watch as each letter appears 500ms late, or try to bring up the emoji input on MacOS
https://flutter.github.io/samples/web/form_app/#/form_widget...
Rendering to a canvas does not "work reasonably well", unless you want to go back to Flash days (but controlled by google this time)
(And I sadly just can't buy the philosophical issue anyway, frankly: if anything, I'd argue the biggest flaw with the web is it has a million nit-picky features when it should ONLY offer JavaScript+canvas, as third parties have a hope of reimplementing that correctly, unlike HTML+CSS. To the extent to which there were important behaviors people liked, such as accessibility, those should come from higher-level frameworks instead of being baked into the lowest level of the system.)
> behaviors people liked, such as accessibility
lol
(As for accessibility, I appreciate you might find my wording funny, but it isn't a laughing matter really.)
That would break the web, though? One of the biggest _strengths_ of the web is backwards compatibility.. I, for one, am grateful to use modern browsers to consume older content and apps.
Blazor, Uno, Qt, Yew, Flutter,....
The craziness of faking UIs with paragraph tags massaged via CSS and JavaScript into a drop down menu.
Now they are back, even Google Docs is moving into it.
[0] https://yew.rs/
React Native has a much larger ecosystem and feature set, including desktop & web targets, native view, many extensions, huge support, a lot of jobs.
NativeScript seems to just tie into native APIs, not the view layer, right? React Native bridges to native controls so you get native look and feel.
Flutter emulates the native view later by drawing everything itself which can be off, but it's performant at least.
If I preferred Web components, Svelte, Angular, or Vue I'd see the appeal of NativeScript.
React Native is not based on NativeScript though, they are two different implementations.
They all have their strengths and weaknesses, you should always chose one where the strengths align with your app and your team. I see it something like this (of the ones I know enough about):
Flutter - Brilliant for somewhat simple apps talking to an api that don't need to share any ui with the web. Sonos is a brilliant example. Banking/Utilities, Smart Home, Restaurant/Takeaway (I think here in UK the Pizza Express app is Flutter). Things that need a "flashy" but consistent ui. In many ways I see Flutter as the new Adobe Flex/Flash.
React Native - Brilliant where you need a more native feel or need to drop to native more regularly. Good WebView support if you need them, mixing web and native views together. Also good to extend native apps. Facebook and other social media apps are a good example.
Ionic/Capacitor (or the older PhoneGap/Cordova) - You have a small team and need to get a fully cross platform app (web/mobile/pwa/desktop) done quick. If you are just calling a few HTTP apis (a CRUD app) and rendering some screens you can't be more productive than with this platform, particularly if sharing views with the web. Brilliant for enterprise, or internal apps. Good examples are the UK NHS apps. Performance on any mobile hardware less than 5yo is better than good. I have used NativeScript with Capacitor, they work very well together when you need to access native functionality not available with the standard capacitor apis.
(I don't know enough about Kotlin and its cross platform tools)