Flutter and Chrome OS | Hacker News Reader

Flutter and Chrome OS

developers.googleblog.com

87 pointsluord104 comments

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

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

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.

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.

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.

> Dart literally has no natural/non-artificial following or use-cases outside Google.

What do you consider a "non-artificial following"? There is definitely a community around the language, and other companies have certainly used and are currently using it.

ocaml with the reason syntax. not quite as quick to get up and running with as dart, but pretty accessible in the long run

Because only JavaScript has the right to be everywhere?

What's the issue with Dart? It's super easy to pickup. IMHO, it's in the same category as Kotlin/Swift (soon it's getting features like non-nullable types and extension functions).

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

NPM is enough reason to not use javascript but I haven't touched javascript since introduction of typescript.

Why? NPM is a fantastic package manager.

But a disastrous registry

NPM introduced a new type of code injection.

Could you explain the code injection vulnerabilities present in NPM that other package managers don't have?

Not the OP, but my understanding is that the problem is a matter of practice: there are so many tiny packages with such complicated dependency graphs that the exposed surface for attacks is two steps past gigantic.

As someone who doesn’t use much JS/npm, but who did work with dependency graphs in software systems in a former life, my (largely academic) study suggests that this is an intractable problem in npm — that is, a solution is such a big change from npm foundational usage that it’s far more likely to be solved with an npm replacement than an npm change. I would welcome sources that either refute or confirm this.

The performance was poor enough for long enough (and continues to be, probably?) that more than one third party implementation came along to replace it. There's no real reason that NPM can't be as fast as Yarn, except that it isn't (or wasn't? I haven't used it for enough full-size projects lately that I would know whether or not it's gotten better).

What are you using instead of JS for web development?

If you really dislike NPM that much, GitHub might be here to save the day.

https://github.com/features/package-registry

Like I said, I'm using typed javascript (typescript) with some webassembly where it make sense, I am not trusting my own code without typings.

I have absolute no idea how to fix package management for javascript, NPM has its own problems that long fixed by other package mangers for other languages, it been years NPM still broken.

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.

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.

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

> there's no reason to be against attempts to challenge the status quo.

Now try justifying that ideology to upper-management :)

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

There were so many benefits to the PC compatible/DOS monoculture in computing. Competition drove down prices, the need to be compatible meant that many new advancements were done in a standardized way, and everybody got a flourishing software ecosystem to use. Monocultures come with _tradeoffs_, but you could argue that without a few of them coming along at the right time, computers would be way behind where they are now.

Like it or not, JavaScript is the #1 player on the web

In a decade, Apple has had little trouble convincing developers to take up not one but two weird languages statistically nobody was using before. I don't think the languages themselves (and even their ecosystems) are what drives or fails to drive adoption.

>Like it or not, JavaScript is the #1 player on the web

Are we talking frontend or backend here? Historically JS has ended up 'king' solely because it's the only language browsers support - but do you not think WebAssembly has the power to change things here?

And on the backend... I'd dispute that it's used for a majority of backend applications. Perhaps a majority of new applications?

JS is a much better compile target than webassembly for managed / GCd languages for the foreseeable future.

GHCJS is mature enough to write production frontend apps in Haskell. JavaScript is not required.

Try: https://github.com/obsidiansystems/obelisk

Example app: https://github.com/srid/Taut

Google seems to be commited to Dart, since they already developed linting, formatting, package manager, support for multiple IDEs... As a native iOS developer, I can say that I'm very impressed because Apple did none of that for iOS.

Dart is meh, but because Google owns it, they can change it to Flutter needs (and they are already doing that). I can see it becoming very nice language in few years, but right now it's good enough.

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.

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.

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

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

iOS does not do live resize, FWIW.

If resizing is a recent addition there, there's absolutely no excuse for what's seen on this GIF. It literally looks like a "this is why Wayland is better than X11" GIF, showing the X11 way.

Yeah, it almost looks okay until you notice the "demo" banner on the top-right sliding in and out of view as the system struggles to update the window layout.

That means the app is running on VM with debug mode, it is slower than production mode which is native not on VM.

Why not run in release mode then to really show capabilities? Poor choice.

So if hello world is that slow, imagine launching anything non-trivial in debug mode to debug it :P

Debug mode has the same performance for 10 lines vs 25k lines, it's really just that it's running in the VM, and has debugging symbol. Performance is almost the same as compiled in my experience, although things like launch and resizing are slower due to how the VM works

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

Doubtful. Chrome OS without Verified Boot isn't Chrome OS.

Something similar I've wondered about is grabbing a (full) Chrome OS filesystem image and running the compositor/browser/interface in a chroot with a Linux installation more to my taste on the outside, including up-to-date upstream kernel, etc.

Could perhaps even prune away all the stuff that's not used/wanted in this configuration. Essentially using Chrome OS as an alternative and conveniently pre-built graphical interface on the front of a proper Linux box, give the only non-command-line program I use is a browser anyway.

I've not actually tried doing this, so maybe it's just doomed to failure or has more downsides I haven't thought of than upsides.

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.

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

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.

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?

Ah, that's a shame. I don't think I'd want to use something that pulled in messy Android as a dependency on Chrome OS.

They may create dedicated shell in future. Proper desktop support in flutter is in very early stages currently.

Dart did transpile to JS, so a WebAssembly backend for a 'web native' Flutter experience on Chrome OS is imaginable.

But their app delivery platform is the Google Play infrastructure, which packages Android apps.

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.

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

I read it as an euphemism for workaround.

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.

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.

I think the TL for Flutter is no spring chicken, he did an interesting post the other day, talks about what other languages they looked at when they decided to move on from Javascript.

"Flutter was started by engineers from the Chrome team, and myself (who worked in the open source team as editor of the HTML standard)." https://news.ycombinator.com/item?id=19856079

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.

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.

It appears to be running under the Android emulation layer:

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

It sounds like they are using the Android emulation:

> targeting Android is the way to build Chrome OS apps

I don't think this is "legacy" as far as the Chrome OS developers are concerned. Android emulation is newish and improving. Before that, Chrome apps were written in JavaScript using a similar API to Chrome extensions. (They used to run in any Chrome browser, but were deprecated except on Chrome OS.)

I feel like one of the selling points of chromeos was everything running in the browser so you don’t have to worry about security problems as much and adding android and Linux support seems to backtrack on that.

Yes, true, but the Linux support seems targeted at developers only, and Android is at least sandboxed better than traditional desktop apps. For someone just using the browser, it's much the same as before.

It looks like this is going to be an OS where all apps run in a sandbox of some sort. Nothing is really native, but there is a variety of sandboxes.

https://flutter.dev/web

It's a bit murky at the moment. It seems like they plan to do a full rewrite for the open web but right now they have the Android stack working in ChromeOS and that let's you start building flutter apps in a windowed, mouse and keyboard environment.

That's wrong, this is a Flutter app, built to run on Android, running in Chrome OS.

That's what I'm saying. You can do this Android loop now, (and work on windowed UX) but they do plan a full web stack later.

Since it's their own custom renderer, they just need to write a back-end for the web (which is what they are doing)

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?

> This makes me wonder what's the battery consumption? Is it similar to electron?

what makes you think that native widgets are the most efficient ? in the end what matters is how slim are your GL calls.

Native UI toolkits (with “native” defined as system standard) have system hooks and access to functionality that third party toolkits don’t. Not sure about Android but on iOS I’m pretty sure that a Flutter app would have a battery impact closer to that of a 2D game than a traditional app, even if it’s reasonably efficient.

Games tend to animate all the time at 60 fps. That drains battery.

Flutter is more like a regular UI in that it animates, but stops when idle. Though you could write a game in it.

> Native UI toolkits (with “native” defined as system standard) have system hooks and access to functionality that third party toolkits don’t

what makes you think that ? the time when scrollbars were rendered in-kernel is long gone.

I believe the current situation is that first-party toolkits have much more insight into the OS and underlying platform than third-party developers can afford.

And I don't think that this is true. First party toolkits do the very same GL calls in the end than a third party would.

I would expect it to be similar to native widgets. After all, native widgets still need to be rendered somehow.

Native widgets on iOS are rendered with the system compositor, Core Animation. If you render everything yourself into a GL or Metal context then you have to blit everything to the context, and then Core Animation blits your buffer to the screen. (This may be bypassed in full screen mode; I don't know. But in any case if you are using native widgets at all then you have this extra blit.)

This is a significant power consumption concern.

Not knowing anything about this, are there any numbers on the power consumption of that extra blit?

I can't imagine it actually blits, it probably swaps buffers like everything since 2000.

No, it blits. Buffer swap doesn't work because Core Animation owns the entire scanout buffer. iOS apps don't have access to it.

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.

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.

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

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.

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.

"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?

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

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

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

How would they lock-in their users then?

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

I believe so: https://github.com/flutter/flutter/wiki/Desktop-shells#linux

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.

Which UI browser framework has lifespan longer than GWT?

VanillaJS for one: http://vanilla-js.com/

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

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

Another way to think about it is that most web developers outside Google lost interest in GWT long ago (if they ever tried it), and Google was one of the last holdouts.

It was also a rather gradual process. The team moved on to j2cl, but there are still occasional commits:

https://gwt.googlesource.com/gwt.git/+log/refs/heads/master

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.

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.

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.

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.

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

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

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.

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

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

Flutter probably wins in performance, but for smaller apps, React Native might be faster to develop.

You should read on articles about apps that convert from React Native to Flutter to learn why they chose to do so.

Reply on news.ycombinator.com