hi all, i’m an android developer exploring compose for web. is it correct to say that compose for web at this time does not support compose ui (e.g. Box, Modifier, etc.), but compose for desktop does? also if this is the case, are there any plans for supporting compose ui for web in the near future? thank you kindly

Hi, fundamentally there are two different approaches to web frontend development using Compose. • DOM (tree of good old HTML tags) - this is currently the polished way similar to React.js and other declarative frameworks in JS. This uses Compose, but not Compose UI (so you can only have multi-platform code sharing between Android and Desktop) • Canvas - this approach draws the whole UI onto web canvas and lets you write code using Compose UI (and share it between platforms). AFAIK this is still experimental, so not everything is supported, things are not well documented and performance is not great (this may inherently be the problem even after it hits GA)

got it. great. thank you.

@fmasa What makes you believe that the performance is not great (this may inherently be the problem even after it hits GA)? Actually I find the performance already quite impressive. On my Mac these examples work like a charm. Of course there is always room for improvement. https://koalaplot.github.io/koalaplot-samples/index.html https://mpmediasoft.de/test/PolySpiralMpp/ (I got one feedback from someone on Linux where the performance was not so great (haven’t seen it myself yet) but that is not so unusual for Linux and one should not judge any new GUI technology by its initial performance on Linux.)

Also with Dom based you can still share your code: everything except your UI, but database, business logic, network, view models with Flows/States

@Michael Paus Yeah, this was unnecessary generalization. It will very much come down to the type of apps you develop. Visualizations etc. are great (these are usually done on canvas anyway even when not using Compose on web). For general web apps (think Github, Slack, not Figma), I've yet to see a webapp fully rendered on canvas that isn't janky (usually when scrolling). The snippets you have posted are actually just a tiny bit of what you would see on a busy app screen. However, that does not mean that this is impossible to overcome (we have canvas off-screen rendering and other tools that could help). This is not the only problem of canvas-based solution though (accessibility and text input comes to mind). This is a great way to quickly turn Android app into a webapp, but right now separate DOM-based implementation would in most cases be more performant and accessible than former.

That’s why we have two options right now.

As to the main question. Browsers are really good at rendering DOM while applying performant CSS effects. It's due to years of optimization for this use case. When using canvas, all these effects now have to run in user code. So making highly performant webapps using canvas is certainly possible, but it may not be feasible without significant improvements in both Compose and browser APIs.

This generalization does not hold up in practice: Browsers can be good at rendering certain DOM/CSS stuff. Have you ever tried to make a browser render a DOM table with 400x400 cells (no matter if

<table>

or

<div>

with CSS grid) and animate cells via CSS? This will quickly convince you how slow browser-based layout and rendering can be despite being around for decades. While I haven't checked the current state of affairs, Compose is highly optimized and with Skia running on WebAssembly I wouldn't be surprised if it is capable of significantly outperforming DOM/CSS, depending on the scenario.

@Oliver.O It would be so much fun to create some examples/benchmarks in canvas-based compose, showing that decades of browsers micro-optimizations have to be worse than compose fundamental optimizations thanks to snapshot system (like automatic fine-grained skipping of compositions, skipping layouts, skipping drawing etc.)

I have some stuff which I'l probably publish soon (possibly even today). It is aimed at discovering specific current limitations, so I would not call it a benchmark. (Capturing meaningful real-world scenarios in a general benchmark rarely works, so I'd always prefer to create a custom benchmark tailored to the actual use case.)

@Oliver.O That't the thing with generilazations, you can always find exceptions. As I mentioned, performant canvas based solution is certainly possible. And since we don't see many complex Compose web canvas apps, the jury is still out. Other similar solutions (Flutter Web comes to mind) are still janky even for relatively simple screen. Don't get me wrong, I very much look forward to "simple" way to bring my Android app to web, but the road is still bumpy (not only on performance front).

I'm not sure that my findings – being tied to specific limitations – will make a difference there when compared with DOM. The example I'm working on is something DOM can do well enough and Compose on Canvas currently has a limitation with redrawing (you'll see). On the other hand, with specific table layouts, browsers still have problems with DOM size and layout reflows. In such cases, Compose may outperform DOM right now.

One specific problem I currently see is the performance of resizing the canvas. This definitely needs a closer look. If you just try my example from above (https://mpmediasoft.de/test/PolySpiralMpp/) you’ll notice that the rendering is quite fast but when you try to change the window size at the same time this breaks down completely. I have not done any measurements but as far as I can see the rendering of the desktop variant of this code is equally fast as the web variant. The big difference however is the resizing behaviour which pulls down the whole experience. It would also be interesting to compare the performance on different operating systems and browsers.

@fmasa But flutter doesn't have anything as good as general snapshot system, right? Also I wonder if maybe google docs/spreadsheets are already using some internal flavor of compose web on canvas (I remember they moved to canvas based rendering like a year ago)

As to Flutter, I don't know. It just comes to mind as the most polished contender right now.

Here is a little app exercising Compose for Desktop and Compose for Web/Canvas via various grids with lots of cells. This is not a universal benchmark (I believe there is no such thing that would make sense). But hopefully, it helps to better understand some aspects of what Compose Multiplatform is currently capable of. Included is a mechanism that resizes the browser's canvas element to its Compose content. https://github.com/OliverO2/compose-counting-grid

@Oliver.O The

key

should do it:

key(Configuration.animationsEnabled) {
                Grid(grid, topLevelRecompositionTrigger, rowLevelRecompositionTrigger, cellLevelRecompositionTrigger)
            }

But I checked it and its still slow. Still my understanding is that

key

should make compose throw away old grid and build a new one. Maybe to make it really efficient it's necessary to make every cell always take the same amount of space in slot table regardless configuration. Then

key

or

if (showGrid)..

condition could be removed.

FYI I'm working on a framework that sits on top of Web Compose called Kobweb (https://github.com/varabyte/kobweb), which adds a few methods taken from Android Compose (including Row, Column, and Box) which internally delegate to traditional HTML DOM approaches.

Isn't this something JetBrains pursued before targeting canvas?

Not familiar if they did, but I definitely think it doesn't make sense in the core library because Android and Web have some fundamental differences. Putting it one layer above seems like it's a bit better.

Yes, they tried and switched to canvas because modifier problem and no ui sharing. You would still need to use actual/expect to share the ui with web.

Yeah, Kobweb aims to be a couple of orthogonal features. Widgets are just one slice of the pie.

@langara

Still my understanding is that

key

should make compose throw away old grid and build a new one.

The changing key would indicate that recomposition of

Grid

is necessary. That, however, doesn't mean that the entire Composables tree below

Grid

will be rebuilt as Compose can skip recomposition selectively: https://www.jetpackcompose.app/articles/donut-hole-skipping-in-jetpack-compose

@Oliver.O But the

key

change is not only for triggering recompositions. It changes identity of the subtree, so (if I'm not mistaken) it should make the old subtree leave the composition and the new one enter the composition. As in Figure 1 here: https://developer.android.com/jetpack/compose/lifecycle#lifecycle-overview

That seems to be a reasonable interpretation. However, as our measurements show, a changing key for

Grid

wouldn't make Compose throw away the old `Grid`'s content and rebuilt everything anew. I have even tried to use a separate counter as a grid ID, incrementing on each animation setting change, but that's still slower than not showing the grid for a period of time. I can only guess, but Compose seems to infer that while there is now a new

Grid

(identified by a new key), its content has not actually changed (at least initially), so it just "moves" all of its Composables to the "new"

Grid

. Could someone from the Compose team enlighten us?

@Oliver.O

key

usually makes sense when the items of some collection could move within its container. The thing is when Compose runs recomposition and when it sees

key(value)

it doesn’t know yet if this key (the content represented by this key) should be thrown away or it could’ve moved somewhere within a container (it can throw it away only after it completes the recomposition of that particular container). I used this snippet in your project:

Row(horizontalArrangement = Arrangement.spacedBy(12.dp)) {
                Button(onClick = { selectedGrid.value = null }) {
                    Text("Back")
                }
                Button(onClick = { startOrStop() }) {
                    Text(if (running) "Stop" else "Start")
                }
                Button(onClick = { grid.clear() }) {
                    Text("Clear")
                }
                Button(onClick = { k.value += 1 }) {
                    Text("Inc key=${k.value}")
                }
                Button(onClick = { configurationVisible = !configurationVisible }) {
                    Text(if (configurationVisible) "Hide Configuration" else "Show Configuration")
                }
            }
            Info(grid, startMoment, configurationVisible)

            key(Configuration.animationsEnabled.value) {
                Grid(grid, topLevelRecompositionTrigger, rowLevelRecompositionTrigger, cellLevelRecompositionTrigger)
            }
        }

Tested with this:

@Composable
private fun CellText(cellContent: Int) { 
    if (cellContent != 0) {
        Text("$cellContent", style = MaterialTheme.typography.h6)
    }
    DisposableEffect(Unit) { // or even better to add DisposableEffect in Cell
        println("Cell created")
        onDispose {
            println("Cell disposed")
        }
    }
}

And when Configuration.animationsEnabled.value changes, every cell gets disposed and created again (so no smart move of content from the old Grid to a new one).

if (showGrid) { Grid() }

is better because Compose knows for sure, that there is no need to temporary keep the old content (the content with the old key). As for the need for `if (showGrid) { Grid }`… My understanding is probably not detailed enough and could lack some accuracy: It’s related to SlotTable write operations. Compose writes into SlotTable much faster when there is no need to change the position (to move the Gap here and there) - when it can write continuously one part after another. This happens when we create a new group and add all the new content into it (e.g. when showGrid changes from false to true, it adds everything related to Grid). But when the write operations happen at many different positions, it requires moving the Gap back and forth. It happens when the content of many cells changes at one moment. I think someone in #compose could explain the operations in SlotTable much better 🙂

Thanks for experimenting and your explanations. Yes, I was aware that

key

identifies a Composable whenever positional identification is insufficient. If my observations were correct, the interesting thing is: It is not just that

if (showGrid) { Grid() }

helps, but also that the duration of hiding the grid matters. For larger grid sizes, a longer period seems beneficial. If it's just the slot table, I'd expect no change in results between

if (showGrid)

and

key(...)

if in both cases the old grid and its components are thrown away completely before creating new slot table entries for the new grid and its components. Or did I miss something?

there is a difference between

if(showGrid) {}

and

key(…)

with if: 1) create initial Grid , 2) showGrid changes to false -> initial Grid gets disposed 3) showGrid changes to true -> new Grid gets created and composed with key: 1) create initial Grid, 2) key value changes -> new Grid gets created and composed 3) initial Grid gets disposed The order of create/dispose is different. This still doesn’t really explain why

key

performs worser than

if(showGrid)

, but at least now we know there is a difference, which could mean different states of SlotTable (needs digging into it).

but also that the duration of hiding the grid matters. For larger grid sizes, a longer period seems beneficial.

it appears that insertion of

AnimatedContent

makes the difference. It’s slow not only when we set true to

Enabled animations

state on a GridScene, but also when we enable the animations beforehand on GridChoiceScene and then open GridScene. Turning the animations off (while on GridScene) goes faster than turning it on. If we remove the AnimatedContent, it makes changes to “enabled animations” state equally fast/slow (either turn on or turn off):

if (Configuration.animationsEnabled.value) {
            @OptIn(ExperimentalAnimationApi::class)
            CellText(cell.content)
            // AnimatedContent(cell.content, transitionSpec = {
            //     slideInVertically { height -> height } with
            //         slideOutVertically { height -> -height }
            // }) {
            //     CellText(it)
            // }
        } else {
            CellText(cell.content)
        }

But still,

if(showGrid)

is necessary for big grids, but no need to have larger delay for bigger grids.

The differences in order might result in a different load pattern on the slot table. I'll see if I can get some hard timing data (interval between changing the animation setting and cell updates continuing) and/or some profiling data covering just that interval. I don't want to put too much load on you as this example might be a strange corner case and there is probably more important stuff in CfW/Skiko to work on right now (e.g. text input and such). I'll report back as soon as I have some data (might take a while). 🙂

start a new thread 🙏☺️

I have updated the application on GitHub to better measure UI responsiveness (see Changes section in the README). Basically, @Oleksandr Karpovich [JB], you are entirely right pointing to slot table updates being the root cause. The trick I had achieved was just removing the old grid from the composition, then delaying until the next recomposition before inserting the new grid into the composition. This replaced slot table reshuffling with sequential insertions. The exact delay is just a heuristic value, lacking a precise indicator for a point in time when the current composition phase completes. I mentioned that an additional delay seemed beneficial for larger grids. There is some truth to this, but the gains are not significant and can be attributed to a different effect: As CfD redraws the entire composition tree on each frame, hiding the grid longer means less redraw cycles happen while the ripple animation of the 'Enable animations' checkbox runs. I have created a separate cross-linked thread in #compose regarding the slot table update problem here: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1663066133417219