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.

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

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.

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.

If you write something like:

    import 'package:flutter_web/animations.dart';

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

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

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.

Doesn't seem bad to me.

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.

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!

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

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

Almost gave me a heart attack.

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.

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.

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.

Disclosure: DevTools technical writer

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.

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.

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.

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.

Size matters a lot.

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

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.

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

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

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.

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

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.

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

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.

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