There are a lot of interesting concepts in this project. I have a question regarding View technology. In the current code, as I understand it, the view part is an entirely new one, using only canvas to draw elements on it. However, the building of UI through this kind of code could be attractive in existing contexts. Do you think it would be possible to have something similar with a binding mechanism on an existing technology like, let’s say, HTML?

Are you asking if we could go back to writing XML?

it sounds more like some kind custom rendering output

I was thinking of this kind of code:

@Composable
fun DIV.comment(model: Comment) {
    div("comment") {
        div ("comment-header") {
            + model.username
        }
        div ("comment-content") {
            + model.content
        }
    }
}

Well that’s basically

kotlinx.html

then, isn’t it?

We don’t want another flash.

Why?

Yes, using a Compose framework with a DOM.

flash was great! And I only now realising this

For the web we should use the standards.

I’m not sure that it will be good enough with DOM, compose renders on each frame

A lot of reason for.

For the web we should use the standards.

Yes,

<canvas>

!

SEO is one of it.

I use canvas for dataviz but I want to keep the page as a linkable and parseable page.

make sense. good reason

kotlin js was not loaded?

In general I think it’s kinda possible, but it’s too early probably discuss it, but if one day we will have MPP version of compose it should be one of the options for sure

Compose will have what they currently call "semantics" which will be used for accessibility purposes, and probably standarization too. That could help expose information to external systems, including SEO so we don't have to change the way we render just because of search engines. Also, I think you can already use schema.org for SEO without using DOM as a SEO hack.

But I think community should investigate this use case first, maybe @gaetan with experience work on dataviz should try to investigate and notify Compose team about this

@Adam Powell could probably provide his insights for that, or find the right team member.

But now there is no rendering for browser, so how it should work is open question. After all React uses dom and shadow dom, so it’s definitely possible

I’m convinced, like @sdeleuze, that Kotlin lacks a web framework. It could perform very well inside the browser to replace Angular/Vue/React because of its DSL and tooling capabilities. Seeing this amazing code (the Observe feature in the compiler plugin is just magic) raises questions about how these patterns could work in the context of an HTML binding.

Also Compose already has adapter for Android Framework views, which is similar to support some sort of DOM adapter

Devs mentioned that compose has no notion about which domain it is manipulating. So I think it would be possible to make it cross-platform engine

DOM parser is just like XML, no.

@gaetan compose would work great for creating html. Getting it to work on the client side (with kotlin js or kotlin native -> wasm) would be the real challenge. I think kotlin js would be easier but would not be ready for production, and targeting wasm is probably the better choice but is a more difficult project to bite off

Getting it to work on the client side (with kotlin js or kotlin native -> wasm) would be the real challenge.

@Leland Richardson [G] I don’t understand why. Could you elaborate a little bit?

well, i haven’t tried so maybe it is easier than i’m giving it credit 🙂

Using Kotlin DCE (https://kotlinlang.org/docs/reference/javascript-dce.html) + uglify makes the final JS quite small. I’m not so worried about that. I think the patterns are interesting but the Compose code is really dedicated to mobile. It should more interesting to try a prototype based on these patterns but targeting a web app.

if i were to try and do this seriously, i would probably try to write a hand-crafted JS-optimized version of SlotTable.kt and reference it using expect/actual… but to get something started there’s probably only a handful of

java.*

imports that you’d need to abstract out

kotlin native -> wasm

I don't think that K/N -> Wasm is a real choice for UI code, it's more like proof of concept, or an option to compile you existing native application for web. Until we have wasm backend, Kotlin JS is the only choice for web imo

i think long-term it will be, i think right now i agree with you

DCE didn’t work very well

It works, you have about 60-80kb for hello world, but now Kotlin JS team works on new backend and promise that it allow them implement much better DCE soon

ah i see. that’s great context, thanks! I haven’t explored the kotlin -> llvm -> wasm pipeline so this data is definitely helpful.

For web frontend, there is maybe a need for 2 parallel approaches to cover all the spectrum of web developers needs: - An approach that takes advantage of the DOM by making Web Components first class citizen with a Kotlin/JS version of lit-html - An approach with pixel perfect rendering leveraging Canvas or WebGL rendering, conceptually the successor of Flash and React Native, where Compose would be the ideal solution I am not sure we should run after an ultimate and unified solution, the Kotlin/JS lit-html port seems low hanging fruit, and would avoid to build a new Vue/React/Angular for Kotlin. That would also let the time to Compose for the Web to mature. For long term, a true Kotlin/WebAssembly support that would leverage WebAssembly GC, using Kotlin IR to Bynaryen toolchain instead of LLVM, combine with Compose would be the ultimate combo.

@shikasd Posted https://android-review.googlesource.com/c/platform/frameworks/support/+/1366020 a while ago, looks super interesting. I'm not sure about the current status of that CL, at the very least there are currently some merge conflicts. But if I were looking for a good place to get started, that's where I'd look.

Yeah, currently it is a bit abandoned due to huge amount of changes required. My current plan to split it to more digestible pieces and spend some time working on them without breaking compilation for android 😄 Otherwise, compiler is not ready to address some of the things required by compose, and that is promised to be fixed in 1.4.30 or later. And whenever the compose is running on JS, there's a huge effort required to actually make it useful. Right now I am working on this alone, so any help is welcomed! :)

Thanks a lot @jim and @shikasd - that looks really interesting! Honestly, that looks much more promising than I thought 🙂

Would be cool to have Slack handle "remind me about this when Kotlin 1.4.30 is released".