Hacker News Reader

Comment by owaislone | Hacker News Reader

Yes it has GUI. Flutter is the main/official way to build apps on it. The OS shell is also written in Flutter if I remember correctly. So far, the OS has been seen on or confirmed to release in near future on one Google Home device. Technically though, it seems to be designed for all kind of consumer devices ranging from phones to desktops.

IMO this is more or less an experiment which if successful, will end up merging/replacing Android and Chrome OS into a single OS. Android and Chrome runtimes can be ported to Fuschia and the underlying OS can be swapped on many devices. New devices can ship with Fuschia + an android compatibility layer. Developers would be able to ship native Fuschia or android apps. Would work on phones, IoT, Chromebooks and could be install-able on desktops.

This is all just speculation though and a lot of things need to go right for this to happen but I'd imagine this would be the ideal/desired outcome for its creators.

View on HN

Maybe it's just my laptop, but most Flutter apps I've tried were clunky and draining CPU like crazy. On top of that other people here have mentioned problems with the framework concept itself which causes certain bugs to just linger for years, because they can't be fixed.

I don't really understand the excitement around flutter.

Developing new stacks from top to bottom is crazy expensive and time consuming. Modern OSes have benefited from many decades of optimisation and you can't replicate that overnight. Even a far superior new architecture will start out worse in almost every way and take a long time to catch up.

Just look at Apple's rollout of Swift. Early on it was slow and painful to use for a long time. In the last year or so it's really matured a lot, but it's been a long road and we're still not there yet for a lot of use cases.

I have experienced the same performance performance on laptop and phone (Google pay).

Yeah—the news that Fuchsia was embracing Flutter as the main way to develop applications was when my interest in it when from very high, to middling. May as well just be web apps at that point, for how they burn resources, latency, and overall feel. I was excited by the promise of an open-source QNX-like OS with a GUI layer that's not a complete mess (like the Unix-alike open source world's is) but it seems like they're heading toward something closer to ChromeOS, which I emphatically do not want.

Flutter is the easiest way to write GUI applications on Fuchsia today, but by no means the only one. There already exists a Wayland to Scenic translation layer. Adding support to Gnome or KDE is totally possible. There is even a rust GUI framework under development in the fuchsia codebase called Carnelian. Like Linux, there is no concept of native platform widgets on Fuchsia. It is up to a product developer to build up those types of layers. The Workstation product may build up such a toolkit of native widgets, but that won't bound the possibilities of what you can do with Fuchsia.

I'm very conflicted with flutter. The developer story is tempting, cross platform consistency but extendable to each system's specifics.

On the flip side there's the odd programming language, the bundle size, the game-engine like rendering (seemingly wasteful, but may improve as hardware evolves).

I find it odd that you consider Dart an "odd programming language", given it is a very "mainstream" language. One of its core goals is to be unsurprising and easy to learn.

except their web story is horrific. they render the entire thing in a canvas which means a giant F.U. to non English-FIGS and a big F.U. to accessibility as well as extensions

Definitely, I remember from reading the documentation that they could also target HTML5/css (https://docs.flutter.dev/development/tools/web-renderer) instead of canvas but I'm not sure how complete / coherent the output is.

what does FIGS stand for?

A short search revealed that it’s a term of art in localization, referring to French, Italian, German, and Spanish. Typically these are the first targets when localizing an initially-English product.

I have no idea what, if anything, Flutter’s canvas-based approach has to do with localization.

Also Flutter exposes a hidden DOM with accessibility information for the canvas. This might someday be superseded by a system like AOM: Accessibility Object Model, which is an API for directly constructing an accessibility tree for non-DOM content like a canvas.

Flutter, because it's using canvas, doesn't play well with text input for non E-FIGS languages. Even when it does work it's a 2nd class experience. Open a flutter demo, switch your OS to a Chinese, Japanese, Korean, type some CJK, watch as it shows placeholders while it goes and downloads fonts. Now try to select the text and use the OS's reconversion features (something you might not be aware of if you don't regularly use non-roman character languages) Install some language or accessibility helper extension. Go run a Flutter demo. Watch as the extension has no way to find the text because there is no text to find, just pixels.

That flutter even got this far strongly suggests the people making it are monocultural. That they are thinking "maybe someday there will be a solution" is not the right way to approach building an inclusive GUI framework in this day and age.

Aha, I think we misunderstood your initial post. You meant "non-English and non-FIGS" languages. Thanks for replying with additional context. I definitely learned a few things.

I see what you mean about Flutter having to download the 16+ MB CJK fonts and lack of visibility for extensions trying to read DOM text. It's possible there's fixes for some of these: the browser local font API could make your local system's fonts available to the Flutter runtime, which would be significantly faster, and the accessibility object model could make content visible to extensions (but only if they were rewritten to read AOM data!).

Also TIL about "reconversion" in CJK IMEs. Pretty neat!

I'm working with some of these same issues right now with a web-based PDF viewer app that runs PDFium in WebAssembly. Trying to make PDF content visible to extensions, IMEs, etc. the same way DOM content is turns out to be quite difficult.

Still, all of this works out of the box with DOM content. It's frustrating how many of these things have given up on "render to DOM".

First thing that comes to mind (as a GUI developer that is currently translating a product) is that the text renderer can't handle accents above and below Latin characters. (e.g. Let's buy crème fraîche in Curaçao) I'd also be surprised if it can handle right-to-left strings as well.

Flutter uses Skia for text rendering and layout; the same rendering engine used by Chrome, Android, and others. I'm beyond confident it can handle all of those situations.

Flutter demos have a localization dropdown for selecting different locales, of which the gallery demo at least supports many, well beyond FIGS: https://gallery.flutter.dev/#/

Note those demos have other problems that make me crazy, like the copious overuse of non-selectable text. Why the default "Text" widget is non-selectable is a total mystery to me: https://api.flutter.dev/flutter/widgets/Text-class.html You have to instead use the "SelectableText" widget: https://api.flutter.dev/flutter/material/SelectableText-clas...

I have plenty of complaints about Flutter, but accessibility and localization aren't among them.

Except Skia is not a text renderer. Skia won't correctly position glyphs for you. It can only render glyphs for you at positions that you provide.

Your understanding of Skia may be out of date.

See SkParagraph: https://skia.googlesource.com/skia/+/refs/heads/main/modules...

And the experimental SkText API: https://skia.googlesource.com/skia/+/refs/heads/main/experim...

It's possible; I haven't looked at Skia for some time. As far as I can tell, in the past, https://skia.org/docs/user/tips/#does-skia-shape-text-kernin... applied.

Fuchsia does a lot of interesting/new things, but the primary motivation for Fuchsia was to make it possible to update the OS independently of drivers. Everyone complains when their Android devices stop receiving software updates, and nearly always the reason that new Android versions can't be backported is that the devices have custom hardware drivers (perhaps closed source) that would need to be be updated to work on newer versions of the Linux kernel.

Since Fuchsia was started, Google has committed to maintaining a stable kernel ABI for AOSP, what they call the GKI. This is a huge amount of work for kernel developers at Google but it will allow (in theory) updates to newer kernels without the need to update these old drivers. I believe ChromeOS is also going to use the GKI (not 100% sure about this though).

I think the big question for Fuchsia is how successful the GKI initiative is, since it takes a lot of wind out of the sails of Fuchsia. Linux already works, has a lot more features than Fuchsia, and has much better performance.

> ... Android and Chrome runtimes can be ported to Fuschia ...

Android is already being ported to Fuchsia for quite some time now.

I thought Google would no longer follow the idea to replace Android with Fuchsia. Do you have a source for this statement?

Yes, check the AOSP Gerrit commits related to Fuchsia, quite a few of them there.

You can start with this one,

https://android-review.googlesource.com/c/platform/manifest/...

There is no compelling reason to keep Android running as some legacy option when they are making Android and more generally Linux compatibility as a goal.

It would just be a slower, less secure option with years of cruft and a huge dependency base they don’t control.

Project Treble and Project Mainline where Linux drivers are considered "legacy", and already Rust's adoption even with nightly features, don't really show that.

They are only upstreaming to decrease the development efforts in Linux kernel itself, tomorrow that kernel can be Zirkon instead.

I don’t know I disagree with anything you said other than the end goal.

But yes, I agree, I think getting the Linux kernel out of Android is an obvious next step.

Does Android just become another Fuschia “product” at that point the same way the workstation and a stripped down IoT one are?

I’d argue it goes further than that but my reasoning kind of gets pretty deep into how Fuschia for example handles things like app delivery etc…

I think Android will continue to exist as a supported interop style solution for years but ultimately you will end up seeing a total transition to 100% Fuschia across all Google platforms (server, IoT, Workstations, mobile devices etc).

I would say that the facts speak for me, it is the Project Treble HAL documentation call refers to Linux drivers as "legacy".

https://source.android.com/devices/architecture/hal-types

> "HALs expressed in HAL interface definition language (HIDL) or Android interface definition language (AIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later must support binderized HALs only."

While Linux folks are still arguing if Rust makes sense to be adopted in the kernel and what features still need to be stabilized,

https://source.android.com/setup/build/rust/building-rust-mo...

And as I pointed out in another comment, here are the ART commits supporting Fuchsia,

https://android-review.googlesource.com/q/fuchsia

I should also note that while people pat themselves on the back, because Android uses the Linux kernel, from Google's point of view that is an implementation detail, not supported as public API for NDK code.

https://developer.android.com/ndk/guides/stable_apis

From NDK point of view for app developers, the underlying OS is a generic OS, with ISO C, ISO C++ standard libraries plus a couple of additional stuff. Something that Termux guys have a hard time to swallow.

Wow, that's good to know thank you, you brought a lot of good info.

Reply on news.ycombinator.com