<@U019WDSFNKC> I'm going to create a DOM vs compos...

# compose-web

[David Herman]

@jeran I'm going to create a DOM vs compose thread here🧵 that people can add answers to your questions in

[David Herman]

I don't think it's ever going to be a situation where DOM will go away and canvas will be the only way to do things.

[David Herman]

I think there's valuable use-cases for both approaches. I don't work at JB so I'm just guessing here, but I think they have limited resources and had to choose one technology to focus on. For them, I would guess canvas / multiplatform makes sense, because Compose HTML is already working enough that you can do stuff with it even if they never work on it again (there are enough escape hatches you can essentially put anything into the DOM you want even if they don't support it yet). Meanwhile, multiplatform across all targets would let JB and Kotlin compete directly in the Flutter usecase (which, well, I haven't checked recently, but has been very popular for startups).

[David Herman]

Having a single codebase that truly works everywhere is very very tantalizing! So I definitely get that.

[David Herman]

However, there are still cases where you would prefer targeting the DOM, despite that. For example, SEO is probably a big one. Also, I suspect creating a full screen canvas to render your text blog is a bit overkill (imagine if every webpage on your ultrawide monitor became a 3000x1000 texture). And using Compose / HTML allows you to leverage a whole ecosystem of existing JS libraries which you can integrate into your site.

[David Herman]

I think the problem you are trying to solve is the most important thing to consider. If you're a new company and you're just trying to create a rich, interactive app, and you want it to run as wide a range of targets as possible, Compose Multiplatform for Web is for you. If you just want to create a traditional website and you'd rather use Kotlin than JS/TS (or maybe you have a bunch of Kotlin business logic that you can share), Compose HTML is worth considering.

[David Herman]

As for the experimental nature of wasm, and its current state of doneness, I can't speak to that. I'm sure someone else can.

[David Herman]

FYI there is a #webassembly channel which may be able to answer some of your wasm-specific questions, if you don't get an answer here.

[jeran]

oh thank you! but i really wasn’t asking about anything dom vs canvas. that’s been there since the beginning and i’m aware of the difference. what i’m curious about is just the canvas approach and the difference between the jsTarget vs the wasmTarget

[David Herman]

A gotcha. I thought your question 2 was asking if DOM was deprecated in favor of canvas.

[David Herman]

I am not sure about this, so don't quote me on it, but I wonder if someday you can have Compose HTML site (jsTarget) and a wasm part (wasmTarget), and basically embed a Compose Multiplatform for Web component inside scaffolding provided by Compose HTML. (Like how with Android you can mix Compose and their old XML view system). I'd love to hear from someone familiar with Compose Multiplatform for Web if this mental model of mine is totally off base or not.

[jeran]

ah. word. yeah fwiw. we actively have a compose mutiplatform web component embedded in a react app. we just had to do the “scaffolding” ourselves

[David Herman]

Neat. I guess what I'm wondering is if Compose Multiplatform for Web installs a bunch of global event handlers on the page.

[jeran]

my guess is no. i believe all the event handling is generally scoped to the canvas element you attach to. other than whatever hook they use for onWasmReady. but just guessing! we haven’t had any issues with like, the compose component swallowing events needed for the rest of the app.

[David Herman]

Nice! Thanks, good to know. Something I was wondering in the back of my head for a while.