Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

developers.googleblog.com

Post reply on HN
Print view View original

131–140 of 467 posts

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#131

Post by dliff »

monocularvision wrote: post #107
dliff wrote: post #85

Earlier quoted context omitted.

RN definitely feels native... assuming the developers utilized the built-in components properly. RN is an actual native component whose state is backed by a JS bridge. There certainly are poorly written / optimized RN apps. There are also apps that due to their nature/goal shouldn't be RN even at an early stage. (Startup, navigation, threading, network issues for one). However, I would argue that a properly written R…

Except for navigation

Curious where this is an issue. React Navigation feels and is, according to their documentation, composed of native components.

Vs. what you can do natively it has severe limitations and the documentation isn't the best (though I think it has improved recently).. but feels native to me.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#132

Post by cornstalks »

Hixie wrote: post #108
jjnoakes wrote: post #66

Earlier quoted context omitted.

The sizes closer to 100MB seem to be from debug builds. From the bug you linked (and this one which it links to: https://github.com/flutter/flutter/issues/16833 ), bare flutter apps are around 4MB on Android. Doesn't seem bad to me.

(I'm the Flutter TL.) According to today's benchmark numbers, we're at 4414KB on Android and 8572KB on iOS (IIRC, iOS encrypts before compressing so it can't get as good a compression). This is for our Hello World test app ( https://github.com/flutter/flutter/blob/master/examples/hell... ), which is more or less the smallest app you can imagine building with Flutter unless you bypass the entire framework and only use…

Fellow Googler here. I think it’s best to report those numbers with the appropriate SI prefix: 4.414 MB and 8.572 MB. Reporting numbers as “X thousand kilobytes” makes it harder to grok the real scale.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#133

Post by networkimprov »

kllrnohj wrote: post #109
networkimprov wrote: post #27

Earlier quoted context omitted.

Maybe Flutter works as a client to a native localhost app? (Analogous to the browser for a localhost web app like Jupyter Notebook[1].) Does it have a Websocket client? [1] https://jupyter.org

There's no reason to bother with websocket stuff, you can just call out to native code via platform channels ( https://flutter.dev/docs/development/platform-integration/pl... ) Just that once you do that you're no longer a portable cross-platform app, and there's limits to what you can do with that pipe in terms of data marshaling and the overhead from that.

Unless you're porting an existing localhost web app which is accessed via Websockets.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#134

Post by Andrex »

michaelchisari wrote: post #36
McDev wrote: post #8

Earlier quoted context omitted.

Lots of businesses are desperate for cross platform mobile dev (I'm not looking at you ), it seems to be an inevitability at this point. In the meantime React Native has come along and I don't think it's made a good name for itself in the mobile dev world. RN projects get littered with poorly implemented third party libraries that aim to bridge a piece of native functionality or SDK into the react context. I've just…

If they can avoid the issues of RN, then Dart/Flutter could be the go-to platform for early round applications that let you build a solid cross-platform app with which to prototype your business model. It will probably never be an ideal platform for mature, premium apps, but if it serves a purpose as the place to go to build a solid working MVP, then that's more than enough to keep it around.

In my opinion, Flutter combined with Firebase (one of Google's other projects) is probably the best possible combination to build an MVP today, on both quality and speed to implement.

There's probably a market here for one-off white label apps too...

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#135

Post by s_y_n_t_a_x »

ergothus wrote: post #77

No one has (yet) mentioned the main reason I ignored Flutter when it initially came out and why I continue to have reluctance - It's google. They have a terrible track record with products AND with libraries. GWT? Dart (pre flutter)? NaCl? How about all those initial Angular devs? That's not a statement on the quality of the result (though some of those examples do indicate concerns), but if I'm not alone in avoiding…

Not to mention the maintenance required for a project of this size. You have to maintain emulation of the UI for multiple environments. When those update, you have to update. Imagine a new iOS release coming out and all other native apps on the market look new and everyone sees your outdated app trying to look native. Now imagine Google putting that on the backlog, never updating the iOS controls in favor of Material. The team has to maintain this emulation for iOS, Android, Windows, and MacOS. This is unreasonable for any company, let alone one with a track record of abandoning projects.

For the record I believe Flutter is here to stay, but I don't believe for a second they'll keep the "native look" around for anything other than Material design. It's a marketing gimmick to get their foot in the door and then transition everyone over to their own design.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#136

Post by Andrex »

saagarjha wrote: post #62
vetinari wrote: post #34

Earlier quoted context omitted.

> If you want your app to look like an Android app on both platforms Funny thing is, that it is emulated on Android as well.

It is, but I trust a Google team to get that to work at least passably well.

As someone who is highly discerning of small UI issues, Flutter on Android implements the UI controls extremely well to my eye.

(Accessibility not so much unfortunately, but that is a work in progress.)

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#139

Post by skybrian »

Hixie wrote: post #108
jjnoakes wrote: post #66

Earlier quoted context omitted.

The sizes closer to 100MB seem to be from debug builds. From the bug you linked (and this one which it links to: https://github.com/flutter/flutter/issues/16833 ), bare flutter apps are around 4MB on Android. Doesn't seem bad to me.

(I'm the Flutter TL.) According to today's benchmark numbers, we're at 4414KB on Android and 8572KB on iOS (IIRC, iOS encrypts before compressing so it can't get as good a compression). This is for our Hello World test app ( https://github.com/flutter/flutter/blob/master/examples/hell... ), which is more or less the smallest app you can imagine building with Flutter unless you bypass the entire framework and only use…

Hmm, encrypting before compressing seems like a pretty strange decision. How does that happen?

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#140

Post by s_y_n_t_a_x »

Hixie wrote: post #117
cmroanirgo wrote: post #71

Earlier quoted context omitted.

Personally, I'd prefer actual native if that was my aim, as opposed to something that looks exactly like it, but actually has layers of styling beneath it in order to look the same. Why? Because if I want the native look, I'm more inclined to be sensitive to my app's size and performance. That said, I do understand that many people want the seeming of a native app, even if there's a bit of a blowout in size and perfo…

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.

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.
Post reply on HN