Hello! I was wondering: With release 1.0, is compose for web ready for production in terms of stability? I see some people calling it a toy, but I guess that is only because there aren't that many 3rd party libraries and you have to construct everything by yourself (e.g. like material design, even though there is now a lot of effort put into kmdc). Am I right that in terms of "what you see is what you get", compose for web is stable and production ready right?

Compose-web is like vanilla react at this stage. You can do anything you could with vanilla react, but it can become very verbose very quick given that you don't have access to any 3rd party components yet. It also suffers from kotlin.js initial bloat, so small applications will be a lot larger in size when compared to same app in vanilla js.

Based on what was shared by @[JB] Shagen in https://kotlinlang.slack.com/archives/C01F2HV7868/p1640344426333700, am I right in understanding that JetBrains/Google will focus for now on building Canvas-based reusable components for both Desktop and Web with pixel-perfect precision at the cost of a 2M cacheable download and worst SEO/accessibility, and that people preferring building website with Compose for the Web won't have out-of-the box reusable components other than the ones provided by the community like https://github.com/mpetuska/kmdc ones (like vanilla React)?

You'll have two options to choose from (with tradeoffs). A. canvas-based components provided by JB that you can reuse for your android and desktop app, with the downside of bigger bundle size and worse accessability B. Community provided HTML-based components (like #kmdc or bootstrap-compose) that provide smaller bundle size and better accessability, with the downside of being web-only (i.e. no way to reuse your components on android and desktop)

For people wondering about the footprint of Compose for the Web with KMDC or Bootstrap Compose, the size of the

.js

file generated for their samples/sandbox with

./gradlew jsBrowserDistribution

are respectively

1.5M

and

1.7M

. Typical website will not use all the components but will provide their own logic so maybe that's not a so bad estimation of the footprint of a typical app/website. Is there some lazy module loading capabilities I could enable to have a lower initial download/parsing size?

Note that KMDC is made modular to help with this a bit, so instead of adding all components to your dependencies you can add only the ones you need (

kmdc

vs

kmdc-button

+

kmdc-textfield

)

Great feedback thanks.

^Excellent summary of the state of Kotlin/JS Regarding the file size, it's not ideal, but at my company we are resource constrained so our decision was between not supporting web at all, or using the common code to ship a heavy but functioning web client, so it's working well for us. I personally would not use it for any web-focused products due to the bundle size. I would love to see better tree-shaking/minification/etc on Kotlin/JS though. Our bundle is currently 5MB 😅

@Brian Guertin have you tried adding the

-Xir-per-module

and

-Xir-property-lazy-initialization

flags to your project? They help decreasing the bundle size (they don't do miracles, but every Kb you can shave off your project is always nice 🙂, on my simple project with Ktor + Compose + kotlinx.serialization they removed 0.43MiB from my project's bundle size) https://youtrack.jetbrains.com/issue/KTOR-1084

@MrPowerGamerBR Great tip! That reduced my bundle from 5.59 MB to 4.35 MB

Thanks for all the responses! Then I go with this conclusion: Compose for web is stable! 🙂 Side effects include: big bundle size and everything is vanilla, also it will probably coexist with a much more advanced canvas based rendering (which sacrifices some browser accessibility features). I guess for my side project it will be an excellent choice.