There are a lot of interesting concepts in this pr...

# compose

[gaetan]

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?

[ribesg]

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

[gildor]

it sounds more like some kind custom rendering output

[gildor]

Canvas has own abstraction, so in theory it may be possible, but i’m not sure that HTML is good option for output, why not use <canvas> directly?

[gaetan]

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

[ribesg]

Well that’s basically kotlinx.html then, isn’t it?

[gaetan]

We don’t want another flash.

[gildor]

Why?

[gildor]

I want another flash!

[gaetan]

Yes, using a Compose framework with a DOM.

[gildor]

flash was great! And I only now realising this

[gaetan]

For the web we should use the standards.

[gildor]

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

[gaetan]

A lot of reason for.

[gildor]

For the web we should use the standards.

Yes, <canvas>!

[gaetan]

SEO is one of it.

[gaetan]

Here for example: https://beta.data2viz.io/pierre/sketches/KGJZpL/view/

[gildor]

Unhandled JavaScript exception: kotlin is not defined

[gaetan]

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

[gildor]

make sense. good reason

[gaetan]

kotlin js was not loaded?

[gaetan]

This is what you should have

[gildor]

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

[gildor]

just a humble opinion

[louiscad]

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.

[gildor]

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

[louiscad]

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

[gildor]

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

[gaetan]

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.

[gildor]

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

[themishkun]

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

[themishkun]

https://kotlinlang.slack.com/archives/CJLTWPH7S/p1557843982187300?thread_ts=1557822636.174800&amp;cid=CJLTWPH7S

[itnoles]

DOM parser is just like XML, no.

[Leland Richardson [G]]

@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

[Leland Richardson [G]]

if you wanted to do something server-side only, you could probably get to something useful in a hundred lines of code or so.

[Leland Richardson [G]]

my hope is that someone tries to do this with ktor at least

[Leland Richardson [G]]

another interesting target IMO would be this library: https://kweb.io

[Leland Richardson [G]]

it seems like it would be a fairly easy target for compose, and could simplify some of the primitives that this library uses. since it’s all server side you wouldn’t have much trouble setting it up on top of the work they’ve already done

[gaetan]

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?

[Leland Richardson [G]]

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

[Leland Richardson [G]]

i think long term targeting wasm is an approach that could actually have some legs, but not sure what it would entail at this stage of wasm and host bindings and stuff like that

[Leland Richardson [G]]

targeting js could “just work” right now with a little bit of finesse. not sure how optimal compose’s runtime would be for a JS VM, but would be interesting to see. The problem with kotlin JS in my mind is just that the kotlin runtime is probably going to be prohibitively large for most web projects

[gaetan]

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.

[Leland Richardson [G]]

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

[Leland Richardson [G]]

btw, i’m saying these things but just to calibrate expectations properly me saying it is not necessarily an indication of whether or not something along these lines would be accepted as a contribution into AOSP.

[gildor]

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

[Leland Richardson [G]]

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

[Leland Richardson [G]]

also, last time i checked out kotlin JS, DCE didn’t work very well (or was even nonexistant?). i guess it has improved significantly?

[Leland Richardson [G]]

i’d be curious for instance to try compiling the compose runtime to JS and seeing how big the output is

[Leland Richardson [G]]

including the kotlin runtime

[gildor]

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

[gildor]

See this message and the whole thread:
https://kotlinlang.slack.com/archives/C0B8L3U69/p1554889049041700?thread_ts=1554827960.039400&amp;cid=C0B8L3U69

[gildor]

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

@Leland Richardson [G] I’m talking not about Wasm in general, but about compilation to Wasm using LLVM and K/N, it’s quite slow and not really efficient (compile to CPU-specific bitcode and then convert it to VM representation)
But if one day we will have Kotlin for wasm it would be completely different story
And of course when wasm will evolve and get more features. This discussed quite a lot in channel #webassembly '

[Leland Richardson [G]]

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

[Leland Richardson [G]]

if hello world is 60-80kb that’s not the end of the world and certainly a much better state of the world than i thought. back to the original of the thread: compose (when it’s stable at least) i think could sensibly target the DOM

[sdeleuze]

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.

[jim]

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

[shikasd]

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! :)

[Marc Reichelt]

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

[Marc Reichelt]

I will dig through the CL first to get a bit familiar, and ping @shikasd again when I want to take this further

[louiscad]

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