It is getting tricky to author a universal multiplatform Composable at the moment coz I see that The...

# compose-web

[andylamax]

It is getting tricky to author a universal multiplatform Composable at the moment coz I see that The Jetpack Compose Modifier and Compose 4 Desktop are using the exactly same modifier, located at androidx.compose.ui.Modifier while Compose for Web Modifier is entirely different and currently located at org.jetbrains.compose.common.ui.Modifier , Isn't this a cry out for expect/actual declaration?

Or maybe I am missing something, Can someone in the Compose 4 Web team explain to me why such a decision was made?

[darkmoon_uk]

Hey @andylamax just wanted to say you're not alone. I started out wanting to hold Web as close to Desktop and Android, as possible, but sadly I found diminishing returns for the effort it was taking.

[darkmoon_uk]

I still have a bunch of `expect`/`actual` s in my project to provide truly common access across the 'material' + web elements.

[darkmoon_uk]

...but without going into boring details I'm finding many situations where this is a PITA to use. The multiplatform aspect really needs baking in lower.

[darkmoon_uk]

I can only imagine it's not that way today, because `expect`ing the full set of Modifiers and other foundation functions would imply a lot more actual work in Web, than JB are prepared to do right now... as we know these things would need implementing completely anew for the DOM.

[darkmoon_uk]

I'm reluctantly rolling back my attempts to create truly common views, and implementing the Web Views separately.

[Nikola Milovic]

@darkmoon_uk yeah, I was really excited that we could maybe share web ui the same way we share desktop and android. I've read that this could be possible if they went the canvas route but they chose DOM.

[darkmoon_uk]

You may have found there is already some bridging via the .implementation property of org.jetbrains.compose.common.ui.Modifier

[darkmoon_uk]

@Nikola Milovic Latest I heard is that they're still exploring the option of rendering Canvas in the Browser.

[darkmoon_uk]

I think this was rejected earlier as being 'too different' from traditional web dev, and that it wouldn't be accepted for this reason, also less SEO friendly.

[darkmoon_uk]

I admit I'm biased as a native mobile Dev, but I really don't care for Compose/Web to be based on the DOM. This is a good thing in my view, never did like the DOM for building Applications, it always felt like a huge hack to me - forcing a document rendering engine to be an Application framework.

[darkmoon_uk]

The sooner we can treat the Browser as just another Client with sandboxed binary code (courtesy of WASM) and canvas rendered graphics, the better! But that's just me...

[Nikola Milovic]

Yeah same, I would 10x prefer the Canvas approach, I am guessing that SEO can be solved without too many issues

[darkmoon_uk]

I would assume that can be solved by exposing some appropriate metadata yes.

[darkmoon_uk]

Even if it's problematic for some reason there are still a lot of types of application that don't need SEO.

[darkmoon_uk]

If we had 'full material Compose' ported for the browser canvas, I'd be in dev heaven TBH ...added euphoria if it's WASM based, over Kotlin/JS 😄

[darkmoon_uk]

The fact it's not using DOM would be irrelevant for the things I want to build.

[Nikola Milovic]

Fingers crossed that maybe they pivot to this solution

[andylamax]

All my excitement is down the drain now

[darkmoon_uk]

😞 Sorry, man. Feels bad being the messenger.

[darkmoon_uk]

They were my dreams too.

[darkmoon_uk]

That said; I think the reason things have gone quiet is that sweet Browser Canvas PoC.

[darkmoon_uk]

🤞

[darkmoon_uk]

I literally just deleted my few-dozen remaining expect declarations from commonMain too 😞, hard call, but it was holding me back.