Hi folks! I’m a Flutter developer but now I’m in m...

# multiplatform

[Oscar Rodriguez Co]

Hi folks! I’m a Flutter developer but now I’m in my learning stage with KMP, but I have a question about the performance of Compose Multiplatform that uses Skia as UI engine versus Flutter that uses Impeller as UI engine. If Flutter changed from Skia to Impeller for performance reasons, what is being done differently so that Compose Multiplatform with Skia can compete with Flutter with Impeller?
When Compose Multiplatform is ready for production, why use Compose Multiplatform instead of Flutter knowing that Impeller has many improvements that Skia doesn’t have?

[jw]

I'm not sure your questions are phrased in a way that I would expect a straightforward answer...

You presuppose that Impeller is a wholesale improvement over Skia for all usage patterns rather than being tailored for how Flutter was already using Skia. It's not clear that all usages of Skia are better served by migrating to Impeller. Since both Skia and Impeller are maintained by Google, I would expect to see the Android OS and Chrome app to migrate first.

knowing that Impeller has many improvements that Skia doesn’t have

Again, Impeller was purpose-built for Flutter's usage patterns. While it's a general-purpose library, that doesn't mean everything built on Skia has usage patterns which are problematic such that Impeller would improve them a meaningful amount.

why use Compose Multiplatform instead of Flutter

Google has 3 large-scale platforms. Largest is Chrome. Second largest is Android. Third largest is Flutter.

If you're choosing something to build on I would first select the native web which runs absolutely everywhere, although suffers due to Google and Apple's comspiracy to force it to be a second-class citizen on their mobile operating systems. After that I would recommend native apps which means Compose UI and Swift UI, and if you don't want to build twice then leveraging Compose UI on iOS at least gives you half the native experience.

Flutter is always the worst option. Instead of a general-purpose language, it's written in a bespoke language that both server developers and web developers rejected so the ecosystem is narrow. It rejects native rendering on every platform, creating an uncanny valley experience on all platforms as well as always chasing native UI toolkit capabilities (especially around oft-overlooked things like accessibility). Even the web still uses native UI toolkit elements where it can, but the web comes with the superpower of its apps being live hosted whereas Flutter apps still need to be downloaded and installed.

Flutter is a selfish choice for a developer. They want its best-in-class developer experience at the expense of its output integrating natively with the ecosystems on which it deploys and the user experience that comes from the native UI toolkit.

It exists as a manifestation of the cultural dumpster fire that is Google, where they control the two largest developer platforms in the history of the human civilization and instead of working to improve those or to blur the lines between them so the advantages of native apps comes to the web and/or the advantages of the web come to native apps they choose the cancerous third option of spending billions to build a weird third platform.

[jw]

I also don't really think Compose Multiplatform is generally the best choice either. What it and Flutter do to work on the web is a pretty bad experience.

[Oscar Rodriguez Co]

Thank you for your detailed and insightful comment. I appreciate you taking the time to share your perspective on Impeller, Skia, Flutter, and Compose Multiplatform. Your points about the specific use cases for Impeller and the broader context of Google’s platforms are very well-articulated

[jw]

If it is a wholesale improvement over Skia, then I do hope it comes to Android and Chrome. However, Android's Canvas is basically a 1:1 mapping of the Skia Canvas, so not sure if that affects anything.

Skia also has multiple backends (I think one is called Ganesh and I forget the other) so it's possible that could bring much-needed performance improvements to how Skia's high-level API interacts with the low-level platform graphics API without requiring switching to a completely different library.

[jw]

In general, Compose multiplatform is one company (JetBrains) taking something built by another company (Google) and making it work on more platforms than it originally was meant for. It's not that Google didn't mean for it to run on more than Android when it was built, but pulling off an entire new UI toolkit for Android was hard enough. I don't think they actually had the capability to pull it off as a first-party fully multiplatform solution.

[jw]

As app developers it's tempting to compare Flutter, Compose multiplatform, separate native apps, and the web. But they're like trains, planes, cars, and boats. Yes, they all move people to different places. But just because you swapped your internal-combustion engine for an electric one in a car doesn't mean an airplane should switch its jet engines. You have to start a lot of comparisons sentences with "Well" "But" and "Although". These separate platforms exist because of their different technology choices, not in spite of them.

[jw]

Graphite is the new Skia backend. Ganesh is the old/current one. And looks like it's based on discoveries from the Impeller project: https://youtrack.jetbrains.com/issue/SKIKO-982

[jw]

https://groups.google.com/g/skia-discuss/c/Fzpne-f9gZ4/m/5_IMDMUcAAAJ has

Interestingly, the startup performance problems Impeller sought to solve are also addressed in our new GPU architecture, Graphite. Android and Chrome continue to ship Skia!

[jw]

I think that's a pretty direct answer to your original question!

[Anonymike]

@jw Fantastic responses and I really appreciate seeing that kind of pragmatism. Just throwing it out there so its known because thoughtful perspective like this is missing from conversations far too often these days.

[andylamax]

Must be an amazing experience working with Jake