https://kotlinlang.org logo
Join Slack
Powered by
Almost every day, I check these two repositories i...
# compose-desktop
m
Almost every day, I check these two repositories in the hope of finally seeing AWT gone. That would mean faster startup times, lower RAM usage, and better support for modern OS-integrated features like window management, notification, dock and etc. There are many great helpers like (Jewel) but still bielieve the infrastructure for modern desktop apps with Kotlin is not yet ready. Wish i could help to push it a bit, Or i just completely lost my mind and the desktop solution is gonna dead and that's why Kotlin multiplatform focus on ios more than desktop 1- (Kotlin Desktop Toolkit)[github.com/JetBrains/kotlin-desktop-toolkit] 2- (Nucleus 2.0)[github.com/NucleusFramework/Nucleus]
๐Ÿ’ฏ 1
k
We had the same discussion topics internally
faster startup times
not related to AWT. AWT is a quite lightweight library
lower RAM usage
as well. most of the real problems usually in the project or the jvm runtime
OS-integrated features
how non-AWT helps here? we know many other small things here and there and we work on them
m
You are not alone. I also believe in desktop apps if they are done right. I already use several features of Nucleus 1.x in my own apps and I am hoping to be able to switch to 2.x soon. When I look at the things which are in the various pipelines, I think the desktop app could see a renaissance.
๐Ÿ’ฏ 4
m
I don't have a problem with AWT. My point was that the Compose Desktop backend is quite old and doesn't fully meet modern requirements. For many features that other multiplatform frameworks enable with just a few configuration flags, we instead have to write custom native code and hope it doesn't break when the application is shipped to users' machines. I recently realized that, because RAM prices have increased significantly, more people are buying older computers or new machines with the minimum amount of RAM. That makes efficient desktop applications even more important.
m
@Konstantin Tskhovrebov One of the hot topics discussed in several places here is replacing AWT by some alternative window managing. The prototypes show much better performance and other advantages. Do you call that "small things" to do?
m
It's not just about performance. It's also about developer experience and UX. I remember when Android apps looked outdated. Material Design 2 and 3 made them feel much more polished and consistent.
Jetbrains Toolbox app is a tray app that uses 500MB of my computer RAM. I guess nobody here is more professional at optimization than JetBrains with more than two decades of experience. So i guess the problem is not about the project itself. They write great codes I sure.
k
The prototypes show much better performance and other advantages.
this is OK for prototypes. I don't say we absolutely against other window managers. But when we seriously check AWT problems written here, it happens there are no AWT specific problems. My cold compose desktop app launches faster than 1 sec to the first frame. Everything else - depends on the UI and other app related things. Resizing issue - WIP. RAM footprint - typical for any jvm UI desktop app. Proguard/AOT/Graal - ways for further improvements. So, we need real problems to investigate. If you know them, please, file issues with a description P.S.: I do want to have a good desktop UI framework. And I read complains here and verify them locally, and share them in the team. But for now we have only rumors and historical distrust of AWT
๐Ÿ™๐Ÿผ 1
โž• 1
m
@Konstantin Tskhovrebov On which OS/hardware are you doing your investigations? My apps on macOS are generally also in the league <1s start-up time and so I also previously didn't understand the complaints of others. I just had to learn it the hard way that the same app launches much slower on Windows or Linux machines. At least that's what people/customers are telling me. I cannot really give precise numbers on this because I don't own a comparable machine. You have already mentioned the resizing issues. They are real and annoying.
u
@Konstantin Tskhovrebov
> faster startup times
not related to AWT. AWT is a quite lightweight library
https://kotlinlang.slack.com/archives/C01D6HTPATV/p1777613786032409
@Max Nucleus 2.0 should be released before July 14th ๐Ÿ™‚
๐ŸŽ‰ 5
๐Ÿš€ 4
k
@Alexander Maryanovsky
a
Try an empty โ€œHello Worldโ€ app and see how fast it starts up. Java without AWT is almost instantaneous, but AWT is like 250ms on modern hardware.
u
@Konstantin Tskhovrebov
My cold compose desktop app launches faster than 1 sec to the first frame.
You are probably using macOS, a fairly recent Mac. macOS handles JIT very well, Linux even better. However, the problem is Windowsโ€”it's a disaster, and I'm not joking. On the exact same machine (mine), which is a beast, IntelliJ takes one second on Linux and 10-15 seconds on Windows. Windows handles JIT very, very poorly. Leyden helps a bit, but it's still slow
a
JVM on Windows has a bug where it looks fir classfiles in the wrong place
Even under AppCDS
(haven't checked AOT yet)
and the failing file-opens take a ton of time
u
I really worked very hard to support GraalVM Native Image, and it's truly worth it. My users, without exception, all noticed the differenceโ€”from 20 seconds down to 1 second. I've received dozens of testimonials like that.
a
I've no idea what you could be doing on startup that takes 20 seconds ๐Ÿ˜ I'm talking about reductions from slightly over 1 second to around 500ms
m
I am using a MacBook Pro 2019[Intel], I don't know how fast are the Compose Desktop apps on newer Macs but on intel machines it's only a bit faster than windows. But about Windows, yes I agree with you about startup time. @ืืœื™ื”ื• ื”ื“ืก
u
Well, me neither, and on macOS, nobody noticed anything because my app has always taken less than 1 second to start.
a
2019 Intel Macs are unfortunately not a target we're likely to spend many resources on
I'll hopefully land AOT in 1.13
kodee happy 2
u
I really think there is a problem with AWT on Windows. I haven't measured it precisely, but even within a JVM, I definitely noticed a drastic reduction in startup time without AWT. I decided to make the transition because not a week went by without me receiving user requests to support touchscreens; I never decided to make the transition for performance reasons.
a
u
About a month ago, I decided to transition my 10k users to Nucleus 2.0 alpha with my new Tao-based backend, and aside from a few issues at the beginning, today I have complete silence; it's been 3 weeks since I've received anything :)
a
Maybe theyโ€™re all dead
๐Ÿ˜‚ 7
m
@Alexander Maryanovsky I guess this statement is missing a smiley at the end ๐Ÿ˜‰.
a
It was implied
m
I appreciate all the people here contributing for a better backend for compose desktop apps ๐Ÿค๐Ÿผ
๐Ÿ™Œ 1
s
fwiw I am excited at KDT โ€” they recently shipped Windows support, but Linux is still not there. But you can see it in action with JetBrains Air if you want. The startup speed, however, I don't think is fair to attribute to AWT. AWT will eat a few hundred milliseconds, but to be honest, if you open any electron-and-general-web-stack app out there, it'll take at best 5-6 seconds to launch, often over 10. Try VSC, try Claude desktop, try Codex
u
air work on linux
m
@seb I am working with Claude desktop right at the moment. And the cold-start performance is in the 1 sec class on my macBook M4. So all the statements about startup-times very much depend on the machine and OS you are using.
s
On my M1 it takes 4-5 seconds to start and another couple to be responsive ๐Ÿ˜
@ืืœื™ื”ื• ื”ื“ืก no, they just launched Windows, Linux still not supported
u
Yes, I installed it.
Personally, I find that an Electron app opens much faster than a Compose app; Chrome itself is very fast to start
s
Huh I spoke with people from the air team yesterday and I misunderstood what they said clearly
Chrome is fast but it's faster than electron
u
I'm currently working on Windows, so I can't show you, but I assure you I installed it from JetBrains Toolbox.
m
Another example for an Electron app is GitHub Desktop and it also starts up in 1s or so. Modern macs seem to be the exception to the rule. They are actually too good for developers because you realize performance problems only when they are already a pain for others ๐Ÿ˜‰.
u
Slack also starts up very quickly under Windows, although I feel they've made very significant optimization efforts.
k
๐Ÿ˜‰ ๐Ÿ˜†
u
I almost fainted! I don't feel well ๐Ÿฅด
In addition to depriving us of the Java ecosystem, you want to give us the JavaScript ecosystem ๐Ÿ˜‚
๐Ÿ˜† 1
a
Our team is actively working on a massive overhaul to fix window resizing behavior
โ€œOur teamโ€ hehe
๐Ÿ˜‚ 3
Well, I guess Claude and I are a team of sorts ๐Ÿ™‚
s
Sasha you're a whole team eheh
๐Ÿš€ 1
a
The A-Team
๐Ÿ˜‚ 2
m
It's been more than two years since reporting this issue and unfortunately it's not fixed yet, a javascript web or electron app have lower latency in such cases, and we can't build something like tldraw for example with Compose or any other kind of apps that requires that level of low latency. I hope this gets a higher priority. F06UJP03S6B
Screen Recording 2024-04-18 at 4.29.50 PM.mov
a
This is just vsync
Disabling it gets you to near-perfect sync with the pointer
If you look at it frame-by-frame, you can see the drawing lag exactly one frame behind the pointer.
m
Yes but disabling vsync cause other problems like flickering especially during scroll, it's enabled by default for a reason right?
a
Iโ€™m not actually sure what problems disabling it causes (other than unnecessary draws during animation)
You can have tearing, I guess
u
I also disabled V-Sync during resizing, but I limited it to the screen's maximum FPS to avoid unnecessarily calculating hundreds of frames.
a
Other than that, maybe the problems are fixable
m
I saw that recently there are changes in cmp aligning with Android's model and I remember Igor said that Android Choreographer solves both the latency and animation issue, shouldn't those recent changes help fixing the latency?
a
Unlikely. These changes shouldnโ€™t change anything behaviorally (yet)
๐Ÿซ  1
a
looking forward to the window resizing fixes, that looks really slick. I was comparing my app to a flutter apps resizing recently and getting jealous ๐Ÿ˜
on the K/N topic, I know the arguments for JVM, that ecosystem, modern jit is great, etc, but MAN for certain apps, I would love to just be able to ship a simple exe, click and run. not a package of stuff
u
Nucleus supports the portable format for Windows, AppImage for Linux, and for Mac, this problem doesn't exist. So, apart from a few extra MBs, I still don't see the point of KN.
If your goal is an ultra-lightweight appโ€”like, if you really care about distributing a 5โ€“10MB appโ€”I'd recommend going with Compose Web + PWA. I think that's the ideal use case for Compose Web
progressier.com/what-web-can-do-today When you see everything a PWA is capable of doing today with a simple, unified API that works everywhere, I don't really see the point of using Kotlin/Native. It's just a hassle for not much return. With Compose Web, you can build a real appโ€”no code signing, no app stores, automatic updates. Plus, you get support for the Kotlin/JS and WASM ecosystem, which is way larger than Kotlin/Native. Because honestly, outside of iOS, Kotlin/Native simply doesn't exist
s
Tend to agree although at this point I'd just go typescript to save myself some of the pain. The web is the most portable way to distribute things for sure
u
I get what you're saying about TS, but I don't entirely agree. It's simpler when you know the ecosystem, but if you love Compose and Kotlin, you don't necessarily want to learn another language or framework just to build a web app. Plus, TS isn't exactly amazing either
Desktop apps nowadays only make sense if you have a real need for the machine's power. Personally, my app uses a local Lucene index and vector search with an embedding model via ONNX Runtime. I've spent hours in front of the profiler optimizing my app so that it properly utilizes all CPU cores. I actively use plenty of native APIs that are completely inaccessible from the web, and I maximize the window's real estate using decorated windowsโ€”along with plenty of other things that would be completely insane to try in a browser. Browsers are just too limited API-wise: no way to draw directly in the window chrome, and only a single thread. I also use ZSTD compression. Anyway, I don't have everything off the top of my head, but I'm really pushing the Java ecosystem to its absolute limits; doing this without it would have been a nightmare. But if it's just to consume JSONs and display lists, there's zero interest in distributing a desktop app
s
I'm just saying especially if you're vibe coding or you're not experienced with the ecosystem it's a lot easier to whip up a website/pwa in typescript
And I agree that not everything needs a native app (desktop even more than mobile), if you have a good website. Web is just easier to do than native: the stack is mature, the tooling is excellent, and you have many freedoms (and footguns) that native apps don't necessarily allow
๐Ÿ’ฏ 1
u
Yeah, I agree that if you're starting from the premise that you won't even reread the code, go with React. AIs churn out React all day long, so they'll be way better at that. But honestly, outside of showcase websites, I wouldn't really trust vibe coding transactions.
s
Oh yeah well I am assuming any software I touch these days is at least partially AI coded. Maybe not full vibe coded, but I know firsthand how the code review culture can be very lax in some teams and thus it's not so far from vibe coding XD
๐Ÿ™ƒ 1
Luckily regulated institutions are forced to do it the right way at least in theory
But rubber-stamping code reviews is a real issue
u
Personally, I think the marketing pitch for new AI models is going to be fixing the mess created by the current ones ๐Ÿคฃ
s
And even if not rubber stamping, the biggest limitation of code reviews is how good the reviewers are: how well they know the problem space, and the technology. How good they are at mentally running and linting the code. And at doing good reviews
@ืืœื™ื”ื• ื”ื“ืก wasn't that the pitch all along lol
๐Ÿ˜ 1
"GPT-5.6 is so much better at coding than 5.5 it can now fix 5.5's shit code" lol
๐Ÿ˜‚ 1
u
There are two scenarios: either the new models fix the mess made by the old ones, or we hit a ceiling. If we hit a ceiling, well, it's going to be a disaster, but the demand for seniors will skyrocket. So, I don't know, maybe the JetBrains Academy should sell courses on how to fix AI-generated code ๐Ÿ˜‚
On the other hand, I'm not sure the job is really going to be any fun then. ๐Ÿ˜ฌ
s
For shit and giggles I asked GPT-5.6 to scope out what it would take to support Tao and/or KDT as first class citizens and there are several gaps compared to what Jewel already supports in AWT. All the rows in the table are things we would lose by moving away from AWT, or would be (severely) degraded. Note that I am not saying we will never support other window managers, or that AWT is perfect, or that other WMs are not good, or making any precise comments about the state of any project/stack. This is a fully automated analysis from an agent looking at a few codebases and comparing. Just want to get across the point that there is no easy win here to be had, even if (and currently we are not) we decided to support other WMs
u
I hope we still have the right to disagree with an AI agent: in this case, there might be a confusion, but the TAO backend is backward-compatible with AWT as long as it doesn't depend on rendering the window via AWTโ€”for example, the clipboard manager. As for the filepicker, I see absolutely no point in implementing it myself; I just made sure that the famous FileKit library from @Vincent works perfectly, and itโ€™s already excellent, I couldn't do any better. Regarding the native tray, here I beg to differ completely: Compose Native Tray is without a doubt the deepest and most perfect system tray integration across all frameworks. Granted, it will keep its own separate repository, just like Compose Media Player or Compose PDF Reader, but it will be part of Nucleus, thus with guaranteed compatibility.
kodee loving 1
s
Yeah this is only an excerpt of a much longer document where it does say that there is a compat layer (as you said in the past there was). The framing is slightly wrong because it read "instead of AWT" as "not using any AWT API" which is not the case and overall not doable since CMP uses them under the hood anyway
I'm not claiming this is a flawless analysis and that's why I started by saying this is GPT not me
u
The problem with AI is that it's too long to read ๐Ÿ˜ตโ€๐Ÿ’ซ
s
That's why I didn't share the entire document lol
๐Ÿ™ƒ 2
u
I'm not claiming this is a flawless analysis and that's why I started by saying this is GPT not me
Yes, and I started by saying that I hope I have the right to contradict an AI agent.๐Ÿ˜…
s
You do of course lol
u
Believe me, today it's not obvious at all. ๐Ÿ˜ฐ
a
Cool that's good to see a course analysis. now feed the table back to an agent and tell it to get to work filling the gaps ๐Ÿ˜
I know the performance wouldn't be as good, and probably other problems. but I would love to be able to offer a pure native portable exe of my compose app
silence the "Flutter can do it" crowd ๐Ÿ˜
u
What is the problem with the Nucleus solution using GraalVM Native Image?
GraalVM's native image completely crushes Dart or Kotlin Native in terms of performance, with absolutely no comparison possible.
And that's without even mentioning the fact that you maintain backward compatibility with the Java ecosystemโ€”certainly not perfect, but possible. You talk about Flutter as if it were a solution for desktop; to my knowledge, Flutter desktop doesn't handle multi-windowing and doesn't handle mouse events but simulates touch events instead. In terms of scroll quality, it makes the experience very bizarreโ€”basically, you find yourself with a mobile app on desktop.
For me today, in terms of Flutter Desktop's capabilities, it's exactly what you could do with Compose Web, so there's no point. I can't imagine building a desktop app with a single thread, or even without IntelliJ's profiler.
a
it's fine, but it's a sort of MacGyver step right? kotlin supports compiling to native, but instead we're duct taping and gluing and doing some MacGyver stuff to get the jvm to compile to native which it was not intended to do. We're more similar to an electron app or something where we are making it work on a technical level in a way it wasn't really intended to
u
I think Kotlin Native on Windows, Mac, and Linux is much more of a workaround than GraalVM; it's something that nobody uses ๐Ÿ™‚ You can't say the same about GraalVM.
a
well while I agree GraalVM is much more mature and probably even more performant, we'll have to agree to disagree that it's not the work around. a good work around to be sure, but very much the definition of a work around
JVM doesn't support native compilation, so GraalVM hacks it together in a way the JVM authors never intended to do the thing.
u
I am currently adapting my trayapp API for the TAO backend and checking the RAM usage with Native Image; I don't think Flutter achieves such performance.
Enregistrement de l'รฉcran 2026-07-11 231602.mp4
GraalVM is supported by Oracle today, in the same way as the JVM itself, so I don't accept the argument.
๐Ÿ‘ 1
And that's without even mentioning everything GraalVM offers without native images; I'm talking about all the polyglot features, which are just incredible if you need to work with the Python ecosystem, for example.
github.com/bitsycore/compose-desktop-native I came across this project which uses Kotlin Native, and I copied its example but with my Tao backend + GraalVM Native Image
20260712-1839-32.2821277.mp4
a
was that flash you opening a second copy of the app?
crazy fast if so
how does the resize behavior look?
u
the first is graalvm native image and the second is kotlin native
a
it would be interesting to get some hard numbers to compare
u
the resizing is perfect
20260712-1958-33.2624579.mp4
hard number of what?
a
I'm currently using the nucleus jbr window decoration. I should really investigate switching to the whole Graal pipeline in nucleus and the jni window decoration
u
I will publish Nucleus 2.0 between tomorrow and the day after; it will be much simpler.
a
I have a pretty intricate but battle tested CI pipeline for producing the final artifacts and publishing to stores, blowing that up to be able to use the Graal will be kind of a big job. but I think the two are intertwined in nucleus right?
u
Nucleus already provides you with ICs, indeed, no I don't see what would be complicated about it.
a
yeah I was running into some small problems last time I attempted it. producing a snap for instance, I already have one published so I can't change the app ID, but the app ID is not configurable in nucleus. it's derived from something that is fixed
it was just a bunch of little things like that that made me abandon it a couple months ago
u
yes i see the issue
It can take me a while to fix the issues, but I accept PRs pretty quickly ๐Ÿ™‚
a
for small projects I love batteries included experiences like what nucleus provides. but for larger long-lived projects like the one I'm working on, I find a lot of benefit in being more in control of these parts of the pipeline
u
I don't think packaging is the main selling point of Nucleusโ€”it's an added bonus. Nucleus is probably one of the most modular frameworks out there; apart from the runtime, which is tiny, you are free to do whatever you want
a
yeah I love that it's more of a toolbox that you can pick the parts out you want
๐Ÿ’ฏ 1
but the big benefit for me would be producing the Graal VM artifacts, which I'm going to take another whack at once 2.0 is released
also hopefully switching the windowing manager to Tao or something
u
Tao will be the only window manager I maintain; everything else will be deprecated and no longer supported. I can't maintain that many things, and especially since I no longer see any point in not using Tao.
All my libraries will gradually force the use of Tao; for example, for Compose Media Player, I imagine it will reduce the library's complexity tenfold because I'll no longer need to do offscreen rendering, and all while using 0 cpu
๐Ÿคฉ 2
112 Views
Open in Slack
PreviousNext
Powered by