I’ve worked a little bit now with both compose for...

# compose-web

[Nikolai Wotton]

I’ve worked a little bit now with both compose for web and compose for android and I’ve noticed quite a few differences. Is the plan to have them eventually meet in the middle as a KMM code-shareable library or are they destined to diverge?

[jim]

Desktop and Android are much more similar, FWIW. We would like to increase the sharing of widgets across all platforms, so we'd rather converge than diverge, but ultimately the future depends on usage numbers and community feedback. Community contributions are also welcomed.

[spierce7]

They are currently working on Widgets that run on DOM. This fundamentally means that trying to make them match and look the same as widgets running on Canvas is difficult to do well.

The web team has expressed an interest in running the web compose on canvas as an alternative to DOM via canvaskit, but this will increase the size of the compiled applications by ~2.5 MB as canvaskit is a large library. Because of that they have avoided it as the initial option.

I’m personally waiting for the canvas drawing option so that widgets can be shared between all the platforms with some amount of ease.

[Casey Brooks]

Yeah, after working with Desktop, I would definitely rather see a canvas-based option. The styling of the Compose UI is just soooo much easier than working with HTML/CSS. It seems like the canvas is already fairly well abstracted out, so maybe there’s a future where Compose Web draws on the normal web Canvas and doesn’t need the canvaskit dependency

[Michael Paus]

I am not a web developer so my question may be stupid but can anybody explain to me what the motivation is to stick with the DOM for the kinds of web applications that Compose will most likely be used for?

[Casey Brooks]

I don’t quite get it either, other than that’s the quicker way to make sure Compose even works in JS. But compose is designed for UIs that change over time with user interaction, and the typical argument I’ve seen in favor of DOM is SEO, which would be static content that does not change. Compose is better-suited for applications that would likely require a user to log-in, and would not be indexable anyway

[Casey Brooks]

The other argument I’ve seen is accessibility. My guess there would be that existing screen-readers or other accessibility tools are locked into DOM and so Compose’s a11y features would not work with them

[Michael Paus]

The accessibility is of course an important aspect but then the Compose’s a11y features only should somehow be mapped to the DOM ones but that should not stop the rest from using Canvas drawing which is the only solution that would make Compose Web interesting for me.

[jim]

Yeah, absolutely both paths are entirely possible, and I imagine that both will probably happen in the fullness of time. Probably some company (maybe Jetbrains, maybe someone else) will like using Compose for their mobile applications and will want to share code with web. Getting Compose drawing to Canvas wouldn't be terribly difficult, but it's probably more than a 1-person effort, so it will require a few people who want to share UI code to step up and help make the entire Compose ecosystem that much better. But it is certainly doable, and if anyone is interested in making it happen, let me know and I'm happy to help facilitate!

The DOM was chosen as a first target for a few reasons.
1. Firstly, it's easier to address the long tail and build something that is actually usable. There is SEO and a11y as mentioned, but there is also interoperability with existing code/libraries, and development tools (chrome devtools), and a whole host of other issues that would need to be relatively well polished to make a useful product. To be clear, these are achievable, but they introduce additional complexity at a time when we needed to prove the basics, and DOM allows us to sidestep all those issues.
2. Performance - Drawing to Canvas would require loading the CanvasKit binaries into the browser. This is totally doable, but comes with a certain performance cost. For a large SPA (single-page-application, like gmail) it might be acceptable. But for small webpages, downloading canvaskit would make the page loading measurably slower. This limits the places it would be applicable.
3. Motivation - Jetbrains had an existing web-based product built using the DOM, and was looking to use Compose, so the thing they were asking for was Compose targeting DOM. If instead they had an Android application and wanted to run it on Web, the calculus might have been different, and Canvas-based might have been implemented first.
That said, canvas-based-widgets also come with a bunch of advantages. The most notable of which is that widgets only need to be written once, and can be shared across Android+Desktop+Web+Whatever. This makes it easy to offer a consistent experience across platforms with a tiny fraction of the development costs.

Ultimately, I think both are super important and useful, but a canvas-based-widget has different use cases and different tradeoffs. If your team/company wants to help make the story complete, let me know and I'm happy to help facilitate!

[Michael Paus]

Bad luck that I am not in a position to help you out here 🙂

[ESchouten]

In my opinion canvas-based rendering is the only way Compose Web (and to some extent Kotlin/JS) will get short-term success. Not because DOM-based is inferior, but because of market demand due to the multi-platform capabilities, and Web and Android marketshares being so large.
Adding to that, right now Compose is used for downloadable apps, serving the same market as SPA's, not static web pages.