Hacker News Reader

Comment by satvikpendem | Hacker News Reader

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, just about the lack of features that they are looking forward to. For that kind of developer experience to consumer satisfaction ratio, Flutter is unbeatable. At least Flutter compiles to machine code instead of shipping a browser per app.

View on HN

At least in the enterprise space, users are well accustomed to terrible design and UX, because the people with the purchasing power aren't the users, and the users have no purchasing power. Think JIRA, or Epic EHR, or SAP - everyone loves to hate it, but it is the go-to solution because it does what the people paying for it want.

The bar is so obnoxiously low in that space that your app literally just needs to work, and people are happy with it.

Same goes with a lot of prosumer software. People complain about missing features they need, because having a slick UI is very much a secondary concern, well after "is this actually doing everything I want it to do?" and "does it have all the features I want to accomplish my goals".

> People complain about missing features they need, because having a slick UI is very much a secondary concern, well after "is this actually doing everything I want it to do?" and "does it have all the features I want to accomplish my goals".

Well, yes, that is the point of software (and any technology in general), to accomplish the goal that the user wants to accomplish. I'm also not talking about prosumer apps per se, although I've made those too, but true consumer apps as well, no one has really complained about the UX, in fact they actually like that I'm able to make slick animations inside the app for quite a cheap computational cost. Since Flutter is basically a 2D game engine, it's optimized for those operations. I'm never gonna write 5 different apps for 5 different OSes anymore, it's a monumental waste of human labor.

I work in the enterprise software space and the last thing regular users want is a flash modern ui. They want familiarity, because enterprise software is like an extension of a user's mind and they want it to stay the same until they retire. I have seen first hand how a auto factory worker can capture data in a green screen terminal plastic covered keyboard faster than using a flash web UI and a mouse. Speed and familiarity are the orders of the day.

Indeed, it's akin to why some programmers like Vim and other terminal editors over GUI based ones. It's the exact same concept.

> Good for you, but most people can't tell nor do they care

Yeah, Apple diehard fans like to repeat how consistent the experience is on MacOS, how incredible it feels compared to any other platform. But in practice very few people care: Windows has zero consistency anywhere (even in the OS settings themselves) and nobody cares, and even on MacOS nowadays, most people are using electrons apps daily, which breaks the conventions so even MacOS isn't homogeneous either in practice anymore (and Electrons app get a lot of flak on all platforms, but it's mostly about RAM usage and overall mediocre performance, and even then it's mostly nerds like us who complain).

> most people can't tell

Hard disagree. I'd take the sibling comment about enterprise users getting used to poor UX and take that a step further: most users anywhere expect poor UX and expect to be ignored.

Take the Github UI refresh (yes it's not an "app", but hear me out). They've literally reinvented the text display widget in the browser. One of the core things that a browser does and Github reinvented it.

Public feedback has often been quite harsh. After a long public beta, it still choked on multibyte characters, it's laggy, it doesn't respond to keystrokes the way a native app (or even the browser itself) does, sometimes it displays spurious characters, and in some cases creates blurry text. Users have had to point out how to deal with multibyte characters Javascript, someone recently complained of excessive eye strain because text is so blurry.

What has Github done in the face of that feedback? They've doubled down on their custom widget and largely ignored the reported issues.

> For that kind of developer experience to consumer satisfaction

Again I strongly doubt you're getting an accurate measure of customer satisfaction if you think folks don't notice non-native apps. Earlier today I was actually trying to think of larger mac-native apps released by not-Apple and couldn't think of anything. The closest I could think of was Fusion 360 and that uses Qt.

As much as I notice how janky VSCode and Signal are, I'm not going to bother providing feedback that Electron sticks out like a sore thumb. With Fusion, the only feedback Autodesk ever responded to was the whole "hey you're pointing customers at staging resources" thing. It's a bit of sunk cost fallacy and a bit of "good enough". By and large once a company has picked a tech stack they're not going to move away from it without some serious motivation.

HN, GitHub and other such sites heavily skew towards developers who can tell, yes. I am talking about the vast majority of people who, I guarantee you, would not be able to tell a native component from a non-native one. The teams I have been on have done user testing for precisely this, comparing native vs cross platform frameworks as we were evaluating whether to use them or not. Literally 99% of the people we talked to did not notice or care, which actually falls in line quite nicely to how much of the US population are software engineers, ~1%.

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.

  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.

We didn't have a "vested interest" in any tech stack, this was all preliminary testing before we built out anything. If you want to take any evidence of what people empirically care about as being somehow a bias or flaw in testing methodology on our part, then do your own user testing and likely come to the same conclusions as us.

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.

Sure, that's an egregious example, maybe GitHub did mess up, I won't deny that, but that one example is not indicative of the entire class of cross platform frameworks being useless.

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

I have never seen this problem on GitHub, which platform does this happen in?

People care about battery drain: https://github.com/flutter/flutter/issues/59327

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?

It does suck that Flutter doesn't have as much bandwidth for people working on it as I'd like, but I'm not sure there's much one can do short of directly contributing and sending PRs, which it seems the author of that issue has done for a temporary fix.

The "temporary" fix is to allow developers to disable the cursor animation, i.e deviate from the native look & feel.

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.

Well, I guess there's no free lunch after all. At least it's better than Electron in that it's compiled code, and that it works on 6 different OSes.

I disagree. Web technologies are highly optimised for what they do (i.e text field uses 0% of CPU), run compiled code on all platforms and don't waste resources on chasing this unachievable and pointless native fetish.

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.

And how are those web technologies going for the bloat of Electron? There is no free lunch.

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.

Not sure why you keep harping on Electron. It's not even available on mobile and choosing to distribute an entire browser engine with every single app is not the same thing as choosing web technologies in general. The Dart runtime isn't any faster than V8 either.

My point is that web technologies are quite poor for building multi-platform apps, something which Flutter excels at, even as it has its own issues. I consider those a worthwhile trade-off. I don't understand the points you're making, first you talk about battery drain, fair, then you talk about native, but it seems like you're missing the fundamental benefit of why some devs choose Flutter, which is that it works everywhere you need it to, and fairly fast, too. People use Electron for this generally, so that is why I brought it up, and I am saying that Flutter is a better alternative to Electron and other web technologies, and I am not sure exactly what you mean by web technologies, but I colloquially understand that to mean HTML, CSS, and Javascript. They are good at things like text rendering at 0% CPU precisely because they've been honed over decades, something which Flutter has not yet been able to.

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.

It's incorrect to say AOT is always faster than JIT (without profile guided optimization). And it's reasonable to call jit-eligible code sometimes compiled.

That is true, I (and the parent) should not have made claims either way about their respective speeds without thorough benchmarks.

Client apps are most of the time not long running processes where JIT could reach steady state performance and startup time is important. So in practical terms, AOT is faster than JIT majority of time in this use case.

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

>My point is that web technologies are quite poor for building multi-platform apps, something which Flutter excels at, even as it has its own issues. I consider those a worthwhile trade-off.

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

How would you make cross platform apps using web technologies, including mobile, desktop and of course web? I've tried a lot of web-based frameworks like Capacitor, Ionic, Cordova and even React Native (which isn't necessarily web tech as it's just a DSL to call out to native components), and I haven't really been impressed with either the performance or UX of any of them. They all feel (except RN) like you're using a website, not a native app, which is because that's basically what you're doing.

Thanks for the benchmarks, seems they're about even.

>They all feel (except RN) like you're using a website, not a native app, which is because that's basically what you're doing.

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.

Technologies like Flutter, Blazor, Rust GUIs that similarly draw to the canvas etc also are all leveraging WASM and WebGPU too though, so I'm not sure how much benefit there is on using the pure web for stuff like this. Even Figma's main canvas editor is written in C++ and some Rust, it's not using Javascript. I expect that if WASM and WebGPU become mainstream, people will simply use their programming language of choice and render to a canvas via WASM, and be able to port that to mobile and desktop. This is basically what Flutter does anyway so it's ahead of the curve of what you're predicting.

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.

I've had a decent experience building a webapp that can be used on the browser, and with some light packaging on the desktop and on mobile without being a full on electron app (webview instead).

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.

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

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.

> People care about battery drain: https://github.com/flutter/flutter/issues/59327

Yes, but this is a completely different topic.

Not if the topic is choosing a technology stack for mobile development. Battery usage is an absolutely key consideration. It's the one thing that many users will notice even if they don't care about tiny UI differences.

Except you were posting on a sub-thread discussing the importance of those “tiny UI differences”.

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.

>Except you were posting on a sub-thread discussing the importance of those “tiny UI differences”.

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.

Sigh … It's 2023 and somehow some people still don't know how to use internet discussion boards… Come on, you've been lurking in there for the past 16 years!

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

[2]: https://news.ycombinator.com/item?id=37699571

[3]: https://news.ycombinator.com/item?id=37699185

I do not accept that discussing battery usage in a debate about cross platform technologies is-off topic just because the direct parent comment didn't mention it.

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.

My statement wasn’t merely about UI. It’s about a lack of respect for conventions. It’s about many things that are inherently wrong with Flutter’s pretend-to-be-native approach, which happens to include UI boondoggles.

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.

The abysmal macOS System Settings, with how it cribs from iOS design language, seems to be doing what Flutter is accused of. Though perhaps that is less the fault of SwiftUI, and more of Catalyst.

Reply on news.ycombinator.com