Is anyone using Compose HTML in production? I'm cu...

# compose-web

[spierce7]

Is anyone using Compose HTML in production? I'm curious on it's performance.

My team is making a new app, and it's goal is Android, iOS, and Web. Compose Web doesn't seem like it will be ready for quite some time, so I'm curious what kind of results people are getting from Compose HTML? Is it suitable for large complicated web applications?

[ian.shaun.thomas]

Yes, performance is fine but the js payload size continues to be way too big for most critical use.

[ian.shaun.thomas]

By big I mean ~2mb using as few dependencies we can.

[spierce7]

If I can get good performance, and the app is <6MB, I'll be pretty happy

[Norbi]

Isn't Compose/HTML supported by the new wasm compilation target?
I think it will have much smaller compiled sizes (see e.g. https://kotlinlang.slack.com/archives/CDFP59223/p1683366751923329).

[ian.shaun.thomas]

Doesn't wasm still require opt in browser flags? I'm targeting "Smart"TVs so I have to support back to like chrome 53 for tvs less than four years old. Thanks a lot Samsung and LG for pushing this ancient junk.

[Big Chungus]

Wasm is out of question for you if you need to support TVs. As for bundle sizes, it's only concerning for small to medium sized apps as the majority of the hit is static increase to polyfil kotlin features. Also es6 support is on the horizon which should unlock better treeshaking. Compose html itself performs just as well as react (if not better) and is pretty stable by now.

Your main concern will probably be integrating with npm dependencies if you need any, otherwise the experience is pretty smooth sailing while you stay within kotlin code.

[Big Chungus]

Note that some kmp libs result in substantial size bumps so you could try to avoid them or replace with js counterparts if size starts becoming concerning. e.g. kotlinx.serialisation or kotlinx.coroutines

[Big Chungus]

You can replace serialization with external interfaces and browser's JSON. For coroutines you could just use fetch api directly and forego suspend functions.

[Big Chungus]

But none of that is specific to compose html, just generic kotlin.js gotchas

[ian.shaun.thomas]

Yep but his use case is similar to ours trying to share code across several platforms and it gets really hard to avoid using some libraries. I'm hopeful the ES work makes good progress towards the bundle size.

And yeah we chose our fate with the TV's granted there is literally zero joy to be had supporting them in any language.

[Norbi]

@Big Chungus, maybe have you tried Compose/HTML with wasm? Does it work at all?

[Big Chungus]

Wasn't even aware it's supported yet

[Norbi]

Sorry, maybe I only imagined it is :(

[spierce7]

Note that some kmp libs result in substantial size bumps so you could try to avoid them or replace with js counterparts if size starts becoming concerning. e.g. kotlinx.serialisation or kotlinx.coroutines

kotlinx.serialization and corotuines, along with ktor are likely auto includes for us. Avoiding Coroutines in our common code removes a thing we love about Kotlin.

[Big Chungus]

By polyfils I meant stuff required for kotlin stdlib to work (e.g. Long type). And yes you can't not have them.

As for js interop, writing external declarations is tedious, but pretty straightforward once you get the hang of it.

[spierce7]

I'm less concerned with initial load size, as its going to be cached for most of our users. It's behind auth. I'm mostly concerned with the experience after load, and load times in general for the cached experience.

[Big Chungus]

Exporting your code to js is a lot harder and limiting though, but can be avoided if your entire app is written in kotlin

[spierce7]

As for js interop, writing external declarations is tedious, but pretty straightforward once you get the hang of it.

I've been trying to make Kotlin JS work in the browser since 2018. I'm pretty familiar with creating externals, and have several in our project for nodejs. I've learned to just embrace the dynamic for interop.

[spierce7]

Exporting your code to js is a lot harder and limiting though, but can be avoided if your entire app is written in kotlin

We just attempted this. It was not a happy experience. We think this new targeted level of abstraction could be a win though, as long as we can convince our UI engineers to be ok with Compose HTML.

[spierce7]

thanks for your thoughts @Big Chungus

[David Herman]

@spierce7 I'm working on Kobweb (https://github.com/varabyte/kobweb). You can check out a few published portfolios that I shared in #kobweb, run lighthouse on them or whatever to check performance. My blog site https://bitspittle.dev is also Compose HTML (through Kobweb).

[spierce7]

Oh, I didn't realize Kobweb was based on Compose.

[David Herman]

I would agree with Ian -- performance is fine, payload size is concerning. Hoping to provide users with an option to break up their js scripts in the future, maybe it will help with caching (a larger initial download, but only smaller parts downloaded in the future)

[David Herman]

My blog site is ~700K last time I checked, not great but not anywhere near 2MB yet thankfully.

[David Herman]

Yeah Kobweb is a layer on top of Compose HTML

[David Herman]

I love the Compose API, definitely want to lean into it!

[spierce7]

@David Herman I see, so Kobweb is providing static site generation, that's how you get the performance on your blogs. Does Kobweb do anything like hydrating a statically compiled page for fast loading, but then allowing it to be dynamic, similar to next.js?

[David Herman]

I call it poor man's hydration. I create an initial snapshot for each page, which you download and render immediately, and then after that, Compose takes over, rebuilding the site up behind the scenes and replacing it.

[spierce7]

So at build time it's generating the static page for initial load?

[David Herman]

So you get faster loads but it's not traditional hydration (as I understand it) because it rebuilds stuff instead of updating stuff

[spierce7]

or is it using SSR, requiring everything to integrate with your server

[David Herman]

Nope, no SSR. You can use with a traditional static site hoster. There's a full stack version as well, where you run your own server, but not SSR.

[David Herman]

So at build time it's generating the static page for initial load?

Yeah, although outside of initial appearance, all pages are essentially the same. They all contain the seed for your full site.

[David Herman]

I'd love to revisit this later but it's working well enough for a 1.0 (which I'm aiming to hit this year I hope!)

[David Herman]

If you're interested in trying it out, you might want to check out: https://bitspittle.dev/blog/2022/staticdeploy which walks you through the steps to export your site.

[spierce7]

thanks, I'll look at it

[David Herman]

Hope it can help you! Feel free to let me know if you have any questions or feedback.