Flutter's Wayland support is used by Google for a consumer product with millions of users. (source: I work for Google.)
574 karma · joined February 13, 2010
That said, yes, if you want small download sizes on the Web then Flutter isn't the technology for you.
Concretely: our minimal overhead is about 300KB gzipped currently. We expect that to go down a bit before we exit beta, but a "hello world" in Flutter for Web will never get down to the few dozen bytes that you could get using pure HTML.
Fundamentally our approach will always have a large overhead compared to other Web technologies because we don't use most of the built-in features that browsers bring to the table like CSS and HTML and so on. We have our own layout, our own compositing, our own gesture detector, etc. We even blink our own cursor. The only features we use are the lowest-level ones like `canvas` that are needed to actually push pixels to the screen, or ARIA which is needed to expose the accessibility tree.
On the plus side that means you can do anything you want. You want the text cursor to look like a wiggling snake with eyes that follow the mouse cursor? No problem. You want a checkbox that exactly matches the Material Design spec? Or that exactly matches the iOS design language? No problem. The cost is that all that code has to ship with your app.
FWIW, one of our driving values is to specifically _not_ compromise in this way. We actively avoid having a "lowest common denominator" approach. I learnt about the risks of such an approach when I was the HTML spec editor. It's one of the reasons that we have been only adding new platforms very carefully, and it's why we've been focusing so much on mobile first. The vast majority of the team is focused on mobile, with a small team on Web and an even smaller team (1-4 people depending on how you count it) working on desktop.
What size would you consider acceptable for a mobile Web app?
I wish I had our notes from back then, but I looked for them recently and couldn't find them. Our best theory is we did it on paper or on a whiteboard. :-(
In practice, we've found many apps these days don't even try to use the OEM UI style. Instead, they make "branded apps" with very customized widgets. Flutter really shines at this; it's very easy to make custom widgets. (Indeed, all our widgets, including the ones that look like OEM widgets, are just "custom widgets"... it's because it's so easy to make high-quality custom widgets that we're able to make OEM-like widgets so quickly.)
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.
As far as the bit about Flutter goes: Flutter was started by engineers from the Chrome team, and myself (who worked in the open source team as editor of the HTML standard). We had no relationship with the Dart team at all until some times into the project, when we were looking around for a language to replace JavaScript in our project (codenamed Sky at the time). We considered a large number of languages but ended up picking Dart because it was the best fit (see the Flutter FAQ for more details). We then had to learn Dart and made friends with the Dart team, with whom we now work very closely.
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.
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.
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.
As a target platform or as a development platform?
We don't support targeting Linux out of the box today, but we support Linux as a first-class development platform (it's what I use). That said, we do work on Linux, and if you're willing to do a bit of work, you can use it to write Linux apps. If you want to target X11, you'll need something like https://github.com/google/flutter-desktop-embedding whereas if you want to target the hardware directly, you can do something like https://medium.com/flutter-io/flutter-on-raspberry-pi-mostly... .
If you can tell that we're not using OEM widgets, we consider that a bug. Please file it and explain what the difference is. We're definitely not perfect, but fidelity is a high priority for us this year.
https://github.com/flutter/flutter/issues/new?template=BUG.m...
Regarding the crash logs, it has definitely helped us improve stability. We do try hard to notify you that it's happening. It's opt-out because people don't tend to opt in to that kind of thing and so the data would be more or less useless (not representative of real usage) if we made it opt-in.