If you doubt my results, talk to your non-technical friends and show them apps that are native vs those that aren't and hear what they say.
If you doubt my results, talk to your non-technical friends and show them apps that are native vs those that aren't and hear what they say.
I have turned pessimistic on Flutter after they failed to fix this catastrophic issue for years, and I'm not someone who is ideologically opposed to cross-platform UI technologies in general.
Imitating native user interfaces takes a huge and continued effort. It's always a step behind and in danger of falling further behind. How long until it gets defunded?
Yes, but this is a completely different topic.
Also, battery usage isn't a native vs portable UI toolkit thing, it's an issue when using Flutter but can also be an issue when using SwiftUI.
Flutter would have been better off with an entirely separate UI convention and stop trying to pretend to be like native apps. I’d still hate it because it really adds nothing to the story that wasn’t in Java+Swing two decades ago, but at least they could start paying attention to how poorly Flutter apps work in their intended contexts instead of trying to keep up with the Joneses.
Not true. The sub thread was about whether or not users can tell the difference between native and cross platform apps, specifically Flutter, and whether they care.
satvikpendem wrote this:
"Good for you, but most people can't tell nor do they care, given that I've shipped Flutter apps across thousands of users, both consumer and enterprise, whom we collect feedback from. Not once did anyone complain about the app visuals or performance itself"
The context is everything and anything that users could notice and provide feedback on, not just visuals.
Also, I think you may have missed the link in my argument between battery usage and the attempt to imitate native visuals.
The original messages in the sub-thread [1] and the message you were responding to[2] were about UI/UX. Had you responded to the even higher level comment you are referring to[3], then you'd have been on-topic…
The same way, if you started to criticize Crux (the topic of the OP) at this point of the thread, you message would be completely off-topic as well.
[1]: https://news.ycombinator.com/item?id=37699475
The parent comment claimed that users don't notice the difference between native and cross-platform. I responded saying that even if they didn't notice the visual difference, they will surely notice the battery drain directly caused by the attempt to achieve accurate visual parity.
This is not off-topic by any reasonable standard. This is merely addressing a closely related and very relevant aspect of the same topic.
After almost four years of saddling every Flutter app that uses text input with anywhere between 5% and 20% CPU usage, this is what they have come up with.
What this tells me is that it is neither possible nor beneficial to imitate native UI toolkits using a completely different technology stack. It's simply the wrong architecture.
I don't understand your position. You're saying (correctly I think) that most users don't care about native. But then you turn around and choose an immature technology that spends a significant share of its budget on trying and failing to imitate native.
The bug I cited betrays the priorities of the project. They chose to prioritise chasing "native" over fixing a critical bug for many years.
Also, look at the large amount of investment going into web technologies - WebAssembly, WebGPU and many others. Even much criticised Apple is putting in a lot of work. I don't think the completely isolated Flutter/Dart team will ever be able to compete.
Flutter binaries and runtime are orders of magnitude smaller and faster than web technologies. True, they shouldn't be chasing native, but it's still better than what we have currently with trying to cover 6 OS with web technologies.
The compiled code from Dart is faster than V8, even simply by virtue of being AOT compiled instead of JITed, not sure where you saw that it wasn't any faster. Also, web technologies do not run compiled code on every platform, they don't run compiled code on any platform, I'm also unsure of where you're making that claim from, unless you're talking about WASM which is still a ways away, and something that Flutter leverages too already (see their work on pushing WASM GC as well as their experimental build of Flutter Web with WASM GC), so it's not unique to web technologies like HTML, CSS, and Javascript.
At the moment it's a different tech stack for packaging mobile vs desktop app, but I'm waiting for Tauri to implement support for mobile to migrate everything to Tauri (I'm using a go webview library for desktop and capacitor for mobile).
Note: I know devs are usually allergic to multiple techs far various targets, but it was pretty much a one-off time cost, 99% of the dev time is spent working on the webapp itself.
I have come to the exact opposite conclusion starting out with an open mind just like you. Flutter seems like a quixotic effort to me. Bugs like the one I linked to are a confirmation of that.
>Also, web technologies do not run compiled code on every platform, they don't run compiled code on any platform, I'm also unsure of where you're making that claim from.
JIT compiles to native code. WebAssembly is another option.
>not sure where you saw that it wasn't any faster
https://programming-language-benchmarks.vercel.app/dart-vs-j...
Thanks for the benchmarks, seems they're about even.
I mean, it really depends on the specifics of your app. For most apps it wouldn't hurt one bit if they were just good mobile websites or PWAs (possibly packaged for app store distribution).
For computation heavy code WASM is becoming a viable complement to JavaScript. WebGPU is on the way. And Figma has just sold iself to Adobe for $20bn after annihilating native competitors (I realise I'm painting in very broad strokes here).
I think there is a niche for mostly client side, offline-first apps that still have no need for deep integration with the native platform and are not games. But it's a small niche getting smaller.
The technogies living in this space will forever be changing, falling out of favour only to be replaced by the next attempt. It's been going on like this forever (Java Applets, Swing, Flash, Xamarin, ReactNative, Flutter...) It's not something I want to build a business or a career on.
But I guess if Flutter works for you and your users right now then why not.
True, some apps could be packaged websites, but you will always be able to tell. The Twitter app is one example, and it's definitely not as smooth as 3rd party native apps, or even those made by React Native or Flutter. I simply consider PWAs a bad user experience based on the many I've tried.
Also, look at this benchmark where native image PGO is now outperforming JIT in peak throughput: https://medium.com/graalvm/graalvm-for-jdk-21-is-here-ee0117...
IMHO, UI toolkits based on low level technology stack are the future. It just that they are massive undertaking. It's not impossible to implement cursor animation with low CPU usage.
Literally 99% of the people we talked to did not notice or care
Or they've decided there are better things to do than try to convince someone who's got a vested interest in defending their current tech stack. The text rendering problems with e.g. Github are something even a blind person could see – yet you're dismissing them as highly arcane things that only a developer would notice.Actually, a blind person would also likely notice your non-native app because it almost certainly doesn't integrate well (if at all) with operating system accessibility features.
You've reduced the problem from something apparently everyone can readily see to now the blind (again, blind who? Blind developers). Accessibility is important which is why every cross platform framework of note has accessibility solutions, the web is not the only user interface that implements accessibility. This says nothing about how much people who are able-bodied care, which, again, is the vast majority of people who simply do not care. Just because one observes some problem to exist does not mean that everyone else feels the same, however much one would like to be vindicated of their experience of the problem.
You've reduced the problem from something apparently everyone can readily see
And you've dismissed this as something only a developer would notice:https://user-images.githubusercontent.com/1002257/248511013-...
https://user-images.githubusercontent.com/440661/246317472-a...
https://user-images.githubusercontent.com/128169473/23926115...
You're greatly overestimating how willing people are to take the effort to complain. At the end of the day non-native toolkits have lowered folks expectations to the point that (save for the occasional "why are computers so fast and apps so slow" comments) they're quite likely to accept a low quality app.
If you've got 99% of any group agreeing on anything subjective there's a problem with your measurement.
> If you've got 99% of any group agreeing on anything subjective there's a problem with your measurement.
Okay, do your own testing and measure it however you want, then get back to me about methodological errors. Because as far as we can tell, most users do not care. In fact, we received messages about how happy they are with the apps and how slick the UX and UI are. You can make good and bad apps in any framework.