Comment by samwillis | Hacker News Reader

Comment by samwillis | Hacker News Reader

Parent Full thread

The obsession with the concept of a "one true cross platform toolkit" even just for mobile is wrong, it will never happen.

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)

I recently blogged about a comparative evaluation of the three technologies you identified as cross platform (Flutter, React Native, Ionic) over at https://glennengstrand.info/software/architecture/ionic/reac... by implementing a feature identical PoC app in each tech stack.

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.

cost reduction rarely leads directly to product quality though...

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?

What's the weakness to React Native?

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.

> What's the weakness to React Native?

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.

Pretty good point, haven't thought that way since I was a Web dev, then React dev, so transition to RN/W was easy.

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.

Flutter Web exists and works reasonably well.

No, it doesn't. Try dealing with accessibility, emoji, screen readers, non-English languages. The people in charge left all of that "TBD" and now they've backed themselves into on unsolvable corner with their "render everything to a canvas". They didn't understand what they were dong. The web apps feel like Swing in Java.

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...

The emoji input does work on Chrome OS

>Reasonably well

Rendering to a canvas does not "work reasonably well", unless you want to go back to Flash days (but controlled by google this time)

That's a philosophical issue, not a functionality one: something can work reasonably well even if you hate the world that results.

(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.)

This is a strange position considering I would rank the JavaScript engine as, bar none, the most complex and difficult part of the entire browser stack to develop and keep maintained, and it continues to grow and become more and more complex along with the runtimes implementing it, which were already incredibly complex by design.

> behaviors people liked, such as accessibility

lol

I don't disagree--though I know people, including myself, who have managed to pull off either all of or most of the work required alone--and so in an argument about the JavaScript engine I would argue it should be a VM only, such as WebAssembly.

(As for accessibility, I appreciate you might find my wording funny, but it isn't a laughing matter really.)

> I'd argue the biggest flaw with the web is it has a million nit-picky features when it should ONLY offer JavaScript+canvas

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.

This is a "the web made a fatal mistake in the past and should have done X" argument and not a "the web should now do X" argument, though if you want a forward-looking suggestion we need to immediately stop adding NEW behaviors.

accessibility is not a behavior that "people liked". It is enshrined in law in so many countries that they _have_ to be at the lowest level of the system.

I would argue it was enshrined in law because people liked it so much they demanded it, so maybe that's a semantics issue? That said, I do not believe the law insists that it be in the lowest level: the law merely insists that it exist for every site. It is convenient to put it at the lowest level if possible, but now it is just one more thing that literally every browser has to implement from scratch, and so the world that results is that the only company capable of making a good web browser is Google. There are sane reasons why accessibility is not considered part of a CPU (and thereby by most other reasonable runtime engines).

People with reading disabilities, vision issues, etc are rarely the ones being heavily represented in parliaments. Accessibility is truly a case of things being earned through spilled blood, and while there's probably much fewer people dying because they can't read the text on your website, it's a natural extension of the physical world. While the laws do not say that it should be up to the browser, it becomes natural that this moves to the lowest common denominator. Should it not be part of browsers, the moment any dominant browser comes in (say, Chrome) and implements it would lead to thousands of websites relying on this behavior from the browser, leading to "Works only on Chrome" situations, and other browsers most likely rushing behind to also support that feature.

Therein lies the future, thanks WebAssembly.

Blazor, Uno, Qt, Yew, Flutter,....

Although WASM is brilliant, I don't think its right to use it to recreate the whole UI drawn to canvas. You loose all accessibility integration with the OS either locking out users or making your life much harder reimplementing it. WASM is perfect for graphics and backend processing, see Figma it uses WASM for drawing the canvas but the rest of the ui is native web with all the accessibility tools that come with the browser/os.

My life was made much harder when Flash and Silverlight like tooling was taken away.

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.

Yew doesn't use the canvas, it uses the DOM iirc.

Wrong

https://flutter.github.io/samples/web/form_app/#/form_widget...

He talks about Yew [0], and you link to flutter?

[0] https://yew.rs/

Sorry.

I stand corrected on that one.

True, although if you are trying to build a cross platform app where the web is a major part of it, I wouldn't even look at the Flutter and default to Capacitor.

If by reasonably well you mean barely hits 20 fps on Desktop and unusable on mobile then sure, it works reasonably well.

+1 for Ionic. I have been able to scale complex B2B and B2C software apps (not games) very well with it. v1 to v2 was rough but since v3 its been great. I'd strongly recommend this to anyone who wants web and mobile apps with one codebase.

We evaluated those 3 options to develop an application used to configure, control and monitor battery systems at Northvolt, and reached very similar conclusions regarding the strengths of each platform.

For some reason NativeScript is never mentioned on HN.

NativeScript looks interesting and would be where I reached if React/RN TypeScript wasn't my preference.

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 based on NativeScript – which provides the JS layer and access to native APIs RN needs.

After looking into it, NativeScript does use native UI controls, not webviews.

React Native is not based on NativeScript though, they are two different implementations.

Love NativeScript, haven’t used it as the main platform but combined with Capacitor is super powerful. Incredible work.

How does that work, doesn't Capacitor already provide its own bridge to native APIs?

https://blog.nativescript.org/announcing-nativescript-capaci...

https://capacitor.nativescript.org/

It can be confusing.

Only for specific APIs - nativescript does everything.

Xamarin?

+1

Xamarin is very popular in enterprise

Reply on news.ycombinator.com