I think I have some ideas :slightly_smiling_face: <https://twitter.com/simonw/status/139691771570562...

# compose-web

[orangy]

I think I have some ideas 🙂
https://twitter.com/simonw/status/1396917715705622528

[Javier]

Personally I hope compose-web get support for all "normal" APIs instead of manipulating the DOM or whatever web concept but with Kotlin as language instead of JS.

I understand the first approach is to attract web devs to use Kotlin, but mobile and desktop devs will want to just reuse their composables instead of learning web concepts and reimplementing the composables multiple times

[Akif Abasov [JB]]

It’s not only about different concepts. It’s about SEO, accessibility, extendibility with existing browser ecosystem and etc. Then, i believe, will appear optional Canvas based solution which can be combined with DOM based to introduce common widgets from Desktop and Android in cases when it’s ok.

[Akif Abasov [JB]]

And I think that someone can create common library of components which implemented in different ways in Desktop/Android and Web via expect/actual mechanisms, but has same signatures. Something like React Native.

[Brian G]

Why not both? Use the standard compose "widgets" but render them using native DOM elements.

[Brian G]

Flutter has a pluggable backend canvas or DOM+Canvas.

[Akif Abasov [JB]]

IMHO: Standard compose widget system can’t be fully supported by DOM without performance/accesibility/etc. problems. Maybe SVG can help.

[Akif Abasov [JB]]

But there’s experiment to try it. You can check “falling balls” example

[Akif Abasov [JB]]

About flutter

[Akif Abasov [JB]]

So i don’t want to say that common compose API should not be available in Web, but it’s much harder and will have lots of tradeoffs.

[Brian G]

Yeah Compose is very similar so in theory the tradeoffs will be identical

[Javier]

Exactly when I said that I was thinking in flutter.

[Filip Wiesner]

mobile and desktop devs will want to just reuse their composables instead of learning web concepts

That's the problem. IMHO you should still learn concepts of the platform you are releasing your app on. That's exactly the reason I don't like RN and to some extent Flutter. It promises an idea that you can use one code base and ignore platform specific concepts. And in lot of cases it's just not true.

[Javier]

I understand there are specific concepts, but that is, specific, not all

[Javier]

An example in android is using an Android view because you can't use compose directly, that is not implying I have to avoid all common compose things and just using specific platform things

[Brian G]

Yeah, HTML is not going away. Android views might though? I could imagine Views being "deprecated" if Compose is successful enough over the years.

[CLOVIS]

Compose Web definitely needs to be web-friendly, but that doesn't mean it should just mirror the DOM.

To me, it seems like Google is not very serious about the Multiplattorm aspects (1.0 was announced, and it's still in androidx for everyone). If JetBrains is going to do all the work, I think they should take liberties with the API: instead of having Compose Multiplattorm (Web + Desktop + Android, and maybe Native one day) be a mirror of Jetpack Compose, it should have its own APIs.

Compose Multiplatform should probably have a set of common APIs that work everywhere with bonuses for each platforms, like normal Kotlin Multiplatform.

[Akif Abasov [JB]]

@CLOVIS , i think same way. And that is very similar to what happening with react native (API which works in all platforms on top of native primitives).