I'm doing a small survey, what would you like to s...

# nucleus

[אליהו הדס]

I'm doing a small survey, what would you like to see in Nucleus? I'm preparing Nucleus 2.6 and I'm not entirely sure what to focus on yet. Up until now, I've really prioritized native compilation via GraalVM. With Nucleus 2.6, I'd like to refocus on the JVM. I think an out-of-the-box JVM is much more optimized for servers than for a desktop app, and that we should provide predefined heap settings (via an opt-in), maybe even activate GC when the window loses focus, when it's minimized, or even when the system goes idle. I also thought about Windows, using the NSIS format to generate the AOT cache directly in the installer to reduce the binary size and allow for creating an AOT cache entirely optimized for that machine rather than a generic AOT code like currently. Maybe even exploring cross-compilation, which is very feasible if we target the JVM, even if the notarization will still have to be done from a Mac. We might also need to optimize ProGuard because currently it requires a lot of manual work, or finally, it's not that different from what exists for native image; I think there's a way to make the JVM target benefit from it automatically. On Linux, with the deb and rpm formats, I think it could be interesting to use the system JVM, since the package manager allows linking the application to a package very simply. This would allow for providing a smaller app (around 20mb even if the package manager downloads Java, I think it provides a better user experience). Anyway, I have a lot of ideas in mind, not necessarily much time, I'd like to know what you think.

[Michael Paus]

First of all I'd like to say that this is one of the greatest projects in the Compose ecosystem for desktop applications. My personal favorite feature is the auto-update which closes one of the biggest arguments in favor of web technologies instead of real desktop applications.

You were asking for new feature requests but I have to admit that I do not really have a clear favorite there. The ones you have named already are certainly useful but none of these features really excites me. The last one which did excite me was the maplibre-compose integration which also closed a big gap for me.

At the moment, I think, it is most important to stabilize and polish what already exists and further promote the development of real desktop application. With the help of Claude I recently conducted a little study to find out where I could possibly replace real desktop applications by PWAs via Compose wasmJs. That's an interesting technology too, however, as this study progressed, the tide turned, and it became clear that true desktop applications are still indispensable in many areas given you have an auto-update feature and can self-host the installers.

[אליהו הדס]

I went from 5s cold boot on a JVM on Windows to 1.5s, I doubt that won't interest you hehe 🙃

[אליהו הדס]

but yes, I am not at all convinced by Compose Web either, in fact Flutter has been trying for almost 10 years now, and it doesn't work, and yet the render is much more optimized and there are many more developers, I don't really understand Jetbrains, a Flutter web app is 1.5mb, it's more performant, there is accessibility, and yet nobody wants it, who would want Compose Web

[Michael Paus]

From 5 to 1.5 is certainly great but on my Mac I don't feel that pain so much 😇. I still don't understand why Windows is so bad at this. My concerns about the web technologies are not so much about Compose or WASM. The main problems are the inherent limitations of the web platform itself. The Compose GUI is great, with a few exceptions, but I simply can't replace real desktop application due to the platform limitations.

[אליהו הדס]

I realized that the problem was caused by Windows Defender; the structure of a current JVM app built with jpackage was the worst imaginable for Windows Defender. A simple app could have 100 jars, each being reanalyzed every time the system restarts—it's a catastrophe. It's necessary to package everything into a single jar, so the analysis is much faster.

[אליהו הדס]

and even if an app is signed, Defender also relies on reputation, both are necessary. and even without that, it remains much faster to load a single jar than 100 at the access disk level

[אליהו הדס]

everything will be opt-in, but I also created a profile for an app that uses on average 80mb less RAM than a current app, with better memory management. In short, it's an optimized desktop JVM profile. But I won't activate it by default; everything will be opt-in with a simple setting to activate it, but those who don't read the documentation won't benefit.

[אליהו הדס]

The gap between a JVM app and a native app is becoming almost insignificant for most apps thanks to this, I find that very interesting.

[אליהו הדס]

concretely the app nucleus demo on the animated atom starts at 200mb currently and will continue to rise until it reaches 500-530mb, the app with the optimized profile will start at 120mb and stabilize at 125. and once again these are not memory leaks, it's just the jvm that doesn't see the point in compressing since it has plenty of available ram

[אליהו הדס]

the native image starts at 80mb and stabilizes at 85, so yes the difference is really insignificant when talking about a desktop application, in a world where an app that does nothing tends to use 500mb of RAM

[Arthur]

androidx.compose.ui.window.v2.rememberWindowState

from the compose 1.12

blog.jetbrains.com/kotlin/2026/08/compose-multiplatform-1-12-0#…

[אליהו הדס]

github.com/NucleusFramework/Nucleus/pull/634

[Arthur]

ah my bad, was still trying to start this nucleus stuff hoping it works on my project

[אליהו הדס]

the new api is very closely linked to awt, so it's a lot of work, and knowing that it's only experimental, I'm not even sure if it's really worth it, given how fast compose is advancing, it might stay experimental for another 3 years