linghengqian commented on issue #2519: URL: https://github.com/apache/shardingsphere-elasticjob/issues/2519#issuecomment-6252414967
- Some numbers that matter for the choice of Flutter here, from https://github.com/version-fox/vfox-plus/issues/11 . In https://github.com/version-fox/vfox-plus , I have now written the same Linux desktop app in nine stacks. They follow one spec and share the translations, icons and test fixtures, and I measured their memory the same way. Flutter was not the lightest. Uno, Gio and Compose Multiplatform all used less, and Uno needed 133 MB on the Home page against 340 MB for Flutter. - The numbers below are PSS in MB for the app and all of its child processes, from https://github.com/version-fox/vfox-plus/blob/2cd73eb5c46dace1762d06ebaf679be015c6e1bb/docs/memory.md . "Home" is the first page after start-up, and "Versions" is a page with 872 versions of Node.js listed. Each row is one run in Docker on Ubuntu 26.04, with Xvfb at 1280x800 and no GPU. Flutter, measured six times, ranged from 332 to 342 MB on the Home page, so a few MB either way means nothing. | Implementation | Technology | Processes | Home | Versions | | --- | --- | ---: | ---: | ---: | | Uno | Uno Platform 6, C# on .NET 10, Skia on the CPU | 1 | 133 | 168 | | Gio | Gio, Go, OpenGL ES through EGL | 1 | 209 | 226 | | Compose | Compose Multiplatform, Kotlin on the JVM, Skia | 1 | 263 | 275 | | Flutter | Flutter 3.47, Dart, Impeller (OpenGL ES), GTK 3 | 2 | 340 | 355 | | Flet | Flet, Python 3.14 in a Flutter application | 2 | 341 | 360 | | Capacitor | Ionic Vue and Capacitor in Electron | 6 | 385 | 398 | | Tauri | Tauri 2, Rust, WebKitGTK 4.1 (GTK 3) | 3 | 397 | 482 | | Dioxus | Dioxus 0.7, Rust, WebKitGTK | 3 | 418 | 497 | | Wails | Wails 3, Go, WebKitGTK 6.0 (GTK 4) | 3 | 480 | 554 | - I don't think these numbers can be carried over to elasticjob-ui as they are. - This issue asks for a web UI in a Docker image and an Android APK, not a Linux desktop app. None of the nine has been built for Android yet, and none has been measured in a browser. - Without a GPU, everything that draws with OpenGL also pays for Mesa's llvmpipe. Uno avoided that by drawing with Skia on the CPU, which saved it about 130 MB, but what that costs in CPU has not been measured yet. Compose ran with a heap of at most 256 MB and the serial GC. On a machine with a GPU the numbers, and maybe the order, will be different. - Memory also matters less here than in vfox-plus. A vfox GUI may stay open in the background all day, which is why Electron was questioned in https://github.com/version-fox/vfox/issues/371 . The ElasticJob console is more likely to be opened to check or change a job and then closed. What runs all the time is the gateway in Docker, and it will most likely stay on the JVM whatever the front end is, since it would reuse ElasticJob's `lifecycle` and `registry-center` modules, as the current backend does with `elasticjob-lite-lifecycle`. - For Android, I wouldn't assume the same order. Compose Multiplatform on Android is Jetpack Compose and runs on ART like any other app, while Flutter brings its own engine and Uno brings the .NET runtime and Skia. Capacitor on Android runs in the system WebView, not in Electron, so its row above says nothing about an APK. Until someone measures an APK on a real phone, this is guesswork. - In the browser, the self-drawn stacks, Flutter included, have a problem that matters for testing. - Flutter, Uno and Compose all draw the whole UI into a canvas there. Flutter dropped its HTML renderer in 2025. Uno 6 uses Skia on WebAssembly by default, and according to the docs on its master branch, Uno 7.0 removes the DOM renderer. Compose for Web, still Beta in 1.12, has always drawn to a canvas. - Playwright can only get at the controls of such a UI through the hidden ARIA tree that the framework keeps next to the canvas for screen readers. Compose has turned that tree on by default since 1.9. Flutter and Uno build it only after a hidden "Enable accessibility" button is pressed, unless the app forces it on, with `SemanticsBinding.instance.ensureSemantics()` in Flutter or `AutoEnableAccessibility` in Uno. Uno's docs say to keep the latter off in production because of its runtime cost, so a test either presses that hidden button first or runs with a setting that users don't have. - That is the other reason I gave in my last comment for starting with TypeScript. With a DOM front end, playwright-cli works on the real elements and nothing has to be switched on for it. - If this issue stays with one self-drawn codebase for the web and Android, the three that came in below Flutter are the ones to compare it with. - Uno used the least memory, and WebAssembly has been one of its targets for years. Gio came second. But C# and Go would each be one more language in a project whose maintainers write Java, as Dart would be. - Compose came in below Flutter too, and Kotlin is the closest to Java of all of them. But its web target is still Beta, and it may not get me out of the IDE problem from my last comment either. IntelliJ IDEA has open WSL issues for Kotlin Multiplatform too, such as https://youtrack.jetbrains.com/issue/KTIJ-21309 , much like the Dart plugin in https://github.com/flutter/dart-intellij-third-party/issues/243 . - Then there is the release build. The current UI builds its Vue front end from Maven with `frontend-maven-plugin`, which downloads Node.js by itself, so a TypeScript web UI would fit into the release as it is. Compose Multiplatform would bring Gradle into the build, and Flutter and Uno would bring their own SDKs, which anyone building a source release would have to install. The APK needs the Android SDK whichever stack we pick. - On licenses, the notes at the end of https://github.com/version-fox/vfox-plus/issues/11 read differently under ASF policy. In https://www.apache.org/legal/resolved.html , MPL-2.0 (`option-ext`, which Tauri and Dioxus ship through `wry`) is Category B and can go into convenience binaries with a label. LGPL (Chromium's `libffmpeg.so` in Electron) is Category X and can't be in a source release or a convenience binary. That doesn't block a web bundle or an APK, but it would rule out Electron if anyone asks for a desktop package later. - So I don't think memory should decide this on its own. What I'd like opinions on is which matters more for elasticjob-ui: one self-drawn codebase for the web and Android, or a web UI that Playwright can test directly, which points back to TypeScript, with something like Capacitor for the APK later. If anyone has shipped Compose for Web or Uno's WebAssembly target, I'd like to hear how it went. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
