I have a vested interest in making the compiler an...

# compose-web

[jw]

I have a vested interest in making the compiler and runtime work on JS and native and have landed some CLs to ensure the runtime will work. Others have sent small changes to the compiler to enable JS. It should be pretty close to usable.

I don't particularly care about Compose UI

[spierce7]

So what are you trying to do with it then if you don’t care about Compose UI? Wouldn’t the UI contain all the layouts that would allow it to be useful?

[jw]

No. Compose is a general purpose tree diff tool. Compose UI is just an implementation of one particular UI framework on top of it.

[jw]

It's not even clear how Compose UI would work on JS. Everything renders to Canvas and you ignore native DOM elements? Sounds terrible.

[altavir]

Not terrible, but not the primary thing. Dom components will be just fine for now. For wasm it should work perfectly on canvas.

[jw]

Yeah sounds like an accessibility nightmare. I'm currently using DOM nodes with Compose on one project and it works great. Or it will once the setup on JS isn't so crazy...

[spierce7]

Everything renders to Canvas and you ignore native DOM elements?

That doesn’t sound that terrible, except for scraping / SEO purposes. However would be a potentially great approach for anything behind an auth system.

Flutter is taking the approach of generating DOM elements, and that seems to be working for them, however it’s significantly more difficult I imagine.

[jw]

Scraping and SEO are just one consumer of the availability of a site's accessibility. Nothing about auth obviates the need for a correctly accessible site.

[spierce7]

Sure, I hadn’t considered accessibility.

Generating DOM elements similar to flutters approach would allow for all of the above, but is a more complicated problem to handle

[jw]

Only if you want to drag along Compose UI. Writing fresh composables that target the DOM is trivial, and then you can use any CSS framework you want like a normal web project.

[altavir]

You also need to think about the performance and the bundle size. I am not sure it is possible to minify the whole skia-web to a reasonable size.

[spierce7]

Only if you want to drag along Compose UI. Writing fresh composables that target the DOM is trivial

Fair point. It’s not the dream, but it’s better than having to deal with each system UI individually.

What do you think about Compose UI on iOS? Surely that’d be beneficial. While you might not care about material widgets inside of an iOS app, it wouldn’t come with the same tradeoffs, and you would care about the layouts, and things like Modifiers. androidx.compose.ui encompasses quite a bit.

[jw]

If your goal is the same as Flutter, sure, Compose UI on iOS is fine. But the Compose compiler/runtime can drive a MPP engine of your app and emit platform agnostic view models which are then trivially bound to platform specific components. Basically React Native's UI approach while still leveraging the intrinsic language of each platform.

[spierce7]

I 100% agree that’s a more attainable approach in the near future. However, its got a lot of moving pieces, and takes a good amount of time playing with an approach like this before a new developer can feel remotely comfortable with it.

If you look at something like Flutter, or even RN though, you can get up and running very quickly compiling for multiple platforms, and since everything for your screen is defined in a single file it’s easier for devs to understand and learn. If you watch a senior Android dev jump into a mpp code base without understanding mpp, much less iOS or JS, it takes weeks for them to become comfortable. The same android dev in a flutter code base, can get comfortable in a few days.

I realize we’re talking about different things here, and if you were to open source what you are talking about, I’d definitely use it, but I think that true compose multiplatform is an important step for Kotlin MPP adoption.

[christophsturm]

@jw it would be great if you could put a small demo of your dom components work in a github repo, it sounds very interesting

[jw]

It's nothing special. For each DOM element you write a @Composable that calls emit ComposeNode and creates the associated DOM element. Then you just add parameters and updater setters to assign values.

Something like

@Composeable
Anchor(href: String, children: @Composable () -> Unit) {
  ComposeNode(
    factory = { document.createElement("a") },
    updater = {
      set(href) {
        this.href = href
      }
    },
    children = children,
  )
}

Ideally you'd auto-generate all of these from the HTML spec.

Then you write a DomApplier that subclasses AbstractApplier and can manipulate DOM trees and you're basically done.

[jw]

Not worth pushing until Compose compiler/runtime are usable in JS without modification. We just got it working in the JVM without modification but the compiler part of JS is more tricky...

[spierce7]

@jw will you get acceptable performance with the above approach I wonder?

[spierce7]

I suppose that’s what React has to be doing under the hood as well.

[jw]

React uses a vdom. Performance should be significantly better with Compose, similar to Svelte

[hfhbd]

Why does Compose do not need a ID like SwiftUI? In SwiftUI, each Model needs to conform to Identifiable, which has only one id property, to compare between the changed objects, because the reference of the object could be changed, but the semantic id did not.