In what ways are compose wasm not production ready?

# compose-web

[Mario Andhika]

In what ways are compose wasm not production ready?

[Alex Styl]

for what it's worth, i tried to use dynamic and it doesnt seem to be available

[Stefan Oltmann]

I am working on a bigger pet project and it seems to work pretty well so far, but something is off with LocalDensity detection compared to JVM.

stefan-oltmann.de/oni-seed-browser

[Kamil Kalisz]

I'm using it in my project so far it works pretty ok. Currently I'm using Precompose for my project navigation and it lacks "support" for browser back/next buttons. But except that I'm pretty happy.

[Jakub Kostka]

IMO, the initial download speed is crucial. Having your landing screen walled by a 6-8MB file is not ideal for a website, where the initial load speed is crucial. I'm experimenting with a brand website on low-cost hosting, and it doesn't seem feasible at the moment as it loads up to 10 seconds. Other than that, I love the options of Compose and Kotlin, I think even at this point, the options available are enough for the majority of use cases. Perhaps having your landing screen in an HTML file, which would after the successful download be hidden may be the solution. But for me, I use Compose to avoid exactly that. Perhaps each screen could be somehow split within the web assembly code, but that is something up to the KMP team.

[Jacob Ras]

Ha @Stefan Oltmann, I have no idea what I'm looking at there but it looks cool

[Jacob Ras]

It also depends on what you're building. Like fellow Jakub said above: initial loading time + download is worth thinking over. For example, I'm building a web app where people would spend a lot of time in it after the initial load. Then it seems fine to have to wait a bit.

[El Anthony]

I'm using for a intranet app, then the initial loading time isn't too bad

[Kamil Kalisz]

For me it's also not a problem as in most cases wasm files are cached by a browser