I have a question, how compose for web can be used for multiplaform ? As you create HTML components and CSS ? I don't quite get it

At the moment, I think what you are hoping for (write the UI once, launch on Android, Desktop, and Web) isn't there yet.

Unfortunately, sharing the actual UI layer with web requires heavy use of `expect`/`actual`.

You'll want to keep an eye out for a future feature where you'll be able to target HTML canvases.

It’s not that the HTML itself is multiplatform, it’s that HTML/CSS is the “composable output” of “Compose Multiplatform” on the JS Web target. The core Compose framework is only concerned with building tree-like structures, but doesn’t care any about particular UI, and it’s been written in Kotlin Multiplatfom (meaning the core framework doesn’t use any platform-specific functionality). The different UI toolkits for Android, Desktop (Java Swing and Skia), and Web (HTML/CSS) are all just implemented as composable tree structures on top of the core mutliplatform library. Like others have said, using Skia’s canvas-based rendering for other platforms (web, iOS) is coming, but it’s not here yet.

That said, multiplatform is still useful as you can write a bunch of business logic or libraries that are multiplatform, and share those across JS, JVM, etc. targets. I also like that you can create model classes in a multiplatform module and then use kotlinx serialization so you can share those model classes over the wire between a server and a frontend.

Aah I see, and when skia will be there, will actual renderer be deprecated?

I would be shocked if they deprecated the current solution.

The current HTML / CSS renderer will still be extremely useful even when a canvas renderer is made available.

Yeah, I’d imagine HTML will always be a valid target for Compose. It’s two completely different use-cases: building cross-platform UIs (Skia) vs using Kotlin for traditional websites/webapps

Nice, so building with it won't be a waste of time, last questions, is there any ETA for skia web ? And where can I find the advancement on it ?

The gist is this: with a canvas renderer, the rendering surface is totally opaque to the browser. You'll also likely need to make it fit the page, which I imagine would require allocating a bunch of extra memory. The HTML / CSS target, in contrast, will work more like a traditional webpage, meaning if you traverse the DOM, you'll see an actual tree of widgets and styles, which robot crawlers can use, as well as all those fancy debugging views that most (all?) browsers come with. Also, you can lean on existing accessibility solutions provided by browsers and web APIs. With canvas, your DOM will just be a big 'ol canvas.

Ah, so using skia web will be like a workaround instead of a complete solution against current renderer ?

I wouldn't say a workaround. I think when you have both choices available, they'll be for different purposes.

I see, thanks for all the answers ^^

I wouldn’t call it a workaround. It’s how Flutter does its Web target too (which is also a Google product). It’s just an alternative. Just like building a Java/Swing app for linux isn’t a workaround for the OS windowing capabilities, it’s just an alternative. There are whole game engines (Three.JS) that also render entirely in OpenGL within the browser, that really doesn’t touch any Web API. So overall, i’d actually say its more of a sign that the browser is maturing as a whole, rather than having Compose and Flutter be considered hacks. It’s no longer limited to only HTML

However, I think as companies grow, they tend to end up splitting up their UIs, fitting the native look and feel for each platform.

@Ayfri if you want your solution to be multiplatform on the future, AFAIK, you should be writing using components from

androidx.compose.material.*

instead of

org.jetbrains.compose.web.dom.*

DOM based components will never work on android/desktop/ios, its the other way around. Dom components only work when inside

renderComposable

and canvas components only work inside

onWasmReady

. You can check https://github.com/JetBrains/compose-jb/tree/master/experimental/examples (specially the chat-mpp, which targets most plaftorms) to have a better understanding. CfW canvas is still in early stages but it already works

in my opinion I don't think that the Web DOM Compose will be deprecated anytime soon, there are valid reasons about why it is better to use the DOM instead of a Canvas (example: accessibility, you prefer using CSS instead of canvas, you don't care about publishing the app to Android/Desktop/etc) and afaik the JetBrains' MPP Compose Core/Compose Plugin does most of the "heavy-lifting" of making the ✨ magic ✨ work

Is would suggest naming the 2 solutions

compose-canvas

and

compose-web-dom

or just keep

compose-web

I think there is a world in which a Compose Multiplatform framework uses cross-platform widgets that map to whatever is native on the platform. I don't see anyone working on it though:/

When iOS, macOS and Web Canvas is done you will have a common set of widgets

It's a good start, but it won't look good if it's just a port of Android to the other platforms.

That's what Flutter essentially is, isn't it?

Yeah, and I can't name a single desktop flutter app.

https://flutter.dev/multi-platform/desktop seems like it's officially supported as a target, at least.

The tech is there, there's no question on that. But “barely better than electron” is not enough for a mainstream Compose. Desktop apps are already close to dead...

I'm guessing 99% of cases for Flutter are startups who want to target Android, iOS, and Web though. I sort of assume it would be the same thing for Compose with Web Canvas but I could be wrong.

Yeah that's likely

What is accessibility like on Flutter for Web?

Good question. They support the DOM as well: https://docs.flutter.dev/development/platform-integration/web/renderers

Google takes a11y very seriously, so I imagine it's decent. As opposed to something they forgot about and added after the fact.

It's true that the accessibility tools in Android Compose are great.

I bet Compose too took a11y into account during its early development, so hopefully that core will carry over well to Web and Desktop (but again, not sure at all)

Compose Web will be fine and similar to Flutter Web rendering.

It doesn't depend only on Compose. Most screen readers (citation needed, just what I've heard) heavily use the DOM for accessibility. Bypassing the DOM may make things incredibly hard, whether the team wants it or not.

a11y is definitely already a concern for desktop, with support on MacOS and partial support on windows. https://github.com/JetBrains/compose-jb/tree/master/tutorials/Accessibility Web DOM likely won’t have a11y built-in, because the HTML itself does that. And for canvas, the core widgets/modifiers already have semantic info built-in, so it should be a relatively small effort to just attach that to the platform’s native a11y services.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas#accessibility_concerns

Canvas content is not exposed to accessibility tools as semantic HTML is. In general, you should avoid using canvas in an accessible website or app.

Yikes 😬

:/

(That was probably an old entry -- one of the articles it links to is from 2012. Perhaps things have changed since then)

Google announced a few years back that GMail would be reimplemented using the canvas, so there's definitely a way, but no idea how clean it is

I think that means that nothing in the canvas is automatically accessible. But apps should still be able to talk to the a11y services in general, but it would need to be in addition to whatever you’re drawing in the canvas

Yeah I read it that way too. I'm having trouble searching and finding how canvas accessibility works today.

I have a solution for a11y, maybe it's dumb but I don't know, maybe compose could generate a hidden DOM with exactly the same fields, but everything in a container with

display: none

so it's completely hidden, then the canvas would be there normally, and screen reader could see a DOM exactly like the canvas is

And if Flutter is making their web apps accessible then it should be possible.

Found this snippet in the W3C documentation:

While it is possible for assistive technologies to access these properties directly through the Document Object Model [dom], the preferred mechanism is for the user agent to map the states and properties to the accessibility API of the operating system.

So for browers, they’re primarily not looking directly at HTML for a11y info, but the browers translate the HTML into ARIA info and feed that into screen readers and similar tools. And it looks like there’s a JS API for dynamically providing these ARIA attributes when you can’t/don’t want to use DOM-based attributes https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA

So actually what's going to happen is that we're going to get a cross-platform accessibility system baked into compose?