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 extremely enjoyable development experience I would recommend anyone I care for to stay away from. The fact it's developed by Google doesn't help: it's a matter of time before they kill it like they did with so many UI libraries and frameworks already, specially with JetBrains developing Compose Multiplatform and the Android team going all-in in the Compose strategy.
Flutter operates more like a 2D game engine. It renders its own views, which involves a lot of arithmetic operations, making WASM a more efficient option than JS.
WASM or JS doesn’t matter. The reason is Canvas instead of DOM. Flutter apps render to the canvas element, because this is the only option for the 2D game engine you mentioned.
> 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.
Unless it is a trivial app, it would still require quite some effort to port (and test), which has a cost. What do you gain by using Flutter that compensates for that risk?
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 layer between the app and the platform.
* Performance: Flutter can absolutely be fast, so I would not claim otherwise. My experience, however, is that RN has required less work to get interactions and animations that feel consistently native.
* Ecosystem: RN benefits from the broader React, TypeScript, JavaScript, and native ecosystems. Expo has also improved dramatically and now covers a large part of the usual mobile platform work.
* Platform-specific features: neither framework completely eliminates native code. Things like widgets, Live Activities, Dynamic Island, extensions, NFC, and other platform APIs eventually bring you back to Swift/Kotlin anyway.
* Migration to native: if the long-term destination is Swift and Kotlin, I find RN a better intermediate representation. Its component model and platform integration are closer to native concepts, which also makes the codebase easier for agents to translate incrementally into proper native applications.
That said, these are trade-offs, not claims that Flutter is bad. Flutter has improved a lot, and for teams that want a highly consistent cross-platform UI, its rendering model can be an advantage.
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).
As someone who used all these frameworks professionally for years, I highly agree. Although, I do not prefer Expo due to it's highly annoying build system and dependency hell, but React Native itself in that case. While I understand Google wants a horse in this race, Flutter doesn't feel like a horse to bet on.
- Dart is a really _ugly_ language with lots of tiny annoyances. Its as if someone took worst parts of Java and Javascript and turned them into a language. Terrible to write, terrible to read, terrible to use.
- While there is no Skia anymore, the whole custom rendering of Flutter often caused more trouble than not, from the UI implementation itself all the way to specific low-end chipsets not being supported.
- Ecosystem propagates these insane architectures that don't make much sense and are made to either print apps as fast as possible or to emulate some Clean Code like behavior.
- Web still feels terrible to use, even after all these years.
Since I'm not happy with any of these, I've even taken upon writing a framework of my own that renders into native UI and works with any language (gonna shill it here https://hypen.space). It was inspired directly by years of working with mobile and experiencing the pains of crossplatform development such as Flutter and Expo. We can do better than these!
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 was forced to migrate from pure native development to React Native and Redux is one of the stupidest things I ever witnessed. Or at least the way the previous devs setup that thing, because it’s so easy to make costly mistakes with it.
I lost so many days of my life profiling and debugging to figure out why hundreds of components were re-rendering when a tiny thing changed somewhere completely unrelated
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.
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).
You're mixing UI components with platform APIs. React Native does use native platform-backed views. NFC and camera access are separate concerns. If an API isn't exposed, you can write the native Swift/Kotlin module and bridge it, just like you would integrate native code into Flutter. Camera support also already exists in Expo.
Flutter: if you want a pixel perfect version of your app that looks similar on Android and iOS. Some quite popular apps use it and make a shit ton of money, for example Headspace. More here: https://flutterhunt.com/
React Native: totally viable, because core business logic is the same. If you want native UI elements and all the iOS Liquid Glass stuff, but don’t want to have to completely separate code based, React Native is a viable option if you don’t mind installing lots of third party packages for functionality you get out of the box in Flutter or true native apps.
Native mobile: I have one smaller app with quite a custom calendar view, written with Claude Code natively for Android and iOS. Coding agents help and you get maximum control. Mentally, it’s a bit cumbersome to direct you agent to do everything twice. While one platform can serve as a reference implementation for the other, it’s kinda annoying mentally "to do the same feature all over again and test and direct the agent". But it’s doable.
KMP: No experience, I just hate most things around Android.
PWA: That ship has sailed. Nobody knows about PWAs, most PWAs are bad. It’s a bummer really.
Capacitor: make an SPA (offline-first preferably), and use native code plugins via Capacitor. Still quite feasible, comparable to Flutter in the sense that you need to build a custom UI or use a fake version of Liquid Glass and Material. I use Ionic for that, but it’s a bit dated (still on Material v2). Heavily depends on your skills as a web dev to get good UX.
Native was always the best. It was just time consuming, requiring a bigger team. Now with AI helping out, it's probably the best option by far. I still like Flutter a lot though because you can get stuff done fairly quickly and even apply Material design to the iOS apps or vice versa if you want to (if it's a business app where the design doesn't matter too much). Or if you e.g. target win32
Even with AI, maintaining feature parity between Android, iOS, Windows, Linux, and Mac is extremely complex. Flutter makes it so much easier. If I were doing native, I'd probably have to drop all desktop platforms.
In most cases yes but if you don’t want native elements and you want your app to look exactly the same on android as on iOS then flutter is a better choice. Assuming you don’t have any performance limitiations.
I’ve been a React Native developer for 8 years, I’ve written many apps with it professionally and personally. Until recently, I would have recommended it wholeheartedly.
This weekend I had an idea I set out to experiment with: if I have an existing React Native app, how much effort would it take an LLM to rewrite it into genuinely native apps. My idea being I no longer need to write cross-platform code and pay the intermediary framework costs, I’d get direct access to the underlying platform. Instead, I could just spec the features I need in the app and the LLM can build it.
It took me a year to build the original app to production quality by hand. My “twins”, as they’ve become known, were at 80% completion in three days of on-off work.
I’m pretty much convinced my experiment was a success. Which sorta terrifies me that I’ve specialised in a technology that can be, for all intents and purposes, be entirely erased.
The only caveat I can find is it is still a great technology for doing cross-platform mobile and web. Using something like Tamagui (as rough as that can be sometimes) allows genuine code sharing across all platforms.
Sucks most that I’m now actively looking for a new React Native role.
Be careful, I’ve been using AI to translate my Swift code to Kotlin and sometimes it makes some mistakes that are invisible to you, because the languages are so similar, but it will bite you in the ass eventually, because there are subtle changes between the platforms
I really believe this is the way forward, native platform UI built by AI.
I'm trying it now with an app and so far it's working really well. I build what I can cross platform, the non-ui stuff, then have AI build the UI for each platform.
It even implemented native low-level graphics on each platform: metal, vulkan, and d3d12. It builds SwiftUI on Apple platforms, WinUI3 on Windows, GTK4 on Linux, Compose on Android. The cross platform stuff is Zig with a C ABI.
And yeah, it's a bit terrifying how fast you can iterate. I've built for all these platforms in about a month. It would have taken at least a year, maybe more before. I haven't even optimized the process by having AI agents follow my lead automatically, so as I finish features on the primary platform they could start building the others by watching. Requires some setup I haven't tackled yet (VMs for all platforms with agents waiting).
Not saying that LLM development isn't fast, but doing a re-implementation of something you know in-and-out is almost always going to be faster, as you skip the probably most time intensive step of product research and requirement engineering.
Absolutely, but that doesn’t discount that it’s now feasible to spec a feature once and have it built for me on both apps. I’m doing the same process on a new project I’m working on and it’s built both apps simultaneously as I’d hoped.
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.
Yes, hopefully now that this decoupling is complete, they'll actually start being updated again. The progress was a bit stalled while this process was ongoing.
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
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.
Of all the myriad projects from Google, how is Flutter/Dart the one that survived the axe? I’m not saying I hate them - I think they’re both really neat - I just don’t understand why Google keeps these limping along with weak support and no clear vision within their broader web ecosystem.
Easy, there are a few google teams that use flutter and the cost savings from not having to have dedicated ios and android teams is very easy to point at to justify the project's existence.
I think Dart and Flutter are very overlooked. The language has completely changed since its release, its statically typed, has null safety, enums, and pattern matching, and is very simple and easy to read. It has fast compilation and a ui framework with hot reload. It's as fast as Js on v8 while using less memory and has the overlooked feature of having very fast, almost 0 overhead, ffi.
I think the importance of good ffi is underrated for these ui languages. For reference, everyone that's using electron has to run two node processes doing ipc over a websocket connection. That's going to waste an absurd number of cpu cycles and memory when you are passing messages around when your app is basically a ui for a cli.
But they also fund JetBrains, Jetpack Compose, and KMP. It feels like the company threw their support behind Kotlin a long while ago on mobile, but internal struggles keep the others limping along. Compose UI tooling no longer requires viewing on device.
You're thinking of Google as a single top down company. It isn't. Think of it as an anarchy of warlords where each pulls the strings and management doesn't really know what's going on.
Flutter made a lot of sense during the Oracle lawsuit when Google needed a way to show Oracle that it can pivot from Java. Now it no longer makes sense but the inertia is too deep.
My guess is that flutter is sold internally through the Huawei support as a leg within China.
How are they limping? Flutter has completely replaced it's rendering engine across all platforms and they're building out major window management support on desktop platforms.
At some point there's just not much exciting new stuff to add. Flutter is a nice stable platform, I'd highly recommend it.
> Flutter has completely replaced it's rendering engine across all platforms
And that new rendering engine is also why apps like Immich are unable to show HDR photos. Apple & Google both pushed broad support for that a couple years ago, with things like Ultra HDR and subsequently ISO 21496-1.
Of course they need to prioritize where to spend resources, like any project, but Flutter also doesn't seem to be on any critical path for fancy headlining new features, either.
I've made a huge critic towards Flutter in another comment of mine, but adoption isn't it: the biggest bank in Brazil, with 135 million clients, is a digital bank whose sole interface is their Flutter app. They are different regarding tech choices (they use Clojure on the backend too), but I think it's a huge testament of how far along Flutter adoption has come.
I really don't understand how/why people deny reality so hard when it comes to Flutter. Reminds me a bit of years ago when people were still scoffing at the idea of anyone actually adopting JavaScript to write web servers with while Node.js was very obviously eating up the market.
It eats the market indeed, and also presents business opportunities for folks like myself, jumping in writing C++ addons, or completely replacing it with Java, .NET, Go, Rust,....
Is that true though? I'm reading HN on an app built using Flutter. I had no idea until recently, so I would assume more apps could use it without my knowledge.
I understand it's limitations vs native apps, but there's quite a few cases where it really doesn't matter.
The biggest one for me is always the fear it will be abandoned. Pretty much goes for any cross platform app framework though.
I used to work at ByteDance and they alone employed I think more than 800 Flutter Devs. Douyin uses Flutter (the Chinese version of TikTok), Grab and Ebay use it, Alibaba and Baidu did too. Toyota and Volkswagen I think both use Flutter. Nubank I think is also a flutter app and they alone have like one hundred million some users.
With the popularity in the Chinese ecosystem alone there's gotta be a billion plus people using flutter.
Most Google's projects that users loved were axed for a reason, typically internal management wars for promotions. Like YouTube really wanted to kill belowed Google Music, so they did. Or Google Pay vs Google Wallet.
Killing Flutter would not promote a manager. For now, of course.
Sure, Adwords migrated from GWT to Dart. (And eventually I followed.) At one point, Dart moved from the Chrome division to the Adwords division. And Adwords alone can fund a team to do developer tools for them. Then, Flutter came a bit later.
It's been over a decade since then, though, and I'm out of touch now.
They still maintaining it's predecessor that the Google "core properties" ran on: Closure (not Clojure), the javascript compiler. It's an evolution of the hack that Gmail initially was built on.
I have user Dart for small personal projects and it's a great language. Somewhat similar to Kotlin, but IMO a bit nicer. Unfortunately the ecosystem is not as developed outside of Flutter as with more popular languages, but it very much exists and pretty nice to use.
I've been using Dart and Flutter for years, but I've never ever met anyone who's seriously using Dart for backend. That would be a very niche thing and not popular with teams.
I always find it strange that flutter isn’t built with golang or typescript. Why use a new language? When flutter came out both languages existed so curious about that.
The main reason i can think of is generics not existing initially
Dart shipped in 2011, four years before Flutter started.
On the technical side, Flutter needed AOT compilation to native ARM for release builds and a JIT for development (that's what makes stateful hot reload possible). Dart does both from one codebase. TypeScript means shipping a JS VM, which is precisely the overhead Flutter was designed to avoid. (In contrast to RN). Dart's other big win is GC tuned for allocating and throwing away tons of short-lived objects which is what happens when you hot reload over and over.
Go has no JIT, so no hot reload, and no generics until 2022, Flutter has a big widget library so that would not have been possible.
And of course the Dart team was inside Google, and had just lost its original mission when Chrome declined to ship the Dart VM, and was willing to change the language to suit Flutter.
I'm not sure why you're being downvoted, it's a super reasonable question.
Iirc the reason is that the Dart team was willing to heavily modify the language and runtime to accommodate the needs of Flutter and the V8 team wasn't.
I use Flet in a few projects. It's still somewhat young and the declarative move caused a few issues (for me, mainly because I wasn't familiar with the pattern), but generally I'd say it's stable, feature-complete and the maintainer seems to be in it for the long haul. Also it fills a critical gap that nothing else does, binding a decent UI framework and cross-platform capability to a language with an extremely large and diverse ecosystem; that's what I think will really make it endure.
Honestly, Flutter is an extremely enjoyable development experience I would recommend anyone I care for to stay away from. The fact it's developed by Google doesn't help: it's a matter of time before they kill it like they did with so many UI libraries and frameworks already, specially with JetBrains developing Compose Multiplatform and the Android team going all-in in the Compose strategy.
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.
* 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 layer between the app and the platform.
* Performance: Flutter can absolutely be fast, so I would not claim otherwise. My experience, however, is that RN has required less work to get interactions and animations that feel consistently native.
* Ecosystem: RN benefits from the broader React, TypeScript, JavaScript, and native ecosystems. Expo has also improved dramatically and now covers a large part of the usual mobile platform work.
* Platform-specific features: neither framework completely eliminates native code. Things like widgets, Live Activities, Dynamic Island, extensions, NFC, and other platform APIs eventually bring you back to Swift/Kotlin anyway.
* Migration to native: if the long-term destination is Swift and Kotlin, I find RN a better intermediate representation. Its component model and platform integration are closer to native concepts, which also makes the codebase easier for agents to translate incrementally into proper native applications.
That said, these are trade-offs, not claims that Flutter is bad. Flutter has improved a lot, and for teams that want a highly consistent cross-platform UI, its rendering model can be an advantage.
- 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.
- Dart is a really _ugly_ language with lots of tiny annoyances. Its as if someone took worst parts of Java and Javascript and turned them into a language. Terrible to write, terrible to read, terrible to use.
- While there is no Skia anymore, the whole custom rendering of Flutter often caused more trouble than not, from the UI implementation itself all the way to specific low-end chipsets not being supported.
- Ecosystem propagates these insane architectures that don't make much sense and are made to either print apps as fast as possible or to emulate some Clean Code like behavior.
- Web still feels terrible to use, even after all these years.
Since I'm not happy with any of these, I've even taken upon writing a framework of my own that renders into native UI and works with any language (gonna shill it here https://hypen.space). It was inspired directly by years of working with mobile and experiencing the pains of crossplatform development such as Flutter and Expo. We can do better than these!
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.
What was your experience on that aspect with Flutter?
I lost so many days of my life profiling and debugging to figure out why hundreds of components were re-rendering when a tiny thing changed somewhere completely unrelated
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).
I get the impression that more are going for native mobile, KMP or PWA.
React Native: totally viable, because core business logic is the same. If you want native UI elements and all the iOS Liquid Glass stuff, but don’t want to have to completely separate code based, React Native is a viable option if you don’t mind installing lots of third party packages for functionality you get out of the box in Flutter or true native apps.
Native mobile: I have one smaller app with quite a custom calendar view, written with Claude Code natively for Android and iOS. Coding agents help and you get maximum control. Mentally, it’s a bit cumbersome to direct you agent to do everything twice. While one platform can serve as a reference implementation for the other, it’s kinda annoying mentally "to do the same feature all over again and test and direct the agent". But it’s doable.
KMP: No experience, I just hate most things around Android.
PWA: That ship has sailed. Nobody knows about PWAs, most PWAs are bad. It’s a bummer really.
Capacitor: make an SPA (offline-first preferably), and use native code plugins via Capacitor. Still quite feasible, comparable to Flutter in the sense that you need to build a custom UI or use a fake version of Liquid Glass and Material. I use Ionic for that, but it’s a bit dated (still on Material v2). Heavily depends on your skills as a web dev to get good UX.
This weekend I had an idea I set out to experiment with: if I have an existing React Native app, how much effort would it take an LLM to rewrite it into genuinely native apps. My idea being I no longer need to write cross-platform code and pay the intermediary framework costs, I’d get direct access to the underlying platform. Instead, I could just spec the features I need in the app and the LLM can build it.
It took me a year to build the original app to production quality by hand. My “twins”, as they’ve become known, were at 80% completion in three days of on-off work.
I’m pretty much convinced my experiment was a success. Which sorta terrifies me that I’ve specialised in a technology that can be, for all intents and purposes, be entirely erased.
The only caveat I can find is it is still a great technology for doing cross-platform mobile and web. Using something like Tamagui (as rough as that can be sometimes) allows genuine code sharing across all platforms.
Sucks most that I’m now actively looking for a new React Native role.
I'm trying it now with an app and so far it's working really well. I build what I can cross platform, the non-ui stuff, then have AI build the UI for each platform.
It even implemented native low-level graphics on each platform: metal, vulkan, and d3d12. It builds SwiftUI on Apple platforms, WinUI3 on Windows, GTK4 on Linux, Compose on Android. The cross platform stuff is Zig with a C ABI.
And yeah, it's a bit terrifying how fast you can iterate. I've built for all these platforms in about a month. It would have taken at least a year, maybe more before. I haven't even optimized the process by having AI agents follow my lead automatically, so as I finish features on the primary platform they could start building the others by watching. Requires some setup I haven't tackled yet (VMs for all platforms with agents waiting).
Relying on WASM means that nobody on Apple platforms who has Lockdown Mode enabled for better security will be able to use it.
its a cross platform framework that you can share component between mobile and other platform and always has been
Now I might vibe code such things using React, but 5 , 6 years ago Flutter got me what I wanted fast.
Firebase integration is absurdly easy. You can make a crud app in about 30 minutes
Still, Flutter now feels ancient to use compared to something like Compose, in that regard.
LOC is dead, long live token usage.
I think Dart and Flutter are very overlooked. The language has completely changed since its release, its statically typed, has null safety, enums, and pattern matching, and is very simple and easy to read. It has fast compilation and a ui framework with hot reload. It's as fast as Js on v8 while using less memory and has the overlooked feature of having very fast, almost 0 overhead, ffi.
I think the importance of good ffi is underrated for these ui languages. For reference, everyone that's using electron has to run two node processes doing ipc over a websocket connection. That's going to waste an absurd number of cpu cycles and memory when you are passing messages around when your app is basically a ui for a cli.
Note that Dart or Flutter are nowhere to be found on Android developer documentation.
Flutter made a lot of sense during the Oracle lawsuit when Google needed a way to show Oracle that it can pivot from Java. Now it no longer makes sense but the inertia is too deep.
My guess is that flutter is sold internally through the Huawei support as a leg within China.
Got any case studies?
At some point there's just not much exciting new stuff to add. Flutter is a nice stable platform, I'd highly recommend it.
And that new rendering engine is also why apps like Immich are unable to show HDR photos. Apple & Google both pushed broad support for that a couple years ago, with things like Ultra HDR and subsequently ISO 21496-1.
Meanwhile Flutter still doesn't really have wide gamut support https://github.com/flutter/flutter/issues/189155
Of course they need to prioritize where to spend resources, like any project, but Flutter also doesn't seem to be on any critical path for fancy headlining new features, either.
Also, Google dogfoods it quite a bit.
https://flutter.dev/showcase/nubank
Archive link: https://archive.is/IIUaj
I really don't understand how/why people deny reality so hard when it comes to Flutter. Reminds me a bit of years ago when people were still scoffing at the idea of anyone actually adopting JavaScript to write web servers with while Node.js was very obviously eating up the market.
I understand it's limitations vs native apps, but there's quite a few cases where it really doesn't matter.
The biggest one for me is always the fear it will be abandoned. Pretty much goes for any cross platform app framework though.
I used to work at ByteDance and they alone employed I think more than 800 Flutter Devs. Douyin uses Flutter (the Chinese version of TikTok), Grab and Ebay use it, Alibaba and Baidu did too. Toyota and Volkswagen I think both use Flutter. Nubank I think is also a flutter app and they alone have like one hundred million some users.
With the popularity in the Chinese ecosystem alone there's gotta be a billion plus people using flutter.
Killing Flutter would not promote a manager. For now, of course.
So they're probably investing in it enough for basic maintenance, but don't really care about evolving the language.
It's been over a decade since then, though, and I'm out of touch now.
https://serverpod.dev/
I personally would like for it to pick up some ideas from Svelte.
The main reason i can think of is generics not existing initially
On the technical side, Flutter needed AOT compilation to native ARM for release builds and a JIT for development (that's what makes stateful hot reload possible). Dart does both from one codebase. TypeScript means shipping a JS VM, which is precisely the overhead Flutter was designed to avoid. (In contrast to RN). Dart's other big win is GC tuned for allocating and throwing away tons of short-lived objects which is what happens when you hot reload over and over.
Go has no JIT, so no hot reload, and no generics until 2022, Flutter has a big widget library so that would not have been possible.
And of course the Dart team was inside Google, and had just lost its original mission when Chrome declined to ship the Dart VM, and was willing to change the language to suit Flutter.
Iirc the reason is that the Dart team was willing to heavily modify the language and runtime to accommodate the needs of Flutter and the V8 team wasn't.
I think this is the video that talks about this: https://m.youtube.com/watch?v=xqGAC5QCYuQ
Flutter can get you up and running quickly. If I want cross-plaform support, one codebase is hard to beat.
lol.