Live data from Hacker News

Flutter 3.47

flutter.dev

91–100 of 231 posts

Re: Flutter 3.47

#91

While I've used Flutter since Alpha, I've been away for a few years. A few things have shocked me in these release notes: how come Impeller still wasn't the default engine for all platforms? Also, why are they migrating to WASM if one of the core features of Dart is compiling to JavaScript? Finally, how come multi window support only get viable now, after four years having desktop support? Honestly, Flutter is an ext…

> how come Impeller still wasn't the default engine for all platforms

Because Impeller has had quite a bumpy ride. Even as recently as June I reported a bug/regression with basic stuff (lines with partial transparency on desktop). All my Android apps are still built with --no-enable-impeller because I've had many instances where the app just shows a blank screen due to driver conflicts.

It may be getting close to stable now, but it wasn't a smooth transition at all.

Re: Flutter 3.47

#92
post #81

I still prefer React Native with Expo over Flutter, mostly for practical reasons: * Language and hiring: TypeScript has a much larger developer pool. Dart is a solid language, but finding experienced Flutter engineers is harder. * Platform model: React Native maps much more naturally to native platform concepts. Flutter owns much more of the rendering stack, which is powerful, but also creates another abstraction lay…

You should try Dart/Flutter again, they've improved a lot.

- Dart. It's richer than JS/TS with stronger type safety, and seems purpose-built for UI. Fewer Dart developers than JS, but I'd argue those JS developers cannot be immediately effective coding React Native (Expo) anyway.

- Emulated components vs. real native components. For multi-platform apps, this is actually desirable. These kinds of apps have their own design system.

- Speed. In my experience, it's negligible, but maybe because I keep using the latest version.

- Ecosystem. Flutter/Dart occasionally introduces "breaking" changes (such as migration to null safety, and recently deprecation of CocoaPods). Community very quick to update their plugins and adapt. Some abandoned plugins were immediately forked to keep being maintained.

- Migrating to native platforms, easier for agents to read an RN project. I'd argue it should be _easier_ to do that with Dart since the language is less "ambiguous" than JS.

However it's not perfect. My complaints:

- Not ideal for web apps with lots of FIRST-time visitors, due to initial download. There are some attempts to solve this, e.g. deferred loading, but I think inherently it's unsolvable since you need to download the whole world (a few MBs) to have the app running on your browser. That's why for this scenario I use SvelteKit. But if you already have a mobile app and want to get a web app "for free", this is a useful feature.

- WebView support is inconsistent across platforms (I'm looking at you, Windows and Linux).

- Text fields are quirky on Android TV.

Re: Flutter 3.47

#93
post #81

I still prefer React Native with Expo over Flutter, mostly for practical reasons: * Language and hiring: TypeScript has a much larger developer pool. Dart is a solid language, but finding experienced Flutter engineers is harder. * Platform model: React Native maps much more naturally to native platform concepts. Flutter owns much more of the rendering stack, which is powerful, but also creates another abstraction lay…

While all of the points you brought up are valid, I've hated every react native app I've ever had to work on. Not because of react native itself, but because they usually take random react developers to work on these apps and the structure they create is absolutely horrible to work with (compared to, for example, native apps).

What was your experience on that aspect with Flutter?

Re: Flutter 3.47

#94
post #81

I still prefer React Native with Expo over Flutter, mostly for practical reasons: * Language and hiring: TypeScript has a much larger developer pool. Dart is a solid language, but finding experienced Flutter engineers is harder. * Platform model: React Native maps much more naturally to native platform concepts. Flutter owns much more of the rendering stack, which is powerful, but also creates another abstraction lay…

>real native components

Since when does React Native use real native components? Last time I've checked it wasn't capable of doing ANYTHING with my phones NFC scanner or native camera...

With flutter I can just build a Kotlin component and integrate it easily into my app. Also Flutters performance is extremely good, I dont know what you are on about. Our app is used on extremely old phones and has great performance. (I am not even a professional android/flutter dev, so I didnt optimize for performance).

Re: Flutter 3.47

#95

The one thing I hate about flutter is the ui code having an ungodly amount of nested brackets.

While you aren't wrong, in my experience when the amount of nesting starts giving me bad vibes it usually indicates that something can be refactored out as a standalone widget.

Still, Flutter now feels ancient to use compared to something like Compose, in that regard.

Re: Flutter 3.47

#96
post #81

I still prefer React Native with Expo over Flutter, mostly for practical reasons: * Language and hiring: TypeScript has a much larger developer pool. Dart is a solid language, but finding experienced Flutter engineers is harder. * Platform model: React Native maps much more naturally to native platform concepts. Flutter owns much more of the rendering stack, which is powerful, but also creates another abstraction lay…

Funny to see speed in there, my experience is the opposite.

Im a very happy Flutter dev and it's always been odd to see so much negative sentiment around it when there are public discussions.

Re: Flutter 3.47

#97

great for mobile apps, fine for desktops, basically unusable for browsers unless you do wasm, if web can be revamped/improved it can be the best option for cross platform GUI

> basically unusable for browsers unless you do wasm Relying on WASM means that nobody on Apple platforms who has Lockdown Mode enabled for better security will be able to use it.

I see that as a win

Re: Flutter 3.47

#98

Tested lots of flutter desktop apps on Github last year. All have sluggish animation. FPS rarely reached 60.

I do more mobile/web Flutter dev so haven't got experience here but I'm surprised to hear that. Can you name some examples?

Re: Flutter 3.47

#99

Are Flutter and React Native still viable choices today? I get the impression that more are going for native mobile, KMP or PWA.

Every time we tried it, it resulted in a worse experience than we knew could be done using native stacks. It is like using sand as a foundation for your house. Random version updates break random things. As soon as you need something a bit advanced on the platform, you are stuck with some barely supported library. Easy to start, hard to maintain and hard to ship a solid product.

Re: Flutter 3.47

#100
post #81

I still prefer React Native with Expo over Flutter, mostly for practical reasons: * Language and hiring: TypeScript has a much larger developer pool. Dart is a solid language, but finding experienced Flutter engineers is harder. * Platform model: React Native maps much more naturally to native platform concepts. Flutter owns much more of the rendering stack, which is powerful, but also creates another abstraction lay…

While all of the points you brought up are valid, I've hated every react native app I've ever had to work on. Not because of react native itself, but because they usually take random react developers to work on these apps and the structure they create is absolutely horrible to work with (compared to, for example, native apps). What was your experience on that aspect with Flutter?

I agree. RN has historically attracted a lot of web developers who treat mobile like a React website, and the result can be terrible. But I've seen exactly the same architectural problem in Flutter: huge widgets, mixed responsibilities, state everywhere, and very little separation of concerns. The framework doesn't protect you from bad engineering.
Post reply on HN