Hacker News new | ask | show | jobs
by Hixie 2603 days ago
Given our architecture, it doesn't cost us any more performance to look like the OEM widgets than a bespoke widget set, and indeed it shouldn't cost us any more to look like the OEM widgets than it should cost the OEM widgets themselves to look like the OEM widgets, because we're targeting the GPU directly.
2 comments
pcwalton 2603 days ago
Just using the GPU isn't enough. On iOS and macOS you have a compositor that has exclusive access to the display that native widgets will use. If you do all the rendering yourself on the GPU, you'll incur an extra hidden full window blit on the compositor side, which is definitely noticeable, especially in power efficiency.
link
Hixie 2603 days ago
If it is noticeable, please do file a bug with the details of the device on this you're seeing the problem. https://github.com/flutter/flutter/issues/new?template=perfo...
link
s_y_n_t_a_x 2603 days ago
It does cost more in developer hours though. Every update to every emulated UI requires an update on your end. There will be a lag between that update where apps will be noticeably different than native. Can you honestly guarantee Flutter will always keep up with all the environments you plan on targeting? Will Windows, MacOS, iOS, and Android always look and feel the same? That seems like a lot more work to maintain than building a bridge.
link
Hixie 2603 days ago
I'm not sure what it would mean for me to guarantee anything. So far, we've generally been able to release updates ahead of the OS. For example, IIRC we implemented support for the iPhone "notch" before the notched iPhone came out. Similarly, our support for Material widgets has actually been ahead of Android's in many ways. You're right, though, maybe one day it will not be.

In practice, we've found many apps these days don't even try to use the OEM UI style. Instead, they make "branded apps" with very customized widgets. Flutter really shines at this; it's very easy to make custom widgets. (Indeed, all our widgets, including the ones that look like OEM widgets, are just "custom widgets"... it's because it's so easy to make high-quality custom widgets that we're able to make OEM-like widgets so quickly.)

link
ericathegreat 2603 days ago
Relying on native components means that differences in platforms get propagated up into application developer land. Consider: Two "native" components have slightly different behaviours. Therefore, the framework also implicitly has two slightly different behaviours. Therefore, the developer using the framework has to cater for two slightly different behaviours. This is where the real pain of cross platform development happens, and the reason it has such a bad rep.

By bypassing the target environment's native controls, they're paying more heavily in render code, but they're getting rid of all of that propagation of pain to higher up the development stack. As a developer, that's a cost I'm willing to pay.

(* For reference, I have used Flutter, Xamarin, React Native and Java at various points in time, and Flutter has very rapidly become my preference. It has a consistency that I appreciate. But of course, ymmv.)

link