Hacker News Reader

Comment by rjzzleep | Hacker News Reader

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.

View on HN

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

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.

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.

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

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.

Reply on news.ycombinator.com