H guys. There is a library project I have been wor...

# compose-web

[Shreck Ye]

H guys. There is a library project I have been working on that unifies the APIs of androidx.compose and Compose HTML https://github.com/huanshankeji/compose-multiplatform-material (you guys are welcome to check out though the components are currently not complete yet). And there is a question I can't find accurate answers online to and I hope to get some official replies to: is Compose HTML now literally part of Compose Multiplatform or not? From what I can find online it's called a "side library" of Compose Multiplatform, but there isn't a yes or no answer. I am considering renaming the project to "compose-multiplatform-html-material" or "compose-multiplatform-html-unified" if the answer is no. Or if any of you guys can help me figure out a better name I'd also appreciate it.

[David Herman]

Author of Kobweb here. Personally, I've always functionally considered Compose HTML a distinctly separate thing from Compose Multiplatform, but according to @jim it's technically a part of it: https://twitter.com/JimSproch/status/1776460202596024387

I can respect that decision, although I suspect for practical purposes, most people probably think of Compose Multiplatform as Jetpack Compose ported to desktop, web, and iOS.

I guess I feel "compose-html-material" is a safer name (and shorter!) but definitely curious if other people have other opinions. You might also consider a name like "compose-multiplatform-dom-material" maybe; not really recommending it but throwing it out there in case it spurs some other name ideas for you. You might also try sidestepping the issue by coming up with a unique name (like Kobweb, Kilua, Doodle, etc.) and then just explain that it's a compose HTML library when people read the description.

[Oliver.O]

I think Compose HTML is quite accurate, though the other variants are missing a common name, at least "officially". I'm calling those "Compose UI" (could be better, but that term seemed to stick with some folks).

Why would you want to attach "material" to it? It could work with any CSS kit out there, right?

[Shreck Ye]

Thanks @David Herman. The information you provide on Polymorphic Compose is quite helpful. I have thought about this roughly in the past and it's great to see someone explaining this systematically and working on it. The name "compose-html-material" has been used on this project but I am also considering merging the 2 projects. (This project started as a project wrapping mwc but was quickly superseded by KMDC. And now I've been wrapping the Material 3 components in Material Web as a dependency of compose-multiplatform-material, which also kind of overlaps with https://github.com/mminke/kotlin-compose-web-material3 .) Coming up with a unique name is also a good idea but I haven't put much thought into it yet as the library is not quite complete yet. Overall, thanks again for your suggestions and your great work done in Kobweb.

[Shreck Ye]

@Oliver.O I attached "material" to it because initially I only wanted to support Material components on both kinds of targets, but it later turned out that I had to implement some "foundation" and "ui" APIs for it to be usable. The JS portion is based on Compose HTML, Kobweb, and Material Web so it should work with CSS, for example, the Material Web tokens. I am also considering wrapping these in a unified `MaterialTheme` but there is no ETA yet.

[Oliver.O]

Thanks for explaining. I haven't looked inside, but would it be a possibility to decouple your unified API and your unified Material components? Maybe then it would be easier for you to name things and for users to build a mental model that sticks. I'm not sure if I understand all the implications correctly, but this is what I understand from what you've mentioned in this thread without looking into the repos.

[Shreck Ye]

My pleasure. Yeah, it's possible to only use the "com.huanshankeji:compose-multiplatform-common" module which maps to the "foundation" and "ui" modules, but the "material" modules depend on the "common" module. Currently, there are only some APIs that are absolutely necessary in the "common" module so if you mean "decouple" by moving it to a separate repository, it's not planned yet.