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

81–90 of 467 posts

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

#81

Post by michaelchisari »

leeoniya wrote: post #78
michaelchisari wrote: post #30

Earlier quoted context omitted.

I tested it, and the "Hello, World" example results in a 560k js package. Uglified and minified takes it down to around 480k. Gzip takes that to 140k and Brotli compression to 100k. That's a lot to bootstrap an app with, but it's not unreasonable, considering what most frameworks these days will start you with.

it's not just what goes over the wire. that's 560k of JS that has to be parsed and compiled, which is a shitload.

True, but (unfortunately) it's hardly an outlier in today's ecosystem.

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

#82

Post by Godel_unicode »

cmroanirgo wrote: post #52
jwiley wrote: post #38

Earlier quoted context omitted.

'main.dart.js' in the example Flutter KENKEN app linked in the blog post: Chrome - 359kb Firefox - 990k I agree that Chrome is becoming more and more a proprietary channel for Google products, which is probably what its original intent was all along.

That's a very large payload difference indeed!

See other comments, they're actually the same file. The heading names in developer tools are just slightly different.

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

#83

Post by Zekio »

Hixie wrote: post #64
eitland wrote: post #22

Earlier quoted context omitted.

Are you saying this isn't a web framework but rather a Chrome framework??

(I'm the Flutter TL.) We support targeting the Web (that's the tech preview we released today), and we support targeting Android, both of which ChromeOS support. We also support development on ChromeOS.

Is there a reason you guys are reinventing Flash under the name flutter? because from what I can tell that is exactly what is happening

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

#84

Post by westoque »

zackbrown wrote: post #26

Has Flutter solved its footprint-bloat problem? The internet is littered with reports of 10-100MB+ .ipa and .apk binaries coming out of simple Flutter apps for iOS + Android. Google states they can't imagine the footprint ever dropping as low as 1MB. [1] On Web, 1MB of base runtime is a complete showstopper. Embedded applications may suffer similarly. Does today's announcement mean Google has figured out how to fix t…

I don’t understand the obsession with small binaries and compiled packages. I care about usability and user experience. If it takes 5mb to have a smooth experience then I’m all for it.

It’s funny how we now have fiber having 1GB/s internet speeds and we rant about having 1MB size package being too big. Also, everyone’s moving to 4k now with even bigger transfer/data requirements.

tldr; 1mb should be a non issue as long as experience improves.

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

#85

Post by dliff »

solarkraft wrote: post #13
saagarjha wrote: post #11

Earlier quoted context omitted.

I’m not sure why this is downvoted, as it summarizes Flutter pretty well. Flutter’s “Cupertino” theme is obviously an emulation if you use it for more than a minute. If you want your app to look like an Android app on both platforms, though, I think it does pretty well at that.

Do users care? It doesn't feel exactly native on Android, but is still fast and looks great (it might indeed be better than native). Afaik the main alternatives, RN and Web (for fully reusable UI) are both heavy and don't feel that native either, yet are popular with developers.

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 RN app, within the confines of the problem RN attempts to solve, does not feel heavy and is actually indistinguishable from native.

From my experience I would surmise a lot of badly performing RN apps stem from poorly written JavaScript, especially bad state management (lots of devs who perhaps have only written web JS in the past?).

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

#86

Post by tlrobinson »

aerovistae wrote: post #56
yesimahuman wrote: post #40

Flutter for Web is heavily reminiscent of Famous with its custom layout system and off-DOM rendering (or guessing DOM rendering support w/ CSS transforms of divs). To see, just view-source on the NYT demo. Quite divergent from the web platform in my opinion. The fact that they have to re-implement copy and paste (and, accessibility features!) further adds to that: https://medium.com/flutter-io/bringing-flutter-to-the…

God, I totally forgot about Famous. That was honestly one of the weirder things I’ve seen in my years of web development. Such a gorgeous website and yet I never really understood what they were trying to sell me on. So much marketing, such little end result....never went anywhere, never amounted to anything meaningful.

Apparently they're still a company, and still a lot of marketing with little end result: https://famous.co/

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

#88

Post by saagarjha »

westoque wrote: post #84
zackbrown wrote: post #26

Has Flutter solved its footprint-bloat problem? The internet is littered with reports of 10-100MB+ .ipa and .apk binaries coming out of simple Flutter apps for iOS + Android. Google states they can't imagine the footprint ever dropping as low as 1MB. [1] On Web, 1MB of base runtime is a complete showstopper. Embedded applications may suffer similarly. Does today's announcement mean Google has figured out how to fix t…

I don’t understand the obsession with small binaries and compiled packages. I care about usability and user experience. If it takes 5mb to have a smooth experience then I’m all for it. It’s funny how we now have fiber having 1GB/s internet speeds and we rant about having 1MB size package being too big. Also, everyone’s moving to 4k now with even bigger transfer/data requirements. tldr; 1mb should be a non issue as lo…

> It’s funny now that there’s fiber having 1GB/s internet speeds, we rant about 1MB size package.

Half the people in the world probably struggle to have access to a 10 Mb/s connection. Even I go to places with connections that are tenuous at best.

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

#89

Post by justinph »

yesimahuman wrote: post #40

Flutter for Web is heavily reminiscent of Famous with its custom layout system and off-DOM rendering (or guessing DOM rendering support w/ CSS transforms of divs). To see, just view-source on the NYT demo. Quite divergent from the web platform in my opinion. The fact that they have to re-implement copy and paste (and, accessibility features!) further adds to that: https://medium.com/flutter-io/bringing-flutter-to-the…

Try using keyboard navigation or a screen reader on that NYT demo. There isn't a single accessible thing on the page. Not even the logo. You can't even select the text. It's awful.

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

#90

Post by ehsankia »

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…

GWT lived for over a decade (how many web libraries do you know that have survived for for that long?), AngularJS is still in maintenance mode, Dart died when it didn't get browser support and Typescript was obviously the better alternative.

At the end of day though, I look at if Google itself is using it extensively, because that's when a library will have the best support/longevity.

Post reply on HN