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.
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.
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.
At the time Google went with Kotlin, Flutter was still very new and a much bigger step away from Java given Kotlin already back then was seamlessly integrated with Java and compiled to JVM bytecode.
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.
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.
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'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,....
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.
> 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.
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.
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.
I treat nesting as a feature: if the nesting starts getting deep, that's the code indicating to extract a child widget. It pushes me toward better composition and smaller, reusable components instead of giant monolithic views.
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 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.
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?
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.
We've been hearing that Flutter is going to be killed any day now for almost a decade. And yet here we are, it's a stable platform that's quietly chugging along with massive 3rd party buy in. Honestly, Google could abandon it at this point and it would have enough momentum to keep going just fine. Where is Compose Multiplatform? Does anyone actually use that, is it even stable yet?
Some do use CMP but yes it's quite immature compared to Flutter and they'll spend a lot of time fixing the same bugs with rendering that Flutter fixed a while ago. We'll see how it goes though, if CMP becomes the blessed route for Android cross platform development it'll attract more people and attention.
The fact is, more and more companies are actually picking Flutter. :) Sony praises Flutter on embedded. LG has added extension to allow Flutter apps on its WebOS. Toyota is developing a Flutter game engine, which is already used in some of its cars.
> 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.
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.
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
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.
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.
There were a lot of factors that led to the dart decision. It's also important to note that Flutter is very old, we were designing it in 2014.
- we wanted hot reload
- it was supposed to feel familiar to web developers and reasonable to native developers
- iOS needed AOT compilation for speed since we couldn't use a JIT
- TypeScript had literally just reached 1.0
- Swift looked promising, but the Oracle lawsuit made the idea of using it tenuous
- Kotlin was not even 1.0 yet, that wouldn't happen for 2 more years
- Go made huge binaries. The language was also lacking features like generics and Go was unwilling to add them (remember this is 2014).
- v8 was not interested in AOT, but Dart was willing to dramatically invest in flutter
There were probably other reasons too I'm forgetting.
Dart was a really pragmatic choice to ship quickly. I have mixed feels about how the decision has aged over time, and wish we had things like Hermes and WASM back then, and a willingness to build a TypeScript compiler like other native frameworks (ex. Valdi)... But for the time I think the choice was reasonable.
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 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.
While the server side is still growing and obviously not as huge as Java etc., Dart definitely is being used on the backend. For instance, https://pub.dev/ itself is written in Dart: https://github.com/dart-lang/pub-dev . :)
The language, like any other, does have some weaker parts, but in general is _very_ nice to write in - thanks to both the language itself and the toolchain built around it.
The apps compile to native binaries for production and are run in Dart VM during development. The SDK is multi purpose. You can write "scripts", you can write CLI apps, servers and with Flutter - the rest of them.
For production you may consider using dart VM also since it benefits from AOT and can actually be faster than a binary after it gets hot, similar to Java.
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
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 don't think you'd want to in most cases, but adapting to different platforms takes energy and thought. For business CRUD apps you may just want to ignore that and get something out that works well.
I use Ableton, Figma, and Emacs regularly. I have a decade (or more) of muscle memory around these apps. If they suddenly decided to adopt the look, feel, and conventions of their underlying host platform, I’d be very upset.
If I’m using Emacs, I don’t want to use Cmd+S to save my files on macOS and Ctrl+S on Windows. I’ve already memorized C-x C-s. I don’t want Ableton to adopt whatever new design language Apple or Microsoft is chasing this week. I want to open the app and find the UI controls looking and behaving exactly the same as they’ve looked and behaved since I started using it in 2014. I want to write code, make music, do design. I don’t want to be frustrated because the button for enabling the metronome is 15px to the left on Windows vs. macOS.
Apps that look and feel native only make sense in two cases:
1. The app is tied to the platform. E.g. Logic Pro. It can integrate deeply into macOS and use the native widget set because it will never run on any other platform. Same for Bear, Things, Pixelmator, Omni Group apps, etc.
2. The app is a replaceable, throw-away utility. I call these “fungible apps”. For example, it doesn’t really matter which Mastodon or Bluesky client you use. There are hundreds of them, and they’re not complex enough that the loss of familiarity or muscle memory matters very much. You can use one client on Windows, a different one on macOS, and a third one on Linux, and it’ll be fine. They can all be native to their platforms, or not. The interaction model is simple enough that you can afford to have a different one on every platform.
For apps that really matter—the apps I use to put food on the table—I absolutely want them to look and feel exactly the same on every platform. The app is the OS, the actual OS is just a hardware abstraction layer.
Can Flutter be used to build apps like Figma or Ableton or Emacs? I actually don’t think so. It’s a poor toolkit for building anything that must last for more than 3-5 years. If you care about longevity, there are basically only three options in 2026: Qt, Electron, or roll your own like Zed/Sublime.
(Adding this as a comment because I'm over my edit window.)
I want to add a third category to the categories that make sense as native apps: apps that are built by the platform vendor (and potentially shipped with the platform).
GNOME apps are built with GTK+, KDE apps are built with Qt, and macOS apps are built with SwiftUI/AppKit. This is how it should be. Microsoft is the only outlier here, shipping apps built with everything from Win32 to React Native to Electron to their own WebView2.
Regarding Microsoft - that's a sad story indeed. The only reason they don't use Win32/GDI+ etc is because it's harder and you ideally want to do that in C++ to get the true powers available to you.
I've recently had to do some win32 stuff in a Flutter app and it's amazing what you can do, but it's pretty hard, even with an AI to help you.
So the "lazy" devs go to work using React Native and Electron rather for apps inside of Windows shipped by Microsoft. Crazy, but it's to meet deadlines.
For end user apps, I want them to look according to the OS, at least on Apple devices. That's what picky customers. For stuff where design does not matter much, such as enterprise apps that "put food on the table", as you say, I use Flutter and still get a very decent result.
But with sufficient time and effort, proper native iOS/macOS wins every time.
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.
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.
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.
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).
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 am sure you are right but if you tell the LLM to be careful with those it should easily avoid those mistakes. But yeah first you need to know what to look for.
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.
I've built apps with millions of users using flutter. Quicker, faster and easier for building cross-platform apps if you know what you are doing.
This is coming from a native framework evangelist for many years, and then just tried flutter early days (which was far more difficult than how easy it is today). Now I write almost all my projects in flutter/dart where I can, especially with AI the speed from idea to production is insane.
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.
I have. It's still immature compared to Flutter and doesn't necessarily run native compiled code depending on platform, it can still be tied to the JVM. Not to mention how amazing pub is compared to Gradle.
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).
They still haven't got native scrolling perfect for iOS. I used a big name app just today and I could instantly tell without looking it up that it was a flutter app, because the scrolling felt non-native.
> it's unsolvable since you need to download the whole world (a few MBs) to have the app running on your browser
another reason why the web should move from whole app bundling to content addressed CDNs for library code. you would only need to download one copy for each framework version not every site. and its easy to make it decentralized with IPFS if you want.
To be honest I never tried and never have the need, as usually I either don't care about the font (use default) or I really care for branding purpose so I always bundle it to be sure.
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.
Ah, that's a shame to hear. I would only like to add that at least for Android apps that I've been "hanging around" (my team never really worked on them), the teaching materials that are provided have generally made them a lot more pleasant compared to the RN stuff.
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
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.
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!
I’ve been keeping an eye on hypen.space and hope it succeeds. What is the level of maturity now and are there any multiplatform app examples that are not trivial?
Oh wow, thanks! I never would have thought anyone was keeping an eye on it!
Regarding maturity level - I would yet say it's mature for serious applications with OAuth, local storage etc. Late alpha/early beta stage.
There are some semi-trivial examples on the landing page - most are just UI + input with DB or API fetching in the background, so nothing spectacular.
All of these are crossplatform and render in both web/desktop/mobile and web SDK's or inside the Hypen Gallery apps.
Biggest obstacles to maturity currently are:
- Does not have native platform channels yet
- Renderers need more optimization work
- Ecosystem needs more stability - i.e. test mode and studio still have hiccups
- Error handling and retry story needs improvement
- Some components are still a bit off across desktop/mobile and need syncing
- Resource references derived from state need implementing for better DX
- Protocol isn't binary yet so performance isn't all it could be
But recently things landed that improve maturity quite a lot:
- Accessibility defining & automatic inference has landed, where framework does the best it can to figure it out for you with no intervention
- Animation API has landed with a minimal DX to enable transitions and animations
- Most of tailwind surface is supported and implemented
- Performance improvements being released this week land it in "often 30-50% slower, but sometimes 50% faster than react". Will add benchmarks to docs for visibility.
- CLI improved by a large margin, with expanded template support and easy building
- Cloudflare worker adapter so you can host your app on a worker
There are some similarities, especially in some syntax ideas.
I'd say the core difference from the DX side is that Slint stylistically aligns more with CSS on some areas and allows things such as assignments, Hypen aligns more with Swift UI and separates those things from the UI completely.
Also the integration story is quite different, where Slint is more leaning into a "component integration" model, Hypen leans more into a "just a display layer" model with strict state/UI/action segregation.
> 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 I’m a bit ambivalent towards Flutter, I totally disagree with you on Dart. To me it’s a better version of Java/Typescript with a very mature cross-platform and JIT/AOT compiler. Admittedly there are some things I wish they would take from TS (like discriminated unions), and I haven’t tried “modern” Java either so maybe that’s improved, but even so, I rarely feel like Dart is getting in the way.
They probably just haven't used the latest Dart versions which fixed a lot of the "ugliness" (which I'd call pragmatism but regardless) like primary constructors where a class can just be a single line now.
And I mean, their entire comment is a way to shill their app so I wouldn't take much stock in what they're saying.
Yeah I have no idea how someone who has used all these languages can come up with a conclusion like Dart is “uglier”. I really want to know what exactly they think is ugly about it!
I am biased - but mostly because I have actively used these in my career for quite a while now and encountered pains with both writing new code, upgrading old code and worst, inheriting code or helping debug someone else's code.
When given a choice, I'd rather use bland React Native nowadays than Expo or Flutter - one is a legacy addon to a framework, while the other sounds like a good idea until you step on a nail or have to read some _bad_ code. And there is a whoooole lot of bad flutter code out there due to relaxed language semantics.
Mostly its the core syntax, it's terribly noisy. Also parts of the implementation itself. While I cannot enumerate the taste, I can give you some examples.
For example:
- Class constructors cannot be in definition headers, i.e. class Something(Int a, Int b)
- The whole final and const/static const mess
- required is annoying and really "slapped on"
- shorthand syntax is => instead of =, personal pet peeve
- positional, named and optional parameters segregation makes things noisy
- concurrency, in which an event loop sounds like a great idea but ends up causing pain with multi-threading and background work so you have to spawn diff isolates
- the whole `await fn()` vs `fn()` validity issue, where you can miss the await keyword and it still compiles is such a slap in the face. think now they solved it, but you could also have returns from non-return functions and vice-versa.
- `dynamic` and generics in the same language have caused many bad designs
- extension types also feel hacked on
- type inference is annoying and highly contextual vs out of the box
- Worst sin: DateTime.now() returns different things based on the platform its running on, making it highly unreliable for something so important
I don’t want to sound harsh but that’s the least convincing list of language misfeatures I’ve ever seen. Almost every point is so minor I am surprised you didn’t mention having to type semicolons and similar incredibly inconsequential things.
The internal divisions with this are really amusing. The big driver towards Flutter seems to be needing an iOS app, but Google really underinvests in those (YT being the exception, but it might as well be a different company).
Companies at the size of Google naturally have different business units with different goals. Flutter solves something from some teams with other parts of the company that do not solve for them. That doesn't mean there are some sort of systemic problems. It just means that it operates more like a series of smaller companies in many ways, which is overall healthier for everyone. It's confusing that everyone always expects some sort of unified strategy from the top. That's like suggesting countries should act more like dictatorships rather than democracies.
I mean yes, but also no. Companies the size of Google still have an overall strategy, and when one group’s strategy is to shit all over another part of the company, that usually doesn’t work out. Even worse, the scale Flutter is developed at is simply completely different than Android and Chrome. Flutter is really a symptom of just how strange Google is, as kind of a weird, anarcho-engineering collective where you can do anything as long as you can get a VP to support it.
I love working with Dart (which IMO is _not_ "worst parts of Java and Javascript (...) turned (...) into a language", "Terrible to write, terrible to read, terrible to use" - quite the opposite, actually) and its toolchain, including Flutter.
I find the architecture simple to follow, no need for "either print apps as fast as possible or to emulate some Clean Code like behavior", though I do think some people use overcomplicated state management solutions. But nobody forces anybody to do that.
My experience with Web has been fine so far and I've seen fully cross platform Flutter apps working absolutely fine on mobile, desktop and web.
This is not to gaslight your experience, YMMV after all.
And React Native, with its dependency hell, project rot, npm ecosystem under the hood, and transpilation with lax runtime leaking into TS, is a total no-go for me. Though I base this opinion partially on my experience with NodeJS, and partially on that of my friends who use RN.
Btw. Does your platform support bundling UI in addition to streaming it from the server? How large is the bundled runtime?
>I find the architecture simple to follow, no need for "either print apps as fast as possible or to emulate some Clean Code like behavior", though I do think some people use overcomplicated state management solutions. But nobody forces anybody to do that.
Unfortunately sometimes you have to, and on average, that code is much worse than your average React Native spaghetti. Whole generations of Flutter devs got these patterns ingrained, and often times they make not just writing and reading code, but communication itself harder.
>And React Native, with its dependency hell, project rot, npm ecosystem under the hood, and transpilation with lax runtime leaking into TS, is a total no-go for me.
That was my stance too until the new architecture released - since then the framework has improved a whole lot, together with its build chain, and is the best way to do crossplatform nowadays.
>Btw. Does your platform support bundling UI in addition to streaming it from the server? How large is the bundled runtime?
Not yet unless you DIY it - currently you can bundle UI and runtime by integrating the Rust engine + renderer with your app, or TS + renderer itself.
There is work being done in a private mirror currently on bundling the whole app + runtime as WASM, exposing WASI interfaces to native such as storage, network, permissions etc, depending on how testing goes it should land in a month or two on the public branch.
> Although, I do not prefer Expo due to it's highly annoying build system and dependency hell
Highly agree with this. I'm almost done moving an app off it into React (web, not native) because the SDK upgrades kept including unlisted breaking changes to the point I can't upgrade anymore. Biggest culprit was Reanimated.
I migrated one recently into fully native Swift UI and Compose from Expo - modern models can do it over night, and you save yourself from the dependency hell that is expo.
I created something similar to Hyphen at my previous job and while it was a big shift in mentality, implementing UI in the backend and having the apps consume that and render it with native components os really underrated.
The biggest negative with Flutter is web. Because most of the UI is canvas-rendered, DOM based tooling like session replay, analytics, accessibility audits, and browser automation require specific instrumentation. That reduces third party choices you have unless you invest in your own tooling and who has time for that. I can't imagine the situation is much better in mobile.
Like I said I dont have much mobile experience to make a claim. Native apps have their own view and accesibility hierarchy. But even there, React Native would be a better choice because its components become native platform views which would directly be located by 3rd party apps like Appium etc compared to flutter.
Does anyone know if the original promise of their simple layout model proved itself?
IIRC, the Flutter team mentioned how using just width/height constraints is enough to represent all relevant layouts. This sounds very nice, being so much simpler than Flexbox and miles ahead of CSS Grid ergonomics.
Did it live up to the promise or did they expand the model with Flex/Grid/etc?
The premise is a bit off. Flutter was never just width/height: the model is min/max box constraints. The core rule is: constraints go down, sizes come up, parent sets position.
Row and Column are just layout algorithms built on that same model, not separate engines added later. GridView uses the sliver system internally, but still doesn't require anything like CSS Grid's general layout model. The render API is open enough for custom layouts too, so packages like https://pub.dev/packages/boxy build directly on it
I just moved out last month, it's just pain after sometime now, it's okay and good for mobile cross, when it comes to desktop, I'd have to struggle to support linux with quick hangs
To an untrained eye who does not care about dropping a few frames, the web version is almost indistinguishable from the "native" build. Especially if you add it to homescreen from safari to hide the navigation bar.
I vouch for Flutter over React Native; we built https://macrocodex.app/ with 16,000+ users already!
And it's completely free no ads, no subscriptions, or donations, for the public benefit of improving health and fitness.
It's a guaranteed weight loss or gain app; results within 2-5 weeks! Don't believe? well just read reviews. We do not have Revenue, so no money to spend on marketing.
OK so that's brief description of what we built now flutter part:
The Flutter development experience is very smooth; you rarely run into any issues, just be careful not to block the UI isolate. Sometimes bad structuring issues or ui bugs may end up blocking your UI.
My experience is in Backend (java, rust, c++, go, ruby, python etc..) and this is the first time i built a mobile app. And same is true for other guys on the team.
Some limitations are from the underlying platform and not Flutter. Initially, I thought the lack of OTA was a dealbreaker (as App Store / Play Store approvals are a slow loop) and Expo might be better, but the lack of OTA made me structure the app differently and it turned out it's not as big of a deal actually.
We also managed to have a PWA app (for nearly free) by using Flutter web, so it also runs on devices which do not support the Play Store or App Store, giving us max coverage across the board.
We tested react native but found it slow (your code runs in Hermes VM so you need to write native code to offload) and dev tools aren't as good as flutters imho.
Dart AOT, which is what runs on iOS/Android, is much faster by default, so you'll hardly ever feel any need to write native code. And when you do need to write native code, we use some for WorkManager and HealthConnect it's very easy! Just be careful with R8; you might have to set rules (though most plugins ship with rules these days) but if you are writing native code in java/kotlin you may have to do this on your own, or it can sometimes break things!
I am glad I picked Flutter over React Native! I had my doubts, but I am glad I looked at their "architecture" rather than the hype of the subreddits.
Flutter is 9 years old at this point. I do hope they move it its own open source foundation since a ton of apps use it, having all that under Google's control isn't the best (looking at you too Android)
Yeah now it might be ok but when it came out I didn’t want to bet on it.
Around the same time at my job tried to build a design system off Google’s web component MD implementation and that shit stalled and then got fully abandoned.
Oh totally agreed, I went through the same thought process 8 years ago at my last job and decided against Flutter too. I really wanted to, it was just too new as a Google product. I'm happy I get to use it now, it's solid.
As someone coming from MacroFactor, estimating macros on food is the hardest part of dieting. So your app is great but it tackles the part of dieting that people aren't stuggling with and doesn't address the part that they do struggle with.
Most dieting apps are pushing for the AI photo and barcode scanning to make estimating easier and though far from perfect, it makes the whole experience at least somewhat doable.
We've had many people who have unsubscribed from MacroFactor after using our MacroCodex.
Not just this, we've also built MacroFactor Workout's rival Symbiote Workout app which is also completely free! it's now in Beta and under rapid developement.
For calorie tracking, you've established apps like Cronometer and MyFitnessPal or they can use our completely free AI calorie tracker CalorieCodex! which does what you want! barcode scan / photo to calorie and macro output etc...
>estimating macros on food is the hardest part of dieting. So your app is great but it tackles the part of dieting that people aren't stuggling with and doesn't address the part that they do struggle with.
I believe MacroCodex actually targets the part most people are likely to struggle with and this is why it is able to provide guaranteed results!
This app is not a calorie tracker, though it can pull calorie totals and weight from other apps using Health Connect on Android.
>Most dieting apps are pushing for the AI photo and barcode scanning to make estimating easier and though far from perfect, it makes the whole experience at least somewhat doable.
We also have an AI calorie tracker; it's CalorieCodex. It's in BETA and can do Barcode/Photo using BYOK AI.
I'll second this. I avoided React Native because I absolutely loathe using React in general (much prefer Vue/Nuxt or Svelte/SvelteKit). Flutter has been an absolute pleasure to build the mobile version of https://miserablyunemployed.com with. It's all really straightforward and I haven't experienced any real gotchas yet.
Very happy that it's still maintain, because that's the only real framework that allow an easy dev for a decently fast app with one code base that works on linux, windows, mac, ios and android at once.
flutter should 100% drop web target. if you disagree you never used flutter for real, or are lying to yourself while employed by google to work on flutter
jimbob45 | 17 hours ago
monocasa | 16 hours ago
So they're probably investing in it enough for basic maintenance, but don't really care about evolving the language.
skybrian | 14 hours ago
It's been over a decade since then, though, and I'm out of touch now.
pjmlp | 12 hours ago
spwa4 | 8 hours ago
vmg12 | 16 hours ago
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.
cageface | 16 hours ago
wiseowise | 13 hours ago
Got any case studies?
cageface | 10 hours ago
mathverse | 9 hours ago
formvoltron | 16 hours ago
vmg12 | 16 hours ago
Larrikin | 16 hours ago
invalidname | 15 hours ago
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.
wiseowise | 13 hours ago
pjmlp | 12 hours ago
Note that Dart or Flutter are nowhere to be found on Android developer documentation.
brabel | 5 hours ago
veeti | 10 hours ago
gman83 | 16 hours ago
deepsun | 16 hours ago
Killing Flutter would not promote a manager. For now, of course.
[OP] gumby271 | 16 hours ago
At some point there's just not much exciting new stuff to add. Flutter is a nice stable platform, I'd highly recommend it.
matchbok3 | 16 hours ago
gkhartman | 16 hours ago
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.
monocasa | 16 hours ago
vips7L | 16 hours ago
owebmaster | 14 hours ago
vips7L | 13 hours ago
satvikpendem | 5 hours ago
doodlesdev | 15 hours ago
Also, Google dogfoods it quite a bit.
Cyph0n | 15 hours ago
wiseowise | 13 hours ago
https://flutter.dev/showcase/nubank
owebmaster | 14 hours ago
filleduchaos | 12 hours ago
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.
pjmlp | 12 hours ago
Barrin92 | 14 hours ago
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.
davidkuennen | 14 hours ago
liquid153 | 12 hours ago
Gonna check out the app
kllrnohj | 16 hours ago
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.
Scene_Cast2 | 16 hours ago
jauntywundrkind | 11 hours ago
Aldo_MX | 16 hours ago
gman83 | 16 hours ago
kumarvvr | 16 hours ago
eddythompson80 | 16 hours ago
superze | 16 hours ago
cocoa19 | 14 hours ago
LOC is dead, long live token usage.
skeledrew | 15 hours ago
MrDresden | 8 hours ago
Still, Flutter now feels ancient to use compared to something like Compose, in that regard.
gman83 | 7 hours ago
Scene_Cast2 | 16 hours ago
I personally would like for it to pick up some ideas from Svelte.
Humphrey | 15 hours ago
synergy20 | 15 hours ago
tonyhart7 | 14 hours ago
its a cross platform framework that you can share component between mobile and other platform and always has been
999900000999 | 14 hours ago
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
tonyhart7 | 9 hours ago
999900000999 | 2 hours ago
It's the fastest way to build something if you're not a big html person.
I've never particularly been good at hmtl tbh. The older I get, the more I'm concerned with the ease of tools/frameworks vs what's the most optimal.
tonyhart7 | 2 hours ago
eklavya | 14 hours ago
JimDabell | 9 hours ago
Relying on WASM means that nobody on Apple platforms who has Lockdown Mode enabled for better security will be able to use it.
sevenzero | 8 hours ago
doodlesdev | 15 hours ago
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.
skybrian | 15 hours ago
ls-a | 14 hours ago
palata | 9 hours ago
satvikpendem | 6 hours ago
maxloh | 14 hours ago
WA | 10 hours ago
gman83 | 10 hours ago
satvikpendem | 6 hours ago
0rzech | 5 hours ago
nmfisher | 9 hours ago
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.
skeledrew | 15 hours ago
theanonymousone | 15 hours ago
skeledrew | 14 hours ago
theanonymousone | 8 hours ago
skeledrew | an hour ago
https://flet.dev/blog/flet-v-0-86-release-announcement
amazingamazing | 15 hours ago
The main reason i can think of is generics not existing initially
bbkane | 14 hours ago
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
billynomates | 9 hours ago
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.
esprehn | 5 hours ago
- we wanted hot reload
- it was supposed to feel familiar to web developers and reasonable to native developers
- iOS needed AOT compilation for speed since we couldn't use a JIT
- TypeScript had literally just reached 1.0
- Swift looked promising, but the Oracle lawsuit made the idea of using it tenuous
- Kotlin was not even 1.0 yet, that wouldn't happen for 2 more years
- Go made huge binaries. The language was also lacking features like generics and Go was unwilling to add them (remember this is 2014).
- v8 was not interested in AOT, but Dart was willing to dramatically invest in flutter
There were probably other reasons too I'm forgetting.
Dart was a really pragmatic choice to ship quickly. I have mixed feels about how the decision has aged over time, and wish we had things like Hermes and WASM back then, and a willingness to build a TypeScript compiler like other native frameworks (ex. Valdi)... But for the time I think the choice was reasonable.
sunsetSamurai | 14 hours ago
wstrange | 14 hours ago
https://serverpod.dev/
sgt | 9 hours ago
flexagoon | 9 hours ago
0rzech | 7 hours ago
The language, like any other, does have some weaker parts, but in general is _very_ nice to write in - thanks to both the language itself and the toolchain built around it.
The apps compile to native binaries for production and are run in Dart VM during development. The SDK is multi purpose. You can write "scripts", you can write CLI apps, servers and with Flutter - the rest of them.
brabel | 5 hours ago
0rzech | 5 hours ago
mraleph | 3 hours ago
JIT mode is only for development, and its performance has not been a priority for a while now.
wiseowise | 13 hours ago
lol.
hirvi74 | 13 hours ago
Flutter can get you up and running quickly. If I want cross-plaform support, one codebase is hard to beat.
feverzsj | 12 hours ago
thelollies | 8 hours ago
britannio | 7 hours ago
TheChaplain | 10 hours ago
I get the impression that more are going for native mobile, KMP or PWA.
keyle | 10 hours ago
WA | 10 hours ago
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.
sgt | 9 hours ago
victorbjorklund | 9 hours ago
tcfhgj | 7 hours ago
sgt | 6 hours ago
GeneralMaximus | 6 hours ago
I use Ableton, Figma, and Emacs regularly. I have a decade (or more) of muscle memory around these apps. If they suddenly decided to adopt the look, feel, and conventions of their underlying host platform, I’d be very upset.
If I’m using Emacs, I don’t want to use Cmd+S to save my files on macOS and Ctrl+S on Windows. I’ve already memorized C-x C-s. I don’t want Ableton to adopt whatever new design language Apple or Microsoft is chasing this week. I want to open the app and find the UI controls looking and behaving exactly the same as they’ve looked and behaved since I started using it in 2014. I want to write code, make music, do design. I don’t want to be frustrated because the button for enabling the metronome is 15px to the left on Windows vs. macOS.
Apps that look and feel native only make sense in two cases:
1. The app is tied to the platform. E.g. Logic Pro. It can integrate deeply into macOS and use the native widget set because it will never run on any other platform. Same for Bear, Things, Pixelmator, Omni Group apps, etc.
2. The app is a replaceable, throw-away utility. I call these “fungible apps”. For example, it doesn’t really matter which Mastodon or Bluesky client you use. There are hundreds of them, and they’re not complex enough that the loss of familiarity or muscle memory matters very much. You can use one client on Windows, a different one on macOS, and a third one on Linux, and it’ll be fine. They can all be native to their platforms, or not. The interaction model is simple enough that you can afford to have a different one on every platform.
For apps that really matter—the apps I use to put food on the table—I absolutely want them to look and feel exactly the same on every platform. The app is the OS, the actual OS is just a hardware abstraction layer.
Can Flutter be used to build apps like Figma or Ableton or Emacs? I actually don’t think so. It’s a poor toolkit for building anything that must last for more than 3-5 years. If you care about longevity, there are basically only three options in 2026: Qt, Electron, or roll your own like Zed/Sublime.
GeneralMaximus | 3 hours ago
I want to add a third category to the categories that make sense as native apps: apps that are built by the platform vendor (and potentially shipped with the platform).
GNOME apps are built with GTK+, KDE apps are built with Qt, and macOS apps are built with SwiftUI/AppKit. This is how it should be. Microsoft is the only outlier here, shipping apps built with everything from Win32 to React Native to Electron to their own WebView2.
sgt | 48 minutes ago
I've recently had to do some win32 stuff in a Flutter app and it's amazing what you can do, but it's pretty hard, even with an AI to help you.
So the "lazy" devs go to work using React Native and Electron rather for apps inside of Windows shipped by Microsoft. Crazy, but it's to meet deadlines.
sgt | 2 hours ago
But with sufficient time and effort, proper native iOS/macOS wins every time.
gman83 | 7 hours ago
pjmlp | 6 hours ago
wwdrew | 9 hours ago
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.
foresterre | 9 hours ago
wwdrew | 9 hours ago
jcollins | 8 hours ago
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).
puelocesar | 8 hours ago
jcollins | 7 hours ago
One downside for sure is lack of deep knowledge on all these platforms can make it difficult to see issues.
brabel | 5 hours ago
rapsey | 8 hours ago
mad_tortoise | 7 hours ago
This is coming from a native framework evangelist for many years, and then just tried flutter early days (which was far more difficult than how easy it is today). Now I write almost all my projects in flutter/dart where I can, especially with AI the speed from idea to production is insane.
meerita | 9 hours ago
* 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.
palata | 9 hours ago
satvikpendem | 5 hours ago
wiradikusuma | 9 hours ago
- 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.
phist_mcgee | 7 hours ago
zigzag312 | 6 hours ago
satvikpendem | 6 hours ago
tancop | 6 hours ago
another reason why the web should move from whole app bundling to content addressed CDNs for library code. you would only need to download one copy for each framework version not every site. and its easy to make it decentralized with IPFS if you want.
d_watt | 5 hours ago
skybrian | 3 hours ago
https://github.com/WICG/cross-origin-storage
microflash | 3 hours ago
wiradikusuma | an hour ago
Degorath | 9 hours ago
What was your experience on that aspect with Flutter?
meerita | 8 hours ago
Degorath | 7 hours ago
puelocesar | 8 hours ago
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
tcfhgj | 7 hours ago
Could you explain how this comes from React Native and/or redux?
I have used Angular with redux (ngrx) and redux made it quite obvious what changed what and why
user43928 | 6 hours ago
You create a selector. You use the selector in a React component.
The component re-renders when the selector outputs a different value, with the usual reference equality caveat.
Does it get any simpler than that?
However, yes, I have seen most developers use Redux incompetently.
They would use actions like "setOrder" instead of "itemAdded", defeating the purpose of a state machine from the start.
satvikpendem | 6 hours ago
user43928 | 5 hours ago
satvikpendem | an hour ago
sevenzero | 9 hours ago
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).
meerita | 8 hours ago
sevenzero | 8 hours ago
thelollies | 8 hours ago
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.
hypendev | 8 hours ago
- 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!
lifty | 6 hours ago
hypendev | 2 hours ago
Regarding maturity level - I would yet say it's mature for serious applications with OAuth, local storage etc. Late alpha/early beta stage.
There are some semi-trivial examples on the landing page - most are just UI + input with DB or API fetching in the background, so nothing spectacular.
All of these are crossplatform and render in both web/desktop/mobile and web SDK's or inside the Hypen Gallery apps.
Biggest obstacles to maturity currently are:
- Does not have native platform channels yet
- Renderers need more optimization work
- Ecosystem needs more stability - i.e. test mode and studio still have hiccups
- Error handling and retry story needs improvement
- Some components are still a bit off across desktop/mobile and need syncing
- Resource references derived from state need implementing for better DX
- Protocol isn't binary yet so performance isn't all it could be
But recently things landed that improve maturity quite a lot:
- Accessibility defining & automatic inference has landed, where framework does the best it can to figure it out for you with no intervention
- Animation API has landed with a minimal DX to enable transitions and animations
- Most of tailwind surface is supported and implemented
- Performance improvements being released this week land it in "often 30-50% slower, but sometimes 50% faster than react". Will add benchmarks to docs for visibility.
- CLI improved by a large margin, with expanded template support and easy building
- Cloudflare worker adapter so you can host your app on a worker
lifty | 2 hours ago
AbuAssar | 6 hours ago
hypendev | 2 hours ago
Also the integration story is quite different, where Slint is more leaning into a "component integration" model, Hypen leans more into a "just a display layer" model with strict state/UI/action segregation.
nmfisher | 6 hours ago
While I’m a bit ambivalent towards Flutter, I totally disagree with you on Dart. To me it’s a better version of Java/Typescript with a very mature cross-platform and JIT/AOT compiler. Admittedly there are some things I wish they would take from TS (like discriminated unions), and I haven’t tried “modern” Java either so maybe that’s improved, but even so, I rarely feel like Dart is getting in the way.
satvikpendem | 6 hours ago
And I mean, their entire comment is a way to shill their app so I wouldn't take much stock in what they're saying.
brabel | 5 hours ago
anthropodie | 5 hours ago
hypendev | 2 hours ago
When given a choice, I'd rather use bland React Native nowadays than Expo or Flutter - one is a legacy addon to a framework, while the other sounds like a good idea until you step on a nail or have to read some _bad_ code. And there is a whoooole lot of bad flutter code out there due to relaxed language semantics.
hypendev | 3 hours ago
For example:
- Class constructors cannot be in definition headers, i.e. class Something(Int a, Int b)
- The whole final and const/static const mess
- required is annoying and really "slapped on"
- shorthand syntax is => instead of =, personal pet peeve
- positional, named and optional parameters segregation makes things noisy
- concurrency, in which an event loop sounds like a great idea but ends up causing pain with multi-threading and background work so you have to spawn diff isolates
- the whole `await fn()` vs `fn()` validity issue, where you can miss the await keyword and it still compiles is such a slap in the face. think now they solved it, but you could also have returns from non-return functions and vice-versa.
- `dynamic` and generics in the same language have caused many bad designs
- extension types also feel hacked on
- type inference is annoying and highly contextual vs out of the box
- Worst sin: DateTime.now() returns different things based on the platform its running on, making it highly unreliable for something so important
brabel | an hour ago
hypendev | an hour ago
It's a matter of taste, and Dart's syntax style doesn't match mine. As much as I tried to enjoy it, after a while I just couldn't look at it anymore.
All of these accumulate and make it feel overly noisy for a lazy brain.
pjmlp | 6 hours ago
sulam | 5 hours ago
pjmlp | 4 hours ago
https://www.youtube.com/watch?v=VX6nAvRWQg4&t=3418s
surajrmal | 3 hours ago
sulam | an hour ago
spixy | 5 minutes ago
0rzech | 5 hours ago
I love working with Dart (which IMO is _not_ "worst parts of Java and Javascript (...) turned (...) into a language", "Terrible to write, terrible to read, terrible to use" - quite the opposite, actually) and its toolchain, including Flutter.
I find the architecture simple to follow, no need for "either print apps as fast as possible or to emulate some Clean Code like behavior", though I do think some people use overcomplicated state management solutions. But nobody forces anybody to do that.
My experience with Web has been fine so far and I've seen fully cross platform Flutter apps working absolutely fine on mobile, desktop and web.
This is not to gaslight your experience, YMMV after all.
And React Native, with its dependency hell, project rot, npm ecosystem under the hood, and transpilation with lax runtime leaking into TS, is a total no-go for me. Though I base this opinion partially on my experience with NodeJS, and partially on that of my friends who use RN.
Btw. Does your platform support bundling UI in addition to streaming it from the server? How large is the bundled runtime?
PS. Clicking on "see all supported platforms →" on your project's homepage gives 404 for https://docs.hypen.space/docs/adapters .
hypendev | 2 hours ago
Unfortunately sometimes you have to, and on average, that code is much worse than your average React Native spaghetti. Whole generations of Flutter devs got these patterns ingrained, and often times they make not just writing and reading code, but communication itself harder.
>And React Native, with its dependency hell, project rot, npm ecosystem under the hood, and transpilation with lax runtime leaking into TS, is a total no-go for me.
That was my stance too until the new architecture released - since then the framework has improved a whole lot, together with its build chain, and is the best way to do crossplatform nowadays.
>Btw. Does your platform support bundling UI in addition to streaming it from the server? How large is the bundled runtime?
Not yet unless you DIY it - currently you can bundle UI and runtime by integrating the Rust engine + renderer with your app, or TS + renderer itself.
There is work being done in a private mirror currently on bundling the whole app + runtime as WASM, exposing WASI interfaces to native such as storage, network, permissions etc, depending on how testing goes it should land in a month or two on the public branch.
>PS. Clicking on "see all supported platforms →" on your project's homepage gives 404 for https://docs.hypen.space/docs/adapters
Thanks, fixing that ASAP!
Rohansi | 4 hours ago
Highly agree with this. I'm almost done moving an app off it into React (web, not native) because the SDK upgrades kept including unlisted breaking changes to the point I can't upgrade anymore. Biggest culprit was Reanimated.
hypendev | 2 hours ago
videogreg93 | 49 minutes ago
kaycey2022 | 2 hours ago
faangguyindia | 2 hours ago
kaycey2022 | 5 minutes ago
oDot | 7 hours ago
IIRC, the Flutter team mentioned how using just width/height constraints is enough to represent all relevant layouts. This sounds very nice, being so much simpler than Flexbox and miles ahead of CSS Grid ergonomics.
Did it live up to the promise or did they expand the model with Flex/Grid/etc?
gman83 | 7 hours ago
Row and Column are just layout algorithms built on that same model, not separate engines added later. GridView uses the sliver system internally, but still doesn't require anything like CSS Grid's general layout model. The render API is open enough for custom layouts too, so packages like https://pub.dev/packages/boxy build directly on it
phoghed | 5 hours ago
We got tables and floats instead.
faangguyindia | 5 hours ago
eviks | 7 hours ago
How does such a basic feature only get added so late?
AbuAssar | 7 hours ago
eviks | 7 hours ago
AbuAssar | 7 hours ago
ouz-a | 6 hours ago
brabel | 5 hours ago
junaid1460 | 6 hours ago
kebsup | 6 hours ago
The web app is here: https://app.vocabuo.com (completely free) And the links for Android/iOS builds are here: https://vocabuo.com (soft paywall)
To an untrained eye who does not care about dropping a few frames, the web version is almost indistinguishable from the "native" build. Especially if you add it to homescreen from safari to hide the navigation bar.
merrvk | 5 hours ago
hactually | 4 hours ago
faangguyindia | 5 hours ago
And it's completely free no ads, no subscriptions, or donations, for the public benefit of improving health and fitness.
It's a guaranteed weight loss or gain app; results within 2-5 weeks! Don't believe? well just read reviews. We do not have Revenue, so no money to spend on marketing.
OK so that's brief description of what we built now flutter part:
The Flutter development experience is very smooth; you rarely run into any issues, just be careful not to block the UI isolate. Sometimes bad structuring issues or ui bugs may end up blocking your UI.
My experience is in Backend (java, rust, c++, go, ruby, python etc..) and this is the first time i built a mobile app. And same is true for other guys on the team.
Some limitations are from the underlying platform and not Flutter. Initially, I thought the lack of OTA was a dealbreaker (as App Store / Play Store approvals are a slow loop) and Expo might be better, but the lack of OTA made me structure the app differently and it turned out it's not as big of a deal actually.
We also managed to have a PWA app (for nearly free) by using Flutter web, so it also runs on devices which do not support the Play Store or App Store, giving us max coverage across the board.
We tested react native but found it slow (your code runs in Hermes VM so you need to write native code to offload) and dev tools aren't as good as flutters imho. Dart AOT, which is what runs on iOS/Android, is much faster by default, so you'll hardly ever feel any need to write native code. And when you do need to write native code, we use some for WorkManager and HealthConnect it's very easy! Just be careful with R8; you might have to set rules (though most plugins ship with rules these days) but if you are writing native code in java/kotlin you may have to do this on your own, or it can sometimes break things!
I am glad I picked Flutter over React Native! I had my doubts, but I am glad I looked at their "architecture" rather than the hype of the subreddits.
phoghed | 4 hours ago
faangguyindia | 4 hours ago
[OP] gumby271 | 3 hours ago
phoghed | 2 hours ago
Around the same time at my job tried to build a design system off Google’s web component MD implementation and that shit stalled and then got fully abandoned.
[OP] gumby271 | 27 minutes ago
alternatex | 4 hours ago
Most dieting apps are pushing for the AI photo and barcode scanning to make estimating easier and though far from perfect, it makes the whole experience at least somewhat doable.
faangguyindia | 4 hours ago
We've had many people who have unsubscribed from MacroFactor after using our MacroCodex.
Not just this, we've also built MacroFactor Workout's rival Symbiote Workout app which is also completely free! it's now in Beta and under rapid developement.
For calorie tracking, you've established apps like Cronometer and MyFitnessPal or they can use our completely free AI calorie tracker CalorieCodex! which does what you want! barcode scan / photo to calorie and macro output etc...
>estimating macros on food is the hardest part of dieting. So your app is great but it tackles the part of dieting that people aren't stuggling with and doesn't address the part that they do struggle with.
I believe MacroCodex actually targets the part most people are likely to struggle with and this is why it is able to provide guaranteed results!
This app is not a calorie tracker, though it can pull calorie totals and weight from other apps using Health Connect on Android.
To understand the problem we are solving, you'll need to read this: https://macrocodex.app/knowledge/rethink/adaptive-tdee/
We've had to design this algorithm to figure out real maintenance calories:
https://macrocodex.app/knowledge/macrocodex/smart-calorie-bu...
>Most dieting apps are pushing for the AI photo and barcode scanning to make estimating easier and though far from perfect, it makes the whole experience at least somewhat doable.
We also have an AI calorie tracker; it's CalorieCodex. It's in BETA and can do Barcode/Photo using BYOK AI.
tuesdaynight | 3 hours ago
faangguyindia | 2 hours ago
ramijames | 4 hours ago
BiteCode_dev | 4 hours ago
It's super nice.
iririririr | an hour ago