Hacker News Reader

Comment by zackbrown | Hacker News Reader

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 this for Web, or are just ignoring it? Or worse — are they planning to 'boil the frog' with a sneaky transition into a world of a New Flash Player?

> 1MB of Flutter runtime got you down? Don't worry, Flutter Player now ships with Chrome.

This is possibly a very dark direction for the Web, of which Google is a powerful steward.

[1] https://github.com/flutter/flutter/issues/12456#issuecomment...

View on HN

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.

Try importing `flutter/animation` — footprint goes WAY off the deep end. `animation.ddc.js` is 4.4MB alone (unminified), never mind the rest of the runtime AND userland application code.

You can see this in the flutter_web/examples/gallery example. [`webdev build` failed for me in examples/gallery, so I'd love to see what a successfully minified version of that example looks like — I'm currently deeply skeptical.]

Compared to React/Vue/Angular and friends, this appears to be a monstrous outlier.

DDC is not at all a representation of the final size of the code, as it doesn't run any kind of tree shaking, minification or optimization, and the animation library has a lot of things that you will definitely not import.

And here I am freaking about an uncompressed js payload of 300k for an entire app... 4+MB just feels crazy.

DDC stands for Dart Development Compiler. It is a fast modular compiler that you use for quick edit&refresh development in the browser. It does not do any global optimizations, unlike dart2js - which is what you use for deployment.

If you write something like:

    import 'package:flutter_web/animations.dart';

    void main() => print('Hello, World!');

DDC would faithfully compile animations.dart as whole and ship that to your browser.

dart2js would include 0 bytes of code from animations.dart into the output.

> `webdev build` failed for me in examples/gallery

Maybe file a bug?

Here is what I get for Gallery:

    ╭─~/s/f/f/e/gallery ⟨master ⟩ ⟨9s449ms⟩
    ╰─» flutter packages pub global run webdev build
    ...
    Compiled 18,344,245 characters Dart to 1,914,077 characters JavaScript in 27.9 seconds

If I gzip the output I get around 500k.

Gallery uses a lot of Flutter so this is in some sense upper boundary for framework overhead.

Also it is still early days - I can clearly see this pushed down.

May I introduce to you: preparsed Javascript sent over the wire: https://github.com/binast/binjs-ref

Isn’t that just an AST? That still has to be parsed and compiled. It just makes parsing a bit faster.

From the README:

> Current advanced prototypes already show JS parsing improvements of 30%-50% on all the most common frameworks, just by changing the format, and we believe that we can increase this improvement much further.

30% is more than a bit :).

I’ve worked professionally on pre-parsing and 30% is not a great result.

And it doesn’t help the time spent on compiling, so it’s saved not a lot of not a lot. Doesn’t really solve the problem.

Yes, but it’s more or less in line with current single page apps. In fact, quite possibly a bit smaller.

not sure how many "Hello, World" SPAs would add up to that.

The point is, real world apps have a bit more complexity than "hello, world", and the runtime cost doesn't matter as much as the app grows in size.

Sounds the platform needs some tree shaking.

I'd add that the connotation of an angulardart app isn't a simple SPA. It's meant for larger applications. I have been using it for the past year and a half and really enjoy it. The compiling times have been improving with each release.

I think the "fix" is not to accept the state of play but to challenge it.

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 the engine directly.

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.

Pardon me making a joke at your expense cornstalks, but...

Is this what a culture that AB tests 34 shades of blue looks like?

I think we can handle the conversion here in the HN comment section!

fwiw, when i saw the prefix and no commas i subconsciously assumed it was under 1000KB and read it wrong, until that comment made me take another look.

Ha, at first I thought "cornstalks" was a new slang reference for Googlers and was just over my head.

Well if it wasn’t, it certainly is now. Thanks for that typeformer.

Sorry, I just copied and pasted the number as it appears on our benchmark page. :-)

Also please be aware not all locals use "." as thousands separator. About half of the world [0], including we here in Germany, actually uses the dot as decimal separator. Thus your number "4.414 MB" actually looks confusingly close like ~4.41 GB to me on first sight. An easy way to avoid this is to not rounding to three digits after your only dot or comma.

[0] https://en.wikipedia.org/wiki/Decimal_separator#Arabic_numer...

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

I believe the literature says that compress before encrypt is less secure, because compression behaves predictably. See CRIME attacks.

But, why compress at all then? It won't do anything.

I'm not sure this is a good enough reason to never compress anything.

Maybe they encrypt with rot13. Compression should work on such a "ciphertext"...

To clarify to anyone else who may have been confused as I was: the "quoted" text in the parent post is not an actual announcement from the source URL or anywhere else, but a hypothetical future situation.

Almost gave me a heart attack.

> This is possibly a very dark direction for the Web

Yes, that imagined dark direction for the web is indeed very dark.

Call it too big to ship reasonably, but Chrome didn't ship an Angular player or Polymer player, so I don't see what suggests they'd start now.

Didn't they ship a Dart VM?

They decided not to: https://www.chromestatus.com/feature/6682831673622528

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

It's actually the very same main.dart.js (dart2js compiler does not have ability to target a specific browser, its output is supposed to work in every supported browser).

359kb is its compressed size, 990k is its uncompressed size.

Firefox shows compressed size in the "Transferred" column and uncompressed size in "Size" column.

In Chrome by default you see compressed size only, but if you click "Use large request rows" then you will see both compressed and uncompressed size.

Use large request rows in Chrome DevTools to see transfer size and uncompressed size: https://developers.google.com/web/tools/chrome-devtools/netw...

Disclosure: DevTools technical writer

to be fair even angular has sizing problems. a "simple" app can easily grow to over 200kb gzipped content (including polyfills). and 200kb is a lot for a simple application.

currently our "big" application already grown to over 600kb gzipped js. I'm pretty sure flutter has the same problem. I think as soon as people start using a SPA their js size will skyrocket.

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.

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

(I'm the Flutter TL.)

Yeah, I was just writing a design doc earlier today and my math for how big a download we could reasonably expect users to wait for was based on a 5Mbit/s download speed. Half a megabyte takes under a second at that speed, but 5 megabytes takes more like 8 seconds. That's a huge difference. In an environment like the Web, where ephemerality is the norm, you really have to stay below 1MB from what I can tell.

All of this takes memory. Also i do a lot more than use some crappy flutter calculator.

India. Next billion users.

Size matters a lot.

Also please consider how many seconds will it take for a cheap Android phone to parse 5 Mb of JS (and how much memory it would take after parsing, which can be up to 10 times more that original code size). I think it can become much more than 8 seconds, and during parsing the browser will likely become unresponsive.

Should try all your Dev and browsing on a 2gb low end Chromebook, and last gen lower end phone for a couple months. Then see how you feel about it all.

I develop apps for tvs, so size and performance matters a lot since they are a lot of tvs already shipped with low end SOCs. newer ones are more powerful, but people doesn't change tv as frequently as phones.

I think there’s a middleground there that if you want to support these countries then there should be a framework for this (Flutter Lite?).. But if you want the complete feature set that is “bloated” but has good ux/ui support then that should be fine as well.

"these countries"? I've seen schools in the US with 15 mb/s My mothers, Xfinity, has a low tier, 25mb/s.

A lot of Australia is still stuck on ADSL with speeds of 5 - 20Mb if your lucky

(I'm the Flutter TL)

Our current plan is to support the complete feature set while still supporting places with connectivity around 5Mbit/s. We are still in very early stages (we only just put out the tech preview today!) but we have some confidence that this is possible. Personally I'm more worried about the performance of layout animations (e.g. resizing paragraphs) than about download size, but again, it's early days still.

It's not just the transfer... It's the compile, load and perceived speed. 1mb compressed and gzipped can be a hundred MB parsed and in memory. Which isn't bad on a modern mid level desktop, but it's crazy on a lower end smart phone.

There are also other factors to consider. I'm not huge in premature optimization, but damn.

I don't think it's the actual file sizes that people object to so much as all the redundancy and inefficiency that the bloat is indicative of. That is, for every increase in CPU, storage, and bandwidth; app developers insist on throwing it away with another layer of frameworks and intermediary libraries.

What Moore's Law giveth, React/Flutter taketh away...

There are smaller/faster ready like libraries such as preact and inferno btw. React does offer a lot of advantages though mostly for diagnostic purposes for developers.

Faster speeds for some do not equate to faster speeds for all. This applies doubly so when bandwidth is metered and may cost the end user more money.

Abstraction for the engineer should not come at the expense of the person on the other end of the wire.

I disagree. I think Ruby/Rails is a good example of this. They maximize on developer happiness but that doesn’t stop users from using a bloated rails app. Take a look at GitHub/GitLab as an example of a Rails app I guess?

I don't see how end users suffer from using Rails. Server side rerponse time is a very small component of page load time for most websites. It's different from being forced to download and parse megabytes of JS, which consumes CPU, battery and time.

Not to mention your data plan

There's more CPU time across 1000 users' browsers than on the server. That doesn't mean you shouldn't try to minimize your load at both ends.

The difference is who pays for the load.

And now that developers make the visitors pay for the load (through their electricity bill, and also through their mental state), they don't give a shit about how much the users will have to pay - and thus how much electricity will be unnecessarily wasted on a global scale.

No offense, but you sound like Verizon charging Netflix for what users are pulling down.

I haven’t used rails in about a decade. Is the bloat of a typical rails app on the user’s machine?

Not everyone is so fortunate to have 1GB/s internet.

Waiting for a page to load is a terrible user experience.

Outside of a select few cities, getting anything more than 100 mbps down is literally impossible unless you have the budget to pay a company to run fiber to your home (at least tens or hundreds of thousands). And outside of major cities, 10 mbps might be the best you can get.

Not to mention there are a thousand situations even inside of the major cities where a few mbps (if that) is all you can muster.

I for one hate pages that take minutes to load... and it happens a lot more than you’d hope.

...in the US? Here in Europe I’m paying 30 euro/month for 200 megabit down (just 20 up, though), and I live in a 50k people town.

Even in London I think some places only get 10Mbps

I'm getting 32 mbps from BT for £52.49. My O2 mobile internet hardly works at all. London really has terrible internet infrastructure. I wouldn't be surprised at all if some people got no more than 10 mbps as you say.

> London really has terrible internet infrastructure.

I think it probably has average infrastructure shared over too many connections. If I do 4G speed tests up north, it's always way faster but there's also way fewer people trying to use it concurrently...

>I think it probably has average infrastructure shared over too many connections.

Which makes it indistinguishable from terrible infrastructure :)

More people sharing the infrastructure also means more people paying for it. So in terms of value for money London's internet infrastructure is terrible even by your very lenient definition.

My old place was getting 12-16Mbps over ADSL despite being only 400yds from the exchange. Fibre improved that slightly to 20-25Mbps.

(New place has 1Gbps fibre - average is about 300-350Mbps during peak times, 800Mbps+ in quiet times.)

Test on a phone, anything over 1MB will lock up the script parser for a few seconds.

The irony is, the same people complaining about 500kb are probably the same people using a 100MB+ terminal emulator built using a web browser (i.e. hyper).

You don't download the entire app every time you change directories like you do navigating between sites in a browser.

If you're sending JavaScript down the line with every request, you're doing it wrong and should give up your career.

When you go to a new website, it doesn't download anything?

NEW website. As in, ONCE and FIRST TIME.

I have gigabit internet and the web is still dog slow. It got a good bit faster when I started blocking third party garbage, but it still doesn't feel any faster than it was in the early 2000's, despite that my internet is literally 17,000 times faster and my computer is also tons faster.

This has also been my experience, uBlock origin improved performance on many websites (and also clues me into how many unnecessary connections by analytics and tracking servers are made by so many sites). It is mind boggling to see sometimes 250+ blocked requests on the badge for a news article.

Yeah. I started very aggressively blocking all third party stuff and then I manually whitelist things as needed. Its crazy how many requests some sites make, for stuff that has no impact on the content I actually want.

Reply on news.ycombinator.com