a

    Ayfri

    2 months ago
    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

    David Herman

    2 months ago
    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

    2 months ago
    Unfortunately, sharing the actual UI layer with web requires heavy use of expect/actual.
    David Herman

    David Herman

    2 months ago
    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

    2 months ago
    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

    David Herman

    2 months ago
    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

    2 months ago
    Aah I see, and when skia will be there, will actual renderer be deprecated?
    c

    Cedrick Cooke

    2 months ago
    I would be shocked if they deprecated the current solution.
    David Herman

    David Herman

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

    Casey Brooks

    2 months ago
    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

    2 months ago
    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

    David Herman

    2 months ago
    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.
    a

    Ayfri

    2 months ago
    Ah, so using skia web will be like a workaround instead of a complete solution against current renderer ?
    David Herman

    David Herman

    2 months ago
    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

    2 months ago
    I see, thanks for all the answers ^^
    c

    Casey Brooks

    2 months ago
    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

    David Herman

    2 months ago
    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 🙂.
    Lucas

    Lucas

    2 months ago
    @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
    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

    MrPowerGamerBR

    2 months ago
    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

    corneil

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

    CLOVIS

    2 months ago
    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

    corneil

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

    CLOVIS

    2 months ago
    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

    David Herman

    2 months ago
    That's what Flutter essentially is, isn't it?
    c

    CLOVIS

    2 months ago
    Yeah, and I can't name a single desktop flutter app.
    David Herman

    David Herman

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

    CLOVIS

    2 months ago
    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

    David Herman

    2 months ago
    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.
    c

    CLOVIS

    2 months ago
    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
    corneil

    corneil

    2 months ago
    What is accessibility like on Flutter for Web?
    c

    CLOVIS

    2 months ago
    David Herman

    David Herman

    2 months ago
    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

    2 months ago
    It's true that the accessibility tools in Android Compose are great.
    I don't think they're available for Desktop Compose yet?
    David Herman

    David Herman

    2 months ago
    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

    corneil

    2 months ago
    Compose Web will be fine and similar to Flutter Web rendering.
    c

    CLOVIS

    2 months ago
    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

    2 months ago
    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

    David Herman

    2 months ago
    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

    2 months ago
    😕
    David Herman

    David Herman

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

    CLOVIS

    2 months ago
    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

    2 months ago
    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

    David Herman

    2 months ago
    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.
    a

    Ayfri

    2 months ago
    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

    David Herman

    2 months ago
    And if Flutter is making their web apps accessible then it should be possible.
    c

    Casey Brooks

    2 months ago
    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
    c

    CLOVIS

    2 months ago
    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