https://kotlinlang.org logo
#compose
Title
# compose
g

gaetan

05/15/2019, 8:46 AM
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?
r

ribesg

05/15/2019, 8:48 AM
Are you asking if we could go back to writing XML?
🚫 6
g

gildor

05/15/2019, 8:50 AM
it sounds more like some kind custom rendering output
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?
g

gaetan

05/15/2019, 8:54 AM
I was thinking of this kind of code:
Copy code
@Composable
fun DIV.comment(model: Comment) {
    div("comment") {
        div ("comment-header") {
            + model.username
        }
        div ("comment-content") {
            + model.content
        }
    }
}
r

ribesg

05/15/2019, 8:54 AM
Well that’s basically
kotlinx.html
then, isn’t it?
g

gaetan

05/15/2019, 8:54 AM
We don’t want another flash.
g

gildor

05/15/2019, 8:55 AM
Why?
I want another flash!
g

gaetan

05/15/2019, 8:55 AM
Yes, using a Compose framework with a DOM.
g

gildor

05/15/2019, 8:55 AM
flash was great! And I only now realising this
g

gaetan

05/15/2019, 8:55 AM
For the web we should use the standards.
g

gildor

05/15/2019, 8:55 AM
I’m not sure that it will be good enough with DOM, compose renders on each frame
g

gaetan

05/15/2019, 8:55 AM
A lot of reason for.
g

gildor

05/15/2019, 8:56 AM
For the web we should use the standards.
Yes,
<canvas>
!
g

gaetan

05/15/2019, 8:56 AM
SEO is one of it.
g

gildor

05/15/2019, 8:57 AM
Unhandled JavaScript exception: kotlin is not defined
😭 1
g

gaetan

05/15/2019, 8:57 AM
I use canvas for dataviz but I want to keep the page as a linkable and parseable page.
g

gildor

05/15/2019, 8:58 AM
make sense. good reason
g

gaetan

05/15/2019, 8:58 AM
kotlin js was not loaded?
This is what you should have
g

gildor

05/15/2019, 9:00 AM
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
👍 1
just a humble opinion
l

louiscad

05/15/2019, 9:06 AM
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.
g

gildor

05/15/2019, 9:06 AM
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
l

louiscad

05/15/2019, 9:07 AM
@Adam Powell could probably provide his insights for that, or find the right team member.
g

gildor

05/15/2019, 9:08 AM
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
g

gaetan

05/15/2019, 9:08 AM
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.
2
g

gildor

05/15/2019, 9:15 AM
Also Compose already has adapter for Android Framework views, which is similar to support some sort of DOM adapter
t

themishkun

05/15/2019, 9:30 AM
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
i

itnoles

05/15/2019, 2:16 PM
DOM parser is just like XML, no.
l

Leland Richardson [G]

05/15/2019, 3:58 PM
@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
if you wanted to do something server-side only, you could probably get to something useful in a hundred lines of code or so.
my hope is that someone tries to do this with ktor at least
another interesting target IMO would be this library: https://kweb.io
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
g

gaetan

05/15/2019, 5:05 PM
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?
l

Leland Richardson [G]

05/15/2019, 6:24 PM
well, i haven’t tried so maybe it is easier than i’m giving it credit 🙂
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
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
g

gaetan

05/15/2019, 10:03 PM
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.
l

Leland Richardson [G]

05/15/2019, 10:28 PM
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
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.
g

gildor

05/16/2019, 12:28 AM
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
l

Leland Richardson [G]

05/16/2019, 12:31 AM
i think long-term it will be, i think right now i agree with you
also, last time i checked out kotlin JS, DCE didn’t work very well (or was even nonexistant?). i guess it has improved significantly?
i’d be curious for instance to try compiling the compose runtime to JS and seeing how big the output is
including the kotlin runtime
g

gildor

05/16/2019, 1:02 AM
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
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 '
l

Leland Richardson [G]

05/16/2019, 2:05 AM
ah i see. that’s great context, thanks! I haven’t explored the kotlin -> llvm -> wasm pipeline so this data is definitely helpful.
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
👍 5
s

sdeleuze

05/16/2019, 5:13 AM
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.
2
j

jim

09/24/2020, 2:30 PM
@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.
👍 1
s

shikasd

09/24/2020, 2:38 PM
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! :)
🔥 5
👍 2
K 4
m

Marc Reichelt

09/24/2020, 9:35 PM
Thanks a lot @jim and @shikasd - that looks really interesting! Honestly, that looks much more promising than I thought 🙂
I will dig through the CL first to get a bit familiar, and ping @shikasd again when I want to take this further
👍 1
l

louiscad

09/25/2020, 7:33 AM
Would be cool to have Slack handle "remind me about this when Kotlin 1.4.30 is released".
K 2
6 Views