Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flutter 3

docs.flutter.dev

Post reply on HN
Print view View original

351–360 of 453 posts

Re: Flutter 3

#351

Post by sgt »

sergiotapia wrote: post #24

We have a react native app and sometimes it fails to build. We go to lunch, and come back no code change now it builds. I'm just sick of the NPM/Javascript bullshit. Does Flutter avoid all of these kinds of issues? I'm this close to scrapping the whole thing.

For mobile apps (not web), I think yes - Flutter solves a lot of these kinds of issues. As with any project, don't just blindly add a lot of dependencies as they may vary in quality and stability, but overall you deal with two things; Dart and Flutter, and it's quite refreshing.

Not as good as native, but if you're going to go cross platform due to various reasons such as development costs, then it's the way to go.

Re: Flutter 3

#352

Post by bschwindHN »

OmahaBoy69 wrote: post #293
bschwindHN wrote: post #245

People are talking about a better developer experience, but hardly anyone is talking about the user experience with apps built with this tech. I don't feel it's great, especially on older devices. Take google pay, a showcase flutter app. It's a laggy mess on an iPhone SE 2016, whereas the "old" google pay ran perfectly fine. On top of that, many google apps I use these days will just freeze and stop accepting touch i…

I'd just like to chip in with my (opposite) experience: I semi-recently developed an app using Flutter and used an iPhone 6, a 6s, and my old Redmi Note 5 as a baseline for performance testing. While I'll admit I wasn't doing anything particularly graphics heavy (at most: sliding modals and some animations), I wasn't able to get things to dip under 60fps on either platform. As for the GPay app, the only performance i…

> I semi-recently developed an app using Flutter and used an iPhone 6, a 6s, and my old Redmi Note 5 as a baseline for performance testing. While I'll admit I wasn't doing anything particularly graphics heavy (at most: sliding modals and some animations), I wasn't able to get things to dip under 60fps on either platform.

I think that's great if you're testing for performance on older phones! Many of them are still quite capable devices. I suspect google isn't doing much of this.

> As for the GPay app, the only performance issue I could notice from testing just now was a dropped frame while quickly scrolling through the "explore" page. Otherwise it works perfectly on my Z Flip 3.

That's a pretty modern phone, right? Have you tried it on your 6 or 6S?

> On the other hand - have you considered upgrading devices? I always hate whipping out the iPhone 6s (same A9 CPU as your SE) because it runs like hot garbage in most cases... a recurring theme in the iOS space.

I haven't, because I think the OG SE is one of the best phones ever made. And I'm not a phone power user in the sense that I'm gaming on it, or doing lots of graphically intensive things. I just replaced the battery on it after using it for 5 years, and it runs everything I want to do perfectly...with the exception of google pay and some of google's other apps.

The issue I have with these basic CRUD apps running with tons of jank is that they're essentially just a UI with some text labels and buttons. For google pay, I want to open it up, navigate a list of people, select one, enter a number, and press "Pay". A computer from the 80s could do this no problem, it's not a graphically or computationally demanding thing. Certainly a computer from 2016 (iPhone SE) is up to the task, and before the google pay transition to flutter, it totally was.

Creating this software that runs slower, with no tangible end-user benefits, is simply pushing us towards more e-waste as people upgrade their devices unnecessarily.

Re: Flutter 3

#353

Post by hunterb123 »

realusername wrote: post #336
the_duke wrote: post #249

Earlier quoted context omitted.

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.

Re: Flutter 3

#354

Post by ducktective »

askonomm wrote: post #339
the_duke wrote: post #42

Despite many maturity issues in practice Flutter is the only realistic option for true cross platform UIs that run everywhere. Apart from Qt , but the licensing issue is a hindrance. And yes, the web backend isn't ideal, but it will improve over time. I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages. Dart isn't horrible and is getting better,…

There's ClojureDart, which means you can now do Dart and Flutter development in Clojure: https://github.com/Tensegritics/ClojureDart

Anyone has used this? Opinions?

Re: Flutter 3

#355

Post by mhoad »

kaba0 wrote: post #329
mhoad wrote: post #159

Earlier quoted context omitted.

FWIW I kind of agree and I’m a big fan of both Flutter and the web in general. There are a couple of web platform technologies that I think are going to take Flutter web from ok to great in the next year or two including. WASM Garbage Collection is going to allow them to move from compiling to JS to WASM. They have already built a WASM compiler ready to go when it lands. WebGPU is another obvious one. Flutter is by d…

Isn’t Dart a very JS-like language? I really don’t believe that compiling to JS would cause any bottlenecks at all, like compiling Java to JS is also possible with Google’s own Closure compiler which produces crazy fast JS output. Sure, JS is not a good compilation target but if you have a sufficiently similar language it is not too hard, and with the man-hours spent on JS JIT-compilers these won’t be slow at all. Th…

For the record Dart has something extremely similar to the Closure compiler built with the same ideas and similar performance AFAIK.

It’s totally fine, impressive even and currently runs the code producing the majority of their revenue via Ads which is all Dart.

But they also recognise (same with Google’s Java teams) that as the platform landscape is changing WASM with garbage collection should be the “next generation” of compile targets for the web for those languages for performance reasons. Both Java and Dart teams already have compilers ready to go once WasmGC is finalised and both of those teams are heavily involved in the standards team driving the broader effort.

I saw some hints at I/O about them building something called “managed languages” into the browser that covered both Dart and Java as well which seems to build on top of that.

I think this has some broader implications for the JS community as a whole for what it’s worth where “compile to JS” is no longer the only game in town in the near future.

As for WebGPU I don’t know enough about the internals to get real deep on the topic but they already have all those problems today but just with WebGL. This too as I understand things is just the “next generation” target for that code.

They (Flutter team) are also rewriting their entire shader pipeline engine from scratch as we speak to take advantage of everything they have learned to date.

In short, I believe them when they say it’s going to be fast and like native.

Edit: I missed your point initially about they could use WASM today. They do that also for parts of the code already (underlying graphics engine is C++ not Dart) but this allows them to move all of the Dart code to WASM now too.

Re: Flutter 3

#356

Post by realusername »

hunterb123 wrote: post #353
realusername wrote: post #336

Earlier quoted context omitted.

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.

Re: Flutter 3

#357

Post by realusername »

hunterb123 wrote: post #156
the_duke wrote: post #42

Despite many maturity issues in practice Flutter is the only realistic option for true cross platform UIs that run everywhere. Apart from Qt , but the licensing issue is a hindrance. And yes, the web backend isn't ideal, but it will improve over time. I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages. Dart isn't horrible and is getting better,…

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…

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

Re: Flutter 3

#358

Post by kaba0 »

mhoad wrote: post #355
kaba0 wrote: post #329

Earlier quoted context omitted.

Isn’t Dart a very JS-like language? I really don’t believe that compiling to JS would cause any bottlenecks at all, like compiling Java to JS is also possible with Google’s own Closure compiler which produces crazy fast JS output. Sure, JS is not a good compilation target but if you have a sufficiently similar language it is not too hard, and with the man-hours spent on JS JIT-compilers these won’t be slow at all. Th…

For the record Dart has something extremely similar to the Closure compiler built with the same ideas and similar performance AFAIK. It’s totally fine, impressive even and currently runs the code producing the majority of their revenue via Ads which is all Dart. But they also recognise (same with Google’s Java teams) that as the platform landscape is changing WASM with garbage collection should be the “next generatio…

Thanks for the informative answer!

Re: Flutter 3

#359

Post by hunterb123 »

realusername wrote: post #357
hunterb123 wrote: post #156

Earlier quoted context omitted.

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…

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

Re: Flutter 3

#360

Post by realusername »

hunterb123 wrote: post #359
realusername wrote: post #357

Earlier quoted context omitted.

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

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

Post reply on HN