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.
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.
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.
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.
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.
> 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?
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.
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.
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 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.
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.
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?
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.
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.
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.)
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.
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
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.
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.
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).
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.
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:
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
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).
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.
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.
> 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?
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.
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.
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.
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.
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.
104 comments
[ 3.3 ms ] story [ 213 ms ] threadAdding good resize support may require a serious rearchitecture of your display engine.
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
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.
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.
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'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.
> 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?
But their app delivery platform is the Google Play infrastructure, which packages Android apps.
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.
"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".
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.
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.
"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
Your comment highlights one potential downside, ie. people not trusting the company because it looks confused on the outside.
> Because Chrome OS runs Android apps, targeting Android is the way to build Chrome OS apps.
> 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.)
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.
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.
what makes you think that native widgets are the most efficient ? in the end what matters is how slim are your GL calls.
Flutter is more like a regular UI in that it animates, but stops when idle. Though you could write a game in it.
what makes you think that ? the time when scrollbars were rendered in-kernel is long gone.
This is a significant power consumption concern.
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.
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.
So, does that mean that Flutter apps for Chrome OS are limited by the Desktop capabilities of Android?
[0]: https://github.com/dart-lang/sdk/issues/34452#issuecomment-4...
If they want it to be everywhere, they have to stop basing it on Dart.
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.
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.
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
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
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.
If you really dislike NPM that much, GitHub might be here to save the day.
https://github.com/features/package-registry
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.
JS might be the #1 player, but there's no reason to be against attempts to challenge the status quo.
Now try justifying that ideology to upper-management :)
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.
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.
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?
Try: https://github.com/obsidiansystems/obelisk
Example app: https://github.com/srid/Taut
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.
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.
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.
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.
As a currently mostly iOS native dev, i must say this makes me a bit nervous.
So far, the success of technologies in between those two has been rather modest.
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.
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.
You should read on articles about apps that convert from React Native to Flutter to learn why they chose to do so.