https://kotlinlang.org logo
#compose-web
Title
# compose-web
a

Ayfri

07/07/2022, 4:37 PM
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
👍 1
d

David Herman

07/07/2022, 4:43 PM
At the moment, I think what you are hoping for (write the UI once, launch on Android, Desktop, and Web) isn't there yet.
c

Cedrick Cooke

07/07/2022, 4:43 PM
Unfortunately, sharing the actual UI layer with web requires heavy use of `expect`/`actual`.
d

David Herman

07/07/2022, 4:43 PM
You'll want to keep an eye out for a future feature where you'll be able to target HTML canvases.
Or, as Cedrick says, you can go pretty crazy with
expect
/
actual
, but it probably won't be trivial.
c

Casey Brooks

07/07/2022, 4:44 PM
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.
d

David Herman

07/07/2022, 4:45 PM
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.
a

Ayfri

07/07/2022, 4:50 PM
Aah I see, and when skia will be there, will actual renderer be deprecated?
c

Cedrick Cooke

07/07/2022, 4:51 PM
I would be shocked if they deprecated the current solution.
d

David Herman

07/07/2022, 4:52 PM
The current HTML / CSS renderer will still be extremely useful even when a canvas renderer is made available.
c

Casey Brooks

07/07/2022, 4:52 PM
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
a

Ayfri

07/07/2022, 4:55 PM
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 ?
d

David Herman

07/07/2022, 4:57 PM
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.
Re: An ETA, I think I read recently that the current situation in Ukraine and Russia has significantly impacted any estimates.
😕 2
a

Ayfri

07/07/2022, 4:59 PM
Ah, so using skia web will be like a workaround instead of a complete solution against current renderer ?
d

David Herman

07/07/2022, 5:00 PM
I wouldn't say a workaround. I think when you have both choices available, they'll be for different purposes.
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.
a

Ayfri

07/07/2022, 5:02 PM
I see, thanks for all the answers ^^
👍 1
c

Casey Brooks

07/07/2022, 5:02 PM
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
👍 2
d

David Herman

07/07/2022, 5:02 PM
However, I think as companies grow, they tend to end up splitting up their UIs, fitting the native look and feel for each platform.
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 🙂.
l

Lucas

07/07/2022, 5:13 PM
@Ayfri if you want your solution to be multiplatform on the future, AFAIK, you should be writing using components from
Copy code
androidx.compose.material.*
instead of
Copy code
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
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
m

MrPowerGamerBR

07/07/2022, 5:22 PM
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
c

corneil

07/07/2022, 5:59 PM
Is would suggest naming the 2 solutions
compose-canvas
and
compose-web-dom
or just keep
compose-web
c

CLOVIS

07/11/2022, 4:41 PM
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:/
c

corneil

07/11/2022, 4:50 PM
When iOS, macOS and Web Canvas is done you will have a common set of widgets
c

CLOVIS

07/11/2022, 5:03 PM
It's a good start, but it won't look good if it's just a port of Android to the other platforms.
d

David Herman

07/11/2022, 5:03 PM
That's what Flutter essentially is, isn't it?
c

CLOVIS

07/11/2022, 5:04 PM
Yeah, and I can't name a single desktop flutter app.
d

David Herman

07/11/2022, 5:06 PM
https://flutter.dev/multi-platform/desktop seems like it's officially supported as a target, at least.
c

CLOVIS

07/11/2022, 5:07 PM
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...
d

David Herman

07/11/2022, 5:07 PM
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.
👍 1
c

CLOVIS

07/11/2022, 5:07 PM
Yeah that's likely
Canvas is going to be hell for accessibility though
I doubt we'll see any major company try it in the coming years
c

corneil

07/11/2022, 5:09 PM
What is accessibility like on Flutter for Web?
c

CLOVIS

07/11/2022, 5:10 PM
d

David Herman

07/11/2022, 5:11 PM
Google takes a11y very seriously, so I imagine it's decent. As opposed to something they forgot about and added after the fact.
c

CLOVIS

07/11/2022, 5:12 PM
It's true that the accessibility tools in Android Compose are great.
I don't think they're available for Desktop Compose yet?
d

David Herman

07/11/2022, 5:12 PM
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)
c

corneil

07/11/2022, 5:13 PM
Compose Web will be fine and similar to Flutter Web rendering.
👍 1
c

CLOVIS

07/11/2022, 5:13 PM
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.
c

Casey Brooks

07/11/2022, 5:17 PM
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.
👍 2
d

David Herman

07/11/2022, 5:19 PM
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 😬
c

CLOVIS

07/11/2022, 5:20 PM
:/
d

David Herman

07/11/2022, 5:20 PM
(That was probably an old entry -- one of the articles it links to is from 2012. Perhaps things have changed since then)
c

CLOVIS

07/11/2022, 5:20 PM
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
c

Casey Brooks

07/11/2022, 5:20 PM
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
d

David Herman

07/11/2022, 5:22 PM
Yeah I read it that way too. I'm having trouble searching and finding how canvas accessibility works today.
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.
☝️ 1
a

Ayfri

07/11/2022, 5:23 PM
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
d

David Herman

07/11/2022, 5:23 PM
And if Flutter is making their web apps accessible then it should be possible.
c

Casey Brooks

07/11/2022, 5:37 PM
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
👍 2
c

CLOVIS

07/13/2022, 4:47 PM
So actually what's going to happen is that we're going to get a cross-platform accessibility system baked into compose?
That's actually so much better than I thought
9 Views