Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I disagree, Flutter is probably the worst choice. React Native is the all around best choice for targeting all platforms natively, otherwise use pure web tech (Ionic + Electron)

The desktop and web targets for Flutter are laughable in their current state. Completely unusable so I consider Flutter to be a mobile only platform at this time.

Another downside is Flutter's emulated UI, it doesn't bridge to native controls like React Native, it's noticeable on iOS especially and will be hard to maintain the fake physics / styling.

React Native is ready for production now for all platforms, including Windows & Xbox via react-native-windows, Web via react-native-web, MacOS via react-native-macos or Catalyst.

Then there's the question as to why would you choose a Google only language and framework with their track record.

With React you can use TypeScript or JS, you don't have to learn a new language or get locked into a framework.



Every experience I had with React Native was truly horrible.

Gigantic, messy JS dependency tree. Constant build breakages after minor version updates. Random flakiness. Unmaintained or buggy native plugins. Questionable support for issues that didn't affect FB.

I wouldn't touch it again.


That's the story with Javascript in general, the tooling is just terrible.

This is one of the underappreciated part of flutter, 4 months of upgrade take me 30min of work and the hot reload just works, good luck with that in the JS world.


I never really have issues with the JS side of things, care to elaborate on what specifically is "terrible"?

Generally what breaks RN is the same stuff that breaks Flutter, native tooling like CocoaPods, Gradle, etc.


> I never really have issues with the JS side of things, care to elaborate on what specifically is "terrible"?

Packages are usually poorly tested (and the fact that it's dynamic language does not help), upgrades are often and painful, the tooling is not very stable in my opinion.

Before settling for Flutter, I've made a limited version of my app in both ecosystem to try both and on the RN one, I already had upgrade issues only after a month...

> Generally what breaks RN is the same stuff that breaks Flutter, native tooling like CocoaPods, Gradle, etc.

You need much less native tooling in Flutter since almost everything is canvas based. Broken stuff on the native part is very rare, I can't really remember anything like this from the past 3 years. I had to upgrade the graddle version once but that's about it.

I have ~30k lines of dart excluding tests and about 15 lines of Kotlin (and zero in ios), that's the kind of ratio we're talking about.


> Packages are usually poorly tested

Just in general? I don't know of any packages in my app that are poorly tested. Simply do not choose dependencies that don't meet your standard, whether it's TS or Dart.

> and the fact that it's dynamic language does not help

Most packages nowadays are written with TypeScript or Flow. JS itself is fast and stable thanks to the billions put into the VMs.

> upgrades are often and painful

You don't have to upgrade. In the early days things were more painful, but I've upgraded the past few major React and RN versions with no hassle.

> the tooling is not very stable in my opinion.

Seems stable to me since the last couple years.

Personally the apps that Flutter makes are of worse quality vs RN apps. Emulated native will always feel cheap compared to real OS controls.


> Just in general? I don't know of any packages in my app that are poorly tested. Simply do not choose dependencies that don't meet your standard, whether it's TS or Dart.

In general, it's not really part of the js culture. Sure you have those very nice packages which have stellar dev practices (such as react) but that's far from the norm.

The testing story also feels better with Flutter to me, one nice thing about the canvas based rendering is that you have very good and useful screenshot testing.

> You don't have to upgrade. In the early days things were more painful, but I've upgraded the past few major React and RN versions with no hassle.

If you don't upgrade, you're left behind and it will become more and more painful to upgrade later. Upgrade policies of languages also have to be taken into account for the dev time.

> Personally the apps that Flutter makes are of worse quality vs RN apps. Emulated native will always feel cheap compared to real OS controls.

No mainstream app is using native controls anyways. Facebook doesn't, Twitter doesn't, Whatsapp doesn't...

Additionally, if you have a terrible phone, this is where Flutter stands out in terms of speed. That's why it's so popular in developing countries. On my Galaxy J3 (bottom of the barrel of samsung), my app is the fastest app I have installed.


> In general, it's not really part of the js culture

As opposed to the Dart culture? Quite a sweeping generalization. There's bad packages in every ecosystem. There's really good packages in every system. Pick the right ones.

> one nice thing about the canvas based rendering is that you have very good and useful screenshot testing.

React you can snapshot test the component tree, as well as diff images on each platform.

> If you don't upgrade, you're left behind and it will become more and more painful to upgrade later. Upgrade policies of languages also have to be taken into account for the dev time.

Sure, I update major versions every year or so. Past 2 years of React Native have been easy.

> No mainstream app is using native controls anyways. Facebook doesn't, Twitter doesn't, Whatsapp doesn't...

That's plain false, they for sure do.

> Additionally, if you have a terrible phone, this is where Flutter stands out in terms of speed. That's why it's so popular in developing countries. On my Galaxy J3 (bottom of the barrel of samsung), my app is the fastest app I have installed.

React Native performs well on older devices as well.


> As opposed to the Dart culture? Quite a sweeping generalization. There's bad packages in every ecosystem. There's really good packages in every system. Pick the right ones.

Not every ecosystem is created equal, they are better testing cultures than dart (such as ruby for example) but they are also worse ones and javascript is definitely worse at that. Packages you install will be on average less tested and less care will be put into the dev experience than in some other languages.

They are exceptions of course such as RN & React but they are far outside the norm.

> Sure, I update major versions every year or so. Past 2 years of React Native have been easy.

As with any other JS project, RN and React are not the main issue but everything around it is and you certainly need extra packages.

> That's plain false, they for sure do.

Have a look at those apps and tell me if they look Material (they don't).


Highly recommend trying expo.dev sometime they have come a long way in providing support for native modules and take care of all that underlying "mess" for you.


I absolutely agree with this. At this point I don't really think there's much reason to _not_ use Expo. I found setting up RN without Expo absolutely awful, and switching to Expo was the only reason I didn't start rebuilding my app in Kotlin+Swift.


There's Expo if you don't want to setup your own stack.

You certainly don't need it though, I have no issue with my React Native stack.

Flutter has its share of similar tooling issues, most of the time its native things like CocoaPods that affect both projects.

RN has a huge amount of plugins, a lot that are very good quality. It's up to the dev to pick quality dependencies.


> React Native is ready for production now for all platforms, including Windows & Xbox via react-native-windows, Web via react-native-web, MacOS via react-native-macos or Catalyst.

All platforms ... except Linux. React-native-gtk is abandoned as far as I know.


You can wrap the React Native Web target in Tauri or Electron for Linux.

There's also https://github.com/valence-native/valence-native that can use either wxWidgets or Qt.

All in all it's better than the current Flutter web / desktop implementation.


Politely, I would point out that the makers of Ubuntu have said that as far as they are concerned Flutter is the future of desktop app development on Linux and all their projects moving forward will be using it by default because they believe in it so much.

They just started in Ubuntu 22.04 by rewriting their installer (I.e the very first thing users see when coming into contact with Ubuntu) to be a Flutter app.

It has proper first class support rather than the hacky and unofficial (and possibly poorly maintained) workarounds you suggested to do cross platform development.


> There's also https://github.com/valence-native/valence-native that uses Qt.

There's been more than a year without a commit in this project, I'm not going to say it's abandoned yet but that's not that far off I guess, good luck with the issues you'll encounter.

> You can wrap the React Native Web target in Tauri or Electron for Linux.

That's one of the only realistic solution for now in my opinion.


> There's been more than a year without a commit in this project, I'm not going to say it's abandoned yet but that's not that far off I guess, good luck with the issues you'll encounter.

Or it's stable? Look at the codebase, it's a pretty dead simple bridge. Make your app open source and all those Linux devs you're supporting can help you out!

> That's one of the only realistic solution for now in my opinion.

Yup, and you get it for free with if you build your app with RN and React Native Web.


> Or it's stable? Look at the codebase, it's a pretty dead simple bridge. Make your app open source and all those Linux devs you're supporting can help you out!

Even the simplest bridge needs upgrades, unless you want to be stuck with react 16.

> Yup, and you get it for free with if you build your app with RN and React Native Web.

That's better than nothing I'd say yeah. That's kind of the issue with react native, you need platform-specific rendering code and since companies don't really care that much about linux desktop it's not really there.


Don't forget native targets for TVs (well android TV at least)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: