
Flutter and Chrome OS - luord
https://developers.googleblog.com/2019/05/flutter-and-chrome-os-better-together.html
======
zengid
This push to extend Flutter to be a UI solution for all kinds of platforms is
really exciting. It looks like a huge piece of the puzzle is FFI support in
the Dart VM, and it looks like they're working on it [0]. I think that basic
support is going to be really important to give Flutter better support for
rich multimedia like audio rendering.

[0]: [https://github.com/dart-
lang/sdk/issues/34452#issuecomment-4...](https://github.com/dart-
lang/sdk/issues/34452#issuecomment-482136759)

~~~
josteink
> This push to extend Flutter to be a UI solution for all kinds of platforms
> is really exciting.

If they want it to be everywhere, they have to stop basing it on Dart.

~~~
dstaley
What's an alternative AOT compiled language that's as accessible as Dart that
also compiles to JavaScript? I don't think there's another more obvious
choice.

~~~
josteink
It only needs to be compiled to Wasm these days and not pure JS.

That means pretty much any existing language with a natural following and a
LLVM-based compiler can be a reasonable candidate.

Dart literally has no natural/non-artificial following or use-cases outside
Google. Trying to sell Dart via Flutter will only harm Flutter and nothing
else.

People not interested in Dart won’t change their mind over yet another UI
framework.

~~~
dstaley
WASM isn't yet a viable candidate for a complete application. There's a lot of
proposals out there to bring it in line with what you can do via JavaScript,
but there's still a lot of things that JavaScript can do more performantly
than WASM. Using a WASM language also means that interop with existing
JavaScript is a bit of a hurdle, so I still feel that Dart is a good choice.
That being said, there's nothing particularly interesting about the language
itself; I'd feel the exact same way about any other language if they also
compiled to pure JavaScript.

------
leerob
As someone who worked extensively with Dart in a previous role, I'm not sold
on Flutter.

For the vast majority of use cases, JavaScript (or TypeScript) is going to be
a better solution than Dart.

Like it or not, JavaScript is the #1 player on the web and if you're trying to
scale and share resources or code at all, you want your engineers to be
proficient in JS. Yes, Dart is similar, but it's not JS. And it's not _just_
the language: it's the ecosystem. Linting, formatting, package managers,
debugging issues, Googling problems, Stack Overflow answers, etc.

Also - Guess how much of that Dart specific knowledge was useful in my current
role? None. It's gonna be hard to hire devs who want to work on Dart IMO.

My opinion: You can have Android, iOS, Web & Desktop with 95%+ code sharing
between them using React Native + React Native Web ->
[https://github.com/devhubapp/devhub](https://github.com/devhubapp/devhub)

~~~
Apocryphon
I thought it was a truism in tech that monocultures are a bad thing?

JS might be the #1 player, but there's no reason to be against attempts to
challenge the status quo.

~~~
slow_donkey
IMO the problem is that Dart is pretty much JS and really not challenging the
status quo - My light experience with Dart is JS < Dart < TS. So if there's an
opportunity to simply use TS, I don't see the benefits of Dart.

~~~
Barrin92
AOT and JIT compilation and the fast hot reload and performance in general of
dart/flutter seem to absolutely trump JS/react native.

------
seba_dos1
That "seamless resize" GIF looks like a joke. I had to reread the paragraph a
few times to make sure it doesn't show an earlier stack being now replaced
with Flutter.

~~~
lern_too_spel
iOS and Android apps didn't support resize until recently. Adding resize
support requires additional, though usually small, work (listening to resize
events). Presumably, this means that Flutter for Android does this
automatically.

~~~
Jare
> Adding resize support requires additional, though usually small, work

Adding _good_ resize support may require a serious rearchitecture of your
display engine.

------
nvrspyx
Will Google ever provide a Chrome OS “distro” to install on non-Chromebook
machines?

I’m aware of things like CloudReady by Neverware[1] which seem to have some
investment from Google, but last I checked, it did not have support for
Android or Linux. Using community built images of Chromium OS and scripts that
“hack” it into a Chrome OS installation has been a huge pain.

I’d love to test a full-featured Chrome OS on my machines, but I’m not
dropping money for a Chromebook despite how cheap they may be because I have
plenty of machines that it could run (with good performance) on.

[1]: [https://www.neverware.com](https://www.neverware.com)

~~~
chronogram
[https://github.com/imperador/chromefy](https://github.com/imperador/chromefy)
does a good job at that.

After trying it out and looking into it more, as well as trying out a normal
Chromebook, Chrome OS just doesn't seem very interesting to me. You can't even
disable mouse acceleration or set a hostname, and the devices are stuck on the
same kernel forever. Bit of a let down, although the A/B root is nice.

~~~
nvrspyx
> Using community built images of Chromium OS and scripts that “hack” it into
> a Chrome OS installation has been a huge pain.

That's actually the exact project I was referring to with the quoted bit
above. I was on mobile and didn't have the chance to look up the exact
project. However, I had a bunch of issues when I tried it months ago. I don't
necessarily blame the script because I'm not sure if the trouble was caused by
the script, my hardware, or user error on my end. I didn't really have the
patience for it since I could get all the same functionality from any run-of-
the-mill Linux distro (Fedora in my case) + Chromium + Anbox.

------
qhwudbebd
It wasn't quite clear to me from the article: are the resulting Flutter apps
running under the Android emulation layer or are they proper Chrome OS apps?

It's great that Chrome OS can run legacy Android stuff, but it'd be a shame if
the ugly design of Android started to leak into Chrome OS proper in a way that
makes it hard/impossible to deprecate.

~~~
csande17
From the article:

> Because Chrome OS runs Android apps, targeting Android is the way to build
> Chrome OS apps.

The screenshot of "The Flutter ChromeOS lint rules in action" also appears to
show an Android app manifest.

Which, honestly, seems like kind of a strange design to me. The whole point of
Flutter is to be a cross-platform app framework; why not just add a ChromeOS
backend to it instead of running the Android version inside an Android
emulation layer?

~~~
pjmlp
Because this is Flutter/Dart team pushing their agenda, not the ChromeOS team
embracing Flutter.

Just like the Android team, usually answers with a political correct "It is
nice to have options" when asked about Flutter and Android. They were pretty
clear at this year's IO that Android's future is now Kotlin, with Java takind
a 2nd place and C++ a 3rd one.

~~~
fauigerzigerk
It looks like you could be right. If this is true then publishing the
following on the Google developer blog is downright deceptive:

 _" Because Chrome OS runs Android apps, targeting Android is the way to build
Chrome OS apps."_

Note that they're not saying it's a good way to build Chrome OS apps, they're
saying it's "_the_ way to build Chrome OS apps".

~~~
sebe
They do say "Flutter is a great way to build Chrome OS apps" and they say
"Because Chrome OS runs Android apps, targeting Android is the way to build
Chrome OS apps."

The article is about chromeos and flutter, to make it clearer, they could have
said, "targeting Android is the way to build, Flutter, Chrome OS apps."

Targeting Android to create Flutter chromeos apps currently seems to be the
go, this may change once flutter for the web and or the linux desktop support
is fully baked.

~~~
fauigerzigerk
Perhaps that is what they meant. Or maybe it isn't.

Right now, Google seems like a rudderless ship floating in a sea of
possibilities created by a bunch of very talented kids suffering from ADHD.

I think someone at Google should grab the helm and actually do some steering.

~~~
wsgeorge
I've always wondered how viable this was as a corporate strategy: why risk the
entire company on one business when you could own several that may or may not
succeed, each running (relatively) autonomously, etc...

Your comment highlights one potential downside, ie. people not trusting the
company because it looks confused on the outside.

~~~
fauigerzigerk
Looking confused is not the reason for the lack of trust. The reason is the
threat of platforms or APIs getting shut down after you have invested a lot of
time in them or built your own product on top of them.

------
0x70dd
If I understand correctly, Flutter embedders use a low level rendering API
that renders the UI similar to how a game is rendered - skipping native
widgets altogether. This makes me wonder what's the battery consumption? Is it
similar to electron?

~~~
deergomoo
Jumping onto this: what about accessibility? On iOS at least, if you use the
native controls you get a ton of accessibility support either for free or with
relatively little effort. VoiceOver has some really deep hooks into the
system.

How, if at all, does this work with Flutter? Seems like it would be like
trying to get a screen reader to describe a game.

~~~
lol768
Flutter apps, from the basic one I've built and tried, are completely
inaccessible to Talkback on Android.

I don't think this is supposed to be the case, from reading the documentation.
But I can't get any labels inside my application to be read aloud.

~~~
CraftThatBlock
I've just tried this on my apps which I've done no accessibility work yet.
It's not perfectly accessible (would need to add some annotations to some
text) but they are mostly accessible

------
bsaul
Funny to see how iOS / Apple is currently working on their own cross-platform
tech (marzipan), which means running iOS app on macOS with minimal changes
(time will tell what this thing ends up looking like). On the other side,
google is releasing a cross-platform tech that's _actually_ cross-platform.

As a currently mostly iOS native dev, i must say this makes me a bit nervous.

~~~
fauigerzigerk
The question is whether there is room for anything between _actually_ cross-
platform web technologies and _actually_ native toolkits.

So far, the success of technologies in between those two has been rather
modest.

------
tpush
"Because Chrome OS runs Android apps, targeting Android is the way to build
Chrome OS apps."

So, does that mean that Flutter apps for Chrome OS are limited by the Desktop
capabilities of Android?

~~~
CraftThatBlock
Yes, since Android apps on Chrome OS actually have the most access to the
system, more than websites.

------
didip
oof, the resize GIF is not selling it, actually it has the opposite effect to
me.

------
kderbyma
Is it just me or is Google doing everything it can to 'use' Linux but not
truly make things based on Linux.....why not just make a proper distro

~~~
slezyr
How would they lock-in their users then?

------
Barrin92
Is there also planned support for Flutter on a plain old linux desktop, and if
so is there a timeline for it?

~~~
markdog12
I believe so: [https://github.com/flutter/flutter/wiki/Desktop-
shells#linux](https://github.com/flutter/flutter/wiki/Desktop-shells#linux)

------
hit8run
Reminds me of Google Web Toolkit (GWT) back in the early 2000s. All of a
sudden Google lost interest and kind of pulled the plug. This technology seems
too risky for me to use in production right now.

~~~
riku_iki
Which UI browser framework has lifespan longer than GWT?

~~~
coldtea
VanillaJS for one: [http://vanilla-js.com/](http://vanilla-js.com/)

~~~
riku_iki
It doesn't look like UI framework (templates + some MVC + components library)
but more like set of small helper libs for JS.

~~~
CraftThatBlock
This is satire, VanillaJS is literally JavaScript. The import file is empty.

------
k_bx
I wish Google would develop protocols instead of frameworks, and only then put
Dart (and others) on top. This way people would be able to choose their
language on top, e.g. I'd love to use Elm, for one. No runtime errors, no
mutability, opinionated built-in FRPish architecture. Dart has none of that.

~~~
skybrian
That's quite a tall order since any general-purpose UI framework is going to
have a huge API surface area.

But Elm runs in a browser, so it should work fine on Chromebooks.

I guess you could use the Linux container for Elm development, but I don't
know what the rough edges are for doing web development that way.

~~~
k_bx
Well, HTML is one example of general-purpose UI framework that's separate from
JavaScript in a way that lets you replace JS with something else. Why can't
something similar be done for Flutter components?

There's an example of elm-bootstrap library, where bootstrap components were
reused, but Elm logic was added on top instead of JS one. Why wouldn't
refactoring Flutter into Flutter-core similarly work?

Also, I didn't understand your comment about the container and how it's
related to this.

~~~
skybrian
The HTML DOM API is in no way separate from JavaScript. It's a mutable API
that's tied into the JavaScript garbage collector, uses inheritance (unlike
some languages) and uses JavaScript values in method parameters and return
values. The only way to access it (once a web page is loaded) is through
JavaScript.

To interact with it from another language, you need at least an adapter layer
that does foreign function calls to JavaScript, or you need to compile the
entire language to JavaScript like Elm does. Elm works because Elm is
specifically designed to compile to JavaScript and they put a lot of effort
into making it smooth. (And bootstrap is part of the same JavaScript
ecosystem.)

In theory you could do the same thing for Flutter by compiling some other
language to Dart. It seems unlikely anyone would make the effort any time
soon, though.

Regarding the Linux container, it's not directly related; I was just pointing
out how someone might do Elm development on a Chromebook.

------
watermans
What is the advantage of writing a Flutter app over a PWA or something like
react-native?

~~~
farahday
Why don't you take literally 5 seconds to google that basic question? That
question is answered on every flutter article, including OP.

~~~
watermans
I did read the article and reviewing it again and searching for "react,"
"progressive," and "pwa" returns zero results.

I think the article opens by stating a pretty strong disadvantage:

Flutter apps run as Android apps and so are less "native" than something like
a PWA or react app, which would just run in the browser.

The article doesn't address my concern at all and I was hoping to have some
constructive feedback about that concern, which did not happen.

~~~
sebe
I'm interested to try flutter out on chromeos, I might get a chromebox, the
acer and hp i5 U series are the recommended ones for Android development.
Developing flutter without the need for a simulator or a phone connected via
usb, is cool. Maybe the next step is develope android flutter apps on android.

With regards PWAs, maybe more so on mobile, flutter apps are AOT, Ahead Of
Time, compiled for release so they should have better start up times than apps
that run on a vm.

The flutter wiki has stuff on the diffent modes.
[https://github.com/flutter/flutter/wiki/Flutter%27s-modes](https://github.com/flutter/flutter/wiki/Flutter%27s-modes)

Debug mode "Optimizes for fast develop/run cycles." runs on the Dart VM and
allows for statefull hot reload.

