Apps made with Google's Flutter may fritter away CPU cycles. Here's what the web giant intends to do about it

Google's Flutter cross-platform app framework appears to have a thinking problem: in certain situations, Flutter desktop apps consume too much processing power. How much is too much? Try an extra six to ten per cent CPU usage just to recreate the blink of a cursor in the style of a native macOS app. That's an improvement over …

[big_D]

#!$%#&!

It is this sort of thing that really gets on my goat. Let's not try and integrate existing controls that are optimally written to be efficient on the native platform, it is time to re-invent the wheel, but we will coat it in tar instead of grease, so that it clogs up the works!

With power prices currently going through the roof, it will become more and more important that applications are well written and economical with their processing load.

Electricity prices have skyrocketed, in the last 3 - 4 months they have increased over 30% and are now in 36-38c/kWh.

By all means, write an object-wrapper around the native textbox, to use the example in the article. But completely re-writing a near zero-impact object in a way that just burns through the processor and memory? You've got to be kidding, right? Right?

And I thought Electron should be burnt in the pits of Hell...

[Aitor 1]

Cheap maintenance

By not using the available frameworks they save themselves from expensive maintenance tasks.. as apple would keep changing the goalposts.

While the result is a disaster, I do understand why they are doing it.. and it reminds me of the terrible java GUI options.

[Anonymous Coward]

Re: Cheap maintenance

No frameworks merely move the venue of the goal posts, they still have to be maintained and it can be as expensive if not more expensive especially if you have to work around a bug the framework developer won't fix.

More frameworks, more libraries, more places for bugs to hide more obfuscated debugging.

[devin3782]

This is completely unacceptable a waste of storage, electricity and the developers brain power/time.

I do like the irony here though, Google caused this problem in the first place with the sheer number of times they bugger about with their OS libraries and UI toolkits so someone thought lets create a framework rather than simply telling the android dev team to stop breaking backwards compatibility.

My mind is unable to conceive the stupidity of their thinking here not to mention the resource waste, surely prevent backward compatibility breakage is cheaper right?

I also notice React JS in that list on flutters website, that's the biggest waste of CPU cycles I've seen yet as it effectively doubles the workload.

[J27]

Yeah, React JS isn't about performance. It's about making it easier for the programmer. I fully acknowledge it, but I still use React JS otherwise we wouldn't be able to produce the fancy UIs the stakeholders want in the required time frame.

That's just how it is today. It's similar to the reason that almost no one writes programs in assembly anymore. But if you can figure out how to get users to care about how much CPU web applications use I'm open to it, that would create a bunch more programming jobs making my skills even more valuable.

[Bachelorette]

> It is this sort of thing that really gets on my goat. Let's not try and integrate existing controls that are optimally written to be efficient on the native platform, it is time to re-invent the wheel, but we will coat it in tar instead of grease, so that it clogs up the works!

Can also be said of all games. Why does every game have to have a different looking text box and different looking submit buttons? Why can't they adopt the OS look and feel?

[Greybearded old scrote]

This is why we can't have nice things

Computers are insanely fast. Even a Raspberry Pi 3 is 66 Cray 1s, in the talk I've just linked to. Where is it all going?

The bigger stuff, playing HD videos, editing my photos and such, they are much faster than my older computers. Great.

The day to day things, even typing into a messaging program, they just keep me waiting more and more. I don't think it's me getting less tolerant. After all, at my age time is passing faster than ever. (The future isn't ahead, it's down. Thats' why we accelerate towards it.) Us lazy with a capital F programmers are throwing it away.

Shame on us all.

[devin3782]

Re: This is why we can't have nice things

Compiling telemetry, that's where its all going.

[Anonymous Coward]

Re: This is why we can't have nice things

Telemetry, which is done for the same reason as things like flutter. Bean counters and lazy managers.

Don't want to maintain different ui layers for different systems, don't want to do design work up front so rely on telemetry to see how the mess they've barfed up is being use and tweak for the majority.

Companies just don't care about a good quality product anymore.

[ecofeco]

Re: This is why we can't have nice things

Shitty code is drowning us all.

[Abominator]

Re: This is why we can't have nice things

Badly written fat frameworks.

Flutter, Electron, Web UI's its all the same shit running on an operating system in an operating system e.g. Chrome browser is effectively an OS with a hard link back to Google.

Just look at Teams, Skype for Business, Lync and MSN messenger.

MSN messenger worked, was fast, consumed n in ~10MB of memory.

Over the years on faster, more powerful hardware they all consume more resources and in fact run much slower. Teams uses 100x more resources with a +1GB memory footprint with some chats open.

I am pretty much disgusted by modern UI frameworks.

Pretty much the only firm with a commitment to efficiency because of its drive to make things thinner, lighter while extending battery life is Apple. Jobs famously banned Flash from being able to run on iPad's so they did not drain the battery as the Adobe framework was a dreadful resource hog/waste.

It seems nothing has been learned.

[Lomax]

Re: This is why we can't have nice things

> MSN messenger worked, was fast, consumed n in ~10MB of memory.

So did Pidgin, my favourite messaging app. Sadly I cannot use it anymore; today I exclusively use Matrix / Element for voice/video/chat and am forced to use their shitty Electron "web app", which suffers from all the problems you mention (and more!). It's also a full screen app for some reason, while Pidgin managed to do all the same things (and better!) in a ~300px wide window - using only a tiny fraction of the system resources consumed by Element.

[Ian Johnston]

Re: This is why we can't have nice things

Computers are insanely fast. Even a Raspberry Pi 3 is 66 Cray 1s, in the talk I've just linked to. Where is it all going?

I'm writing this on my desktop computer, an old Lenovo ThinkCentre. It takes about 15 seconds to boot Linux, in which time its modest CPU is capable of doing 84,000,000,000 and its SSD is capable of transferring 8GB. So what combination of 84,000,000,000 things done and 8GB transferred is needed to get it running?

[Lomax]

Re: This is why we can't have nice things

You probably have several things happening, such as waiting for an IP address, searching & mounting drives, intialising hardware, polling for keyboard interrupt - these are not CPU bound tasks.

[Doctor Syntax]

"Flutter may fritter away CPU cycles"

I don't think it's alone in this.

[Warm Braw]

What about the claimed "Native Performance", then?

According to the blurb, you get "Native Performance":

Flutter’s widgets incorporate all critical platform differences such as scrolling, navigation, icons and fonts, and your Flutter code is compiled to native ARM machine code using Dart's native compilers.

My personal view is that cross-platform UI frameworks are mostly misconceived. For a start, you (by which I mean I) typically want a very different type of interface on a desktop even than on a tablet and a very different interface on a mobile phone. The "one size fits all" approach leads to the vacuous "SPA" experience where you have a meaningless bunch of stock graphics that probably scrolled very nicely on the i7 on the office LAN beneath which are a couple of buttons of indistinguishable function. By comparison, the differences in fonts and cursor-flashing are insignificant. And of course, you're always going to need an accessible alternative to the visual UI anyway.

What I think is actually needed is some tooling to assist in the creation and maintenance of diverse user interfaces which, among other things, would keep an inventory of UI data, its mapping to UI elements in different UI styles, flag up things that might be overlooked and exploit commonalities but ultimately facilitate the creation of native UI designs for the supported platforms. And, apart from anything else, you'd still have the native code to fall back on if the tooling provider decided to abandon their project. Which I gather occasionally happens.

[_LC_]

Re: What about the claimed "Native Performance", then?

It's almost like they're selling things. *rust* *rust* (Germish joke)

[heyrick]

Re: What about the claimed "Native Performance", then?

It is native. It's just not particularly good or optimised for the platform in question. But it's compiled into real actual native code that runs natively.

(it's the coding equivalent of mucking with the axes of a graph to make their product look twice as good as the competition)

[Anonymous Coward]

Re: What about the claimed "Native Performance", then?

I think you're slightly missing the point of cross platform frameworks.

Cross platform frameworks bring a consistent API to all devices, so regardless of the visual appearances of your UI across different platforms the underlying event handling and layout code is the same which should (if you're a competent team) reduce the resources required to maintain that part of your application.

While it's tempting to design a cross platform UI for everything, that's not really the point. *Some* UIs can be designed in a way that is consistent and in a way that makes sense across a wide variety of platforms and form factors, but a lot can't. That said though, it should be possible to at least build semi-complex components and modules which can be reused across devices and with a single framework to interface with that becomes a lot easier.

[Decani]

Snip "In Flutter the cursor is a timer and for each frame we need to composite and paint the layer tree to the surface." WTF? A blinking cursor doesn't change any layout dimensions, so the dirty region is the tiny bounds of the cursor. Even ancient Java Swing would just repaint the minimum of pixels. Why have they not learned this simple lesson? Dumb arse programmers.

[ThomH]

From the little that I think I know, Flutter is built around a presumption of immutable views and complete subtree recompositions. Like functional programming, but only the bad parts, and presumably implemented by somebody with a background in video games.

Users and efficiency be damned.

[Anonymous Coward]

Same as SwiftUI, works ok for small things with occasional updates in the data, but try and do anything beyond showing a weather forecast it all falls apart.

[iron]

Programmers at Google ignore the past rather than learning from and building on it. Hence the 6 billion messenger apps that they have writen, each slightly less useful than the one that come before it.

[Anonymous Coward]

Former employee here. The propaganda that Google hires only the brightest and best begins on day one, and sadly most of the workforce is just-graduated Americans so they believe it.

Since it’s axiomatic that anything a Google employee will create is going to be the best possible version of that thing, why even waste time doing things like reading the literature, looking at competitor’s products, etc?

[Bachelorette]

Except Flutter's lead dev was Hickson. Yes, the legendary Hickson. The one who writes all the specs for HTML5 and worked at Netscape and Opera.

[Anonymous Coward]

Not quite. For example, what happens if the caret is (partially) under a window which blurs objects behind it?

Yes, less than the entire screen should be redrawn, but exactly how much or how little is dependent on other factors beyond the mere shape and size of the caret.

[Steve Davies 3]

Fluttering away CPU cycles?

Nah. That's all the telemetry telling the Google Mothership everything about you, your device and everyone you know.

Simple really.

Once upon a time, developers slaved for hours to make their code more efficient, use less ram, etc etc.

These days, they just add more spyware frameworks and walk away with Loadsamoney.

[Anonymous Coward]

I remember writing such a crummy framework with a Flutter-like design for fun back in 1990. It was impressive for the day (though I say so myself), but then anything that wasn't text was impressive in those days...

[Anonymous Coward]

Ah, another cross-platform framework.

Brilliant. Just what we need. Making every platform look just like Java Swing.

Well done Google.

Now we need a cross-framework platform and the circle will be properly squared.

[Bachelorette]

Re: Ah, another cross-platform framework.

Swing was ahead of it's time but the major drawback with Swing was you needed to download Java separately at a time when people were still on dialup and the JIT engine ran on computers much slower than today.

Flutter compiles to native code and the libraries are much smaller than Java since Flutter doesn't try to handle every scenario like the kitchen sink.

[Anonymous Coward]

Quelle surprise

Another less than performant JIT execution engine based language not living up to the predictions.... Colour me shocked I say.

[Bachelorette]

Re: Quelle surprise

Flutter is compiled to native code, not JIT. It's just that it doesn't use Mac components to create the UI, but uses it's own painter to draw things that resemble Mac components. That way the same codebase works on Android too which was the point all along. To turn iOS developers into Android developers.

[Anonymous Coward]

I used flutter for a year and switched to gioui .

GIOUI , https://github.com/gioui/gio-example

Also open source.

Also compiles to web, desktop and mobile.

I find gio much higher perf and much easier to use and extend

[Anonymous Coward]

Cross-Platform GUI for Go

Yeah, no thanks.

[Abominator]

Flutter, AMP and the rest. They are all attempts at land grabs by Google to suck your application or website traffic through your servers.

Simple. Never ever be stupid enough to use Google 'technology'. Its not there from the goodness of their hearts, but rather to enrich their advertising businesses. Everything they do is about improving their ad revenue.

[Fruit and Nutcase]

Skia/Iska

"...Kaushik Iska, senior software engineer at Google, said Flutter was working as expected"

Well he would, wouldn't he? *

Skia/Iska - Are they by any chance related?

* Mandy Rice-Davies

[Fred Daggy]

Oh, no it is not!

"For desktop apps, particularly on plugged-in devices, excessive resource consumption is often tolerated as a trade-off for developer/user convenience"

Oh, no it is NOT! Exhibit A : Windows 11. versus, say, Windows 2000.

When your POS Operating System or framework makes the fans spin faster than those on a Concorde, out it goes. Natrually, some tasks might actually tax a processor or disk access. Compilation, for example. Bitcoin mining, if that's your think. Blinking cursor - no way.

Betas: Ok, it's in development. But never, ever production ready code.

[David 132]

Re: Oh, no it is not!

Betas: Ok, it's in development.

Yeah, but you have to remember the Google product lifecycle.

It goes:

Alpha—>Beta—>Cancelled

[khjohansen]

Re: Oh, no it is not!

... I believe you've just reverse-engineered their corp. name ...!!

[DWRandolph]

"working as intended" Code for this is shite, but upper managlement has already told the shareholders what a bright new shiny they have to play with.