Hacker News Reader

Comment by michaelchisari | Hacker News Reader

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.

View on HN

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.

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.

Sounds the platform needs some tree shaking.

Reply on news.ycombinator.com