I'm curious about the average size of KMP / Browse...
# multiplatform
t
I'm curious about the average size of KMP / Browser applications. My app currently has about: • 30 pages (some fairly complex, see the screenshot in the thread) • 50 dialogs (some complex as in the screenshot, some much simpler) • charts, real-time updates, authentication and authorization, markdown renderer • 100ish icons • 200ish string resources This is 2.5 MB (uncompressed, production build). Since I'm using a relatively new framework (which is currently unoptimized), I'm wondering how this compares to other KMP browser applications.
Screenshot 2025-07-22 at 9.09.06.png
c
This is about what I would expect. Is this JS or Wasm?
t
JS
c
In 2019 I had a relatively UI-simple app with KotlinJS + Ktor + React and it was about 2.5 MB too
thank you color 1
r
I would say 2,5MB is very good result compared to CMP. Still to get some more complex components (like rich text editor or advanced tables) you will need to use heavy NPM packages or implement them yourself with a lot of Kotlin code.
thank you color 1
t
I don't use NPM at all, I implemented everything by myself.
And I plan to keep it that way, the tables won't increase the size much (I have an old implementation) the editor might but I also have an old implementation that used Operation Transforms and IIRC it wasn't too big.
j
Comparison to CMP - the image viewer example (https://zal.im/wasm/iv/) is 8 MB.
thank you color 1
The KiteUI sample project (https://kiteui.cs.lightningkite.com) is less than 2 MB.
@Tóth István Zoltán You're beating CMP by a huge factor at the moment, as are the rest of us who aren't using CMP or WASM.
t
Thanks, those are good examples, the KiteUI is localhost tho :)
j
Lol, wrong tab URL copied. https://kiteui.cs.lightningkite.com
t
My problem with WASM is that it is slow, the JetSnack lags for example.
j
That's been my experience too. I really didn't want to make an alternative UI library to Compose, but web performance is completely unacceptable and the design choices in the API of CMP literally make it impossible to fix.
t
Those design choices are why I started to write my own actually.
j
Ditto. I have longer rants about it, but I think I'll hold back.
t
Same, I really try to be diplomatic about it. 🙂 Thanks for the examples, I'm quite happy that even unoptimised the framework is not too big. That is one of my big worries.
r
Do not underestimate the power of the compose! 😉 https://spotify-clone-kilua.vercel.app/ - 0.5MB JS + 1,3MB Wasm
t
That is much better in terms of speed. It does not have many UI features to, so the small size is not comparable (I think).
Just adding datetime is +200 KB in the final minimised module.
j
@Robert Jaros Is this compose web or compose html? I see real components in there so I'm guessing the latter?
r
It's Kilua
j
Then you're on the same page as us, I think. Compose (as in the compiler plugin) is fine. CMP web is not.
Kilua looks pretty good!
t
In my experience real problems with any framework appears when you start to use tables, trees and resize together. This combo is very hard.
I've been working for 2 weeks to implement a tree-friendy resize like IntelliJ project tool and it is still not perfert.
j
Ugh, yeah, that sounds really difficult. We don't have a direct use case for that one as much, but my one attempt to implement that was a mess.
r
Full-featured production app with Tabulator component included, running with SSR, authorization and built-in complex admin module - https://demo.wykaz.finn.pl/ - 3,5MB JS. Heavier, but still not bad in my opinion 🙂
j
Duuuuude that's beautiful! If I didn't need a framework to also go to Android and iOS I think I might pick it up.
thank you color 1
t
How many pages do you have in the admin module?
And is that 3.5 MB the minified bundle?
r
Define "page" 🙂 There are at least 15 submodules, with different lists, tabbed pages, forms and modals.
Yes, minified but uncompressed.
t
That's why I asked, we don't see that in the demo, and 15 submodules are considerable.
j
@Robert Jaros I was playing around with the WASM compilation back in the day for my library and found that it was both bigger binary size AND slower, since I was doing heavy DOM manipulation. But it looks like you're doing heavy DOM too, and you're still using WASM. Has it improved a lot? Was there something you had to do to get it more efficient?
r
I think Wasm target is a lot faster than JS (50%?). Even when manipulating DOM it is still a lot faster.
j
Huh. I guess things must have changed. It has been a few years.
Thanks!