I have a question, how compose for web can be used for multiplaform ? As you create HTML components ...

# compose-web

[Ayfri]

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

[David Herman]

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

[Cedrick Cooke]

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

[David Herman]

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

[David Herman]

Or, as Cedrick says, you can go pretty crazy with expect / actual, but it probably won't be trivial.

[Casey Brooks]

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.

[David Herman]

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.

[Ayfri]

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

[Cedrick Cooke]

I would be shocked if they deprecated the current solution.

[David Herman]

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

[Casey Brooks]

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

[Ayfri]

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 ?

[David Herman]

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.

[David Herman]

Re: An ETA, I think I read recently that the current situation in Ukraine and Russia has significantly impacted any estimates.

[Ayfri]

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

[David Herman]

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

[David Herman]

I think a canvas renderer solution could help startups use Kotlin multiplatform as a tool instead of Flutter, which is currently a very popular approach for new companies ramping up quickly trying to hit many platforms at the same time with a single codebase.

[Ayfri]

I see, thanks for all the answers ^^

[Casey Brooks]

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

[David Herman]

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

[David Herman]

For me, I started building on a blog site, and a traditional web target is way more appropriate for me than a canvas solution, since I don't want to allocate a giant canvas buffer to essentially render mostly text. And I have no intention to port that blog to any other platform -- instead, the browser itself is the "multiplatform" component 🙂.

[Lucas]

@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

[Lucas]

As other said, you can still share business logic, but if you want t o share UI code you cant do it with dom components

[MrPowerGamerBR]

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

[corneil]

Is would suggest naming the 2 solutions compose-canvas and compose-web-dom or just keep compose-web

[CLOVIS]

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:/

[corneil]

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

[CLOVIS]

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

[David Herman]

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

[CLOVIS]

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

[David Herman]

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

[CLOVIS]

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...

[David Herman]

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.

[CLOVIS]

Yeah that's likely

[CLOVIS]

Canvas is going to be hell for accessibility though

[CLOVIS]

I doubt we'll see any major company try it in the coming years

[corneil]

What is accessibility like on Flutter for Web?

[CLOVIS]

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

[David Herman]

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

[CLOVIS]

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

[CLOVIS]

I don't think they're available for Desktop Compose yet?

[David Herman]

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)

[corneil]

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

[CLOVIS]

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.

[Casey Brooks]

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.

[David Herman]

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 😬

[CLOVIS]

:/

[David Herman]

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

[CLOVIS]

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

[Casey Brooks]

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

[David Herman]

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

[David Herman]

But ultimately if it's possible, then I think you just use Compose for Web Canvas and even if a11y doesn't work initially, in theory it will work someday later and you won't have to change any of your code.

[Ayfri]

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

[David Herman]

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

[Casey Brooks]

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

[CLOVIS]

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

[CLOVIS]

That's actually so much better than I thought