https://kotlinlang.org logo
Join Slack
Powered by
Cross-posting, if that's OK.
# multiplatform
j
Cross-posting, if that's OK.
t
Well, probably you already know, but I do. 😉 https://github.com/spxbhuhb/adaptive https://adaptive.fun (please use desktop browser for this one, not mobile friendly yet)
K 1
m
Square had a library that used the compose runtime but not UI to build a UI tree, where you then implement visual the nodes using native views. I don't remember what it was called
s
There's also Compose HTML with Kobweb https://kobweb.varabyte.com/
thank you color 1
j
Molecule handles data reactivity, but not actual UI, yeah?
Kobweb is web only, so not qualifying in this case.
Indeed, @Tóth István Zoltán and I already talked about our stuff, though if we had a bigger group I'd be interested in a larger discussion.
s
That's right. Molecule relies on a frame clock for timing, but is otherwise agnostic to UI
t
That was a good talk. I think it is very beneficial to see other approaches to the UI.
j
@Nick Are you the Doodle guy? Want to chip in to a discussion here?
t
Does Koweb have a widget/component library? I'm looking at the docs but don't see anything like that (or most probably I'm just looking at the wrong place).
j
And does anyone know what codeyousef's handle is on here? I want to get a meeting together and some kind of discussion
s
@Tóth István Zoltán Kobweb builds on Silk for the UI layer https://kobweb.varabyte.com/docs/concepts/presentation/silk
👍 2
h
@Michael Krussel it’s called redwood and uses native platform views for the UI: https://github.com/cashapp/redwood
👍 2
j
It looks like 
redwood
is still active? I can't find a demo of it.
@jw you work on Redwood, correct? Is the project active and intended for public use? Are there any sample projects hosted for web that we can look at?
@hfhbd do you know much about redwood? Can you answer the questions above?
s
There's a #C5HT9AL7Q channel as well, if you'd like to reach a wider audience
n
yep #C01CJM07MGV is one that i actively maintain
j
Yes Redwood is active. No you probably shouldn't use it.
thank you color 2
h
I only read the readme of redwood, but I don’t think it is used outside of Cash App, at least the majority of issuers are employees of Cash. The „need“ for a design system and the nice built-in solution for remote code updates are mostly requirements from cash and not used by other people/companies.
j
Yeah it requires a few weeks or months of upfront work before it's usable in practice.
h
Still nice to open source it :)
j
Totally. I actually got yelled at once by (incompetent) managers for "working only on open source" because I spent all my time building it. So fun to have to explain to these people that it's the thing they told me to build and its code ships in the app exactly the same whether it's open or not.
thank you color 2
😆 1
j
Oof. Feel lucky that I haven't had to deal with anything like that, despite working on the project at my job.
r
I think #C04QPSCQ39T is also kind of multiplatform UI
j
@CLOVIS That's yours? Any thoughts on the parent post?
c
Decouple isn't actively maintained at the moment. It's been waiting for years for context parameters. Now that they're there I guess it could start again
Sorry what's the question here? Are you making a list of all existing frameworks?
j
Yes, and trying to see if there are efforts that could be joined together. I'd prefer to work with someone else outside my company if possible.
👍 1
c
Ah I see. Well, that was the point of Decouple actually 😅 Decouple tries to be a thin API layer that can be used on top of any other Compose-based framework. My initial goal was to create a component library that could be used both from Compose Multiplatform and also from Compose for Web (without look and feel differences, but with the same semantics).
The initial goal of Decouple was that if someone created a GTK Compose-based implementation for native Linux, and someone else created a Composed-based JS framework, etc… you could use Decouple to use them all in a single shared codebase. However, I started the project too early when there were no other existing Compose-based frameworks, so I had to create my own components, and it turns out I'm not very good at that
@David Herman and @Letter (#C04RTD72RQ8) may want to chime in here too
j
While I don't care for the Compose methodology for reactivity personally, I might be willing to give it up in an effort to just make KMP actually useful for multiplatform projects that include web. (in React vs SolidJS, I pick SolidJS every time)
Mine (KiteUI) is solidly in the, well, Solid camp. In fact, it's original name was Rock because it was based on Solid.
c
Most components in a UI framework do very little state management. Maybe there's a lightweight way a component could be used from either.
j
KiteUI is actually mostly divorced from the preferred reactivity system already, but it might be difficult to bridge. Worth looking into for sure
d
@Tóth István Zoltán Kobweb has Silk. At the moment, we have a small handful of widgets, but filling that widget library out will be our next push. I will also add a section for widgets in the docs site in the "near" future too. Sorry that it's not in place quite yet! EDIT: Sorry @Seri just saw you already posted this for me above. Thank you!
j
That answers for web components, at least!
d
@joseph_ivie I'm glad you're trying what you are trying, and I genuinely hope you find something that allows a true cross platform experience while still feeling good on native web. My goals were indeed different. I had fallen in love with Compose HTML and just wanted to make it nicer to use. I spent a few weeks exploring the idea of making it work in a cross platform way, but the native web feature set was just too overpowering, so I ended up leaning all in on HTML / CSS instead. My own general advice to users has been to share business logic with multiplatform but have a custom UI for web.
🙌 3
j
I mean, it's working well already. KiteUI is used in production here at our company and it runs great on mobile and on web. I'm just tired of working alone. We need support, or perhaps to join someone else. In addition, since we're a software development contractor, our clients are always wanting more confidence that whether their codebase lives or dies isn't wholly dependent on us.
We're just a team of about 10, and of those, there are about 5 of us who know enough to actually work on the library, and most of us need to spend time on actual client work.
d
Can you easily integrate third party JS libraries in your KiteUI?
j
I mean, since it's using entirely vanilla JS stuff and vanilla elements, yes, just as it is for any good KMP JS project
d
That's nice!
Do you have a link to a public site that uses KiteUI?
j
We embedded Google Maps with path drawing not too long ago for one of the projects. The JS actual is less than 300 lines, and it's doing some drawing of paths and markers so its no slouch.
hold on, thinking through some others
gotta think through disclosure rules too
https://app.repsauditready.com/login-explanation is undergoing public beta testing; it's our own so I can disclose that
bit rougher around the edges since it's early
https://app.vandenbussche.com/auth/login These guys have an app, but it's private login for their customers.
I don't have explicit permission for several others to share, so I'll hold off on those
d
No worries, thanks for sharing what you could. I didn't actually go through the registration form on the REPS site, not sure if you'd want random Kotlin strangers banging on the door during testing 🙂. So I can just see the login screen.
j
Ha, appreciated.
I really would like feedback on the library if you have any, btw. Presentation in GitHub, design, etc.
d
With Kobweb, I didn't have to worry too much about the core API design, since that was just Compose HTML. Beyond that, I focused on connecting with people who had pain points that Kobweb could solve. Portfolio sites, landing pages, things like that. It looks like KiteUI is doing some stuff with minus operator overloading, which results in concise code but also maybe a syntax that feels kind of alien to new users? I think that might be your biggest obstacle, but you would need to ask others to confirm. (As an aside: Compose in its early days tried to do some operator overloading with unary plus actually but they removed it eventually. Random search results here but see also https://www.reddit.com/r/androiddev/comments/dmd1ua/jetpack_compose_similar_to_flutter_ui_why_a_new/ and https://stackoverflow.com/questions/58571670/whats-the-meaning-of-plus-sign-before-a-kotlin-method. These days code looks more like 
var x by remember { mutableStateOf(...) }
instead)
j
The dash operator overload was controversial inside our group, as well. Once we got to large codebases though it became a clear winner for readability. You're right though, that's really foreign and I've heard that same response from some others.
d
Worth stating that Kilua uses unary plus though so I bet @Robert Jaros could provide a good counterpoint here.
t
I think that discussion about any UI framework has to address the elephant in the room as well: AI code assist. This area advances very fast and it will be basically impossible to create any viable framework without paying attention to how AI works. I personally bet on voice controlled software which can change itself during runtime according to the instructions of the user. UI will act as an MCP server and most UI will incorporate a prompt. When the user says something like “change the color if the second column to red” the UI should be able to perform that operation. This is one of the basic concepts why I decided to build one from scratch, without relying on Compose which I feel is not well suited for this (I might be wrong, I’m admittedly no Compose expert.)
c
I work with customs and insurances, there is no way such a framework could ever get adopted here
j
@Tóth István Zoltán I've been thinking a lot about that too. Since we have some larger codebases, we've been trying Junie on some of this stuff. I've been impressed at how well it figures it out. It's certainly not perfect though.
@CLOVIS I believe it, but why? I just want to understand what my library is really missing and where its misses are.
d
@Tóth István Zoltán That's a really interesting point and honestly, I feel like if web truly goes the way of AI code assist, I think that JS/TS may simply win 🙂 But I try not to worry about what I can't control. Also, if we're imagining a future where AI gets much better, there's no reason to think it won't be able to learn any framework near instantly and provide good advice on how to use it.
t
@CLOVIS I’m not sure about that to be honest, it will be a real competitive advantage to have AI support.
c
(@joseph_ivie: I was talking about the AI-user-changes-behavior-live idea)
j
AH that makes more sense! Lol
c
Your framework wouldn't be used here, but that's just because they're scared of Kotlin on the browser 😐
🫤 1
j
Ironic, since you're the guy whose made Kotlin in the browser bearable for us
K 1
😅 1
c
it means a lot to me that I've managed to convince at least one person lol, I haven't been very successful IRL
t
@joseph_ivie It depends on us if Js wins or not. I’m already able to generate actual Kotlin UI code that is non-trivial and works with minor fixes.
j
You're referring to David's comment about AI making TS required, right? I hate it, but I agree with it. It's incredibly frustrating to me.
🤝 1
t
Of course, I’ve spent a lot of time writing documentation for AI.
j
Same here. Junie doesn't completely screw up writing UI now thanks to some in-progress .junie/guidelines for KUI.
t
Imho Kotlin on Js is not successful atm because of lack of component libraries.
c
Just throwing this out there, but if we do want to try to get multiple library authors to talk together and share ideas, it's possible JB would give us our own channel dedicated to this. This thread is already starting to become quite messy
something like 
#javascript-library-development
j
Agreed, though I'm not here just for the JS. Not sure who the right person to reach out to is though.
c
That would be Alina Dolgikh in #C0B8W32VA I'd think, but let's discuss this a bit more before we make a request
Personally, JS interop was the main reason I switched from Java to Kotlin initially (~2017). In 2022 I had a Kotlin React app in production, and all my libs and plugins are stuff I needed then. Since then I'm employed at a company that doesn't do KJS, so nowadays I spend more time on server-side library development and I don't do much UI anymore. Still, the Vite plugin works and is waiting for more testing to be marked stable, and I plan on continuing to maintain it for whoever needs it. Having a shared discussion place for all of us to update on each other's work would be quite nice, there is a lot to do that would benefit all of us
For example, one of the blockers for KJS I've heard in local meetups is the lack of a good cross-platform i18n library. That's probably the kind of things we could develop together and integrate back into each of our projects
👍 1
j
Agreed
c
I don't believe in having a single UI framework that does everything because I don't believe it's possible to cater to all use-cases in a single unified design, but sharing small pieces like this and making sure they're as good as possible sounds like the way to go
"offloading work to a web worker" is definitely another of these things that is painful today but could be made much simpler. Kobweb and Seskar both have helpers for it with different pro & cons, there's probably something to do here
Also, being unified gives us more visibility when talking with JetBrains
j
I don't believe in having a single UI framework that does everything because I don't believe it's possible to cater to all use-cases in a single unified design
Well, never every use case, but I think the vast majority of use cases is quite possible. It'll never be perfect, since the native libraries are arguably always the best for the platform. But I do think that using the same definitions (row, column, image...) for all targets is still quite reasonable and should be able to deliver a very decent result. I still think it's reasonable to target web static, web SPA, SSR, mobile, and desktop.
But yes, I agree with your other points most certainly and would love a place to talk about it
c
@Robert Jaros what do you think? From what I understand, you're the closest to this so far, having SSR and everything
r
I'm definitely a web-only person. Never played with mobile development so I think my point of view is very biased. But I've noticed many devs think of web target as most limited and I fundamentally don't agree with this 🙂 For me the other targets (mobile, desktop) are limited and making a framework multi-platform automatically imposes limitations on what can be achieved for the web. The frameworks like KiteUI or Adaptive (or CMP as well) look really amazing and the amount of work put into them is very impressive but I personally probably wouldn't use any of them for my own, web-only projects. Because I feel they are putting constraints on the web target.
💪 1
j
I mostly agree with that take - if you're not targeting all of the targets, why bother? But also: KiteUI has a (granted, untested) way of explicitly using direct HTML tags when targeting an HTML-based target to specifically try to not limit that. However, fundamentally, the more platforms you target by definition the more capability the library must take away.
Making a library to target every platform has been difficult to say the least - if I weren't both a mobile and web developer before starting the project I think it would have gotten really messed up after targeting another platform.
d
You can see my own spicy take here: https://bitspittle.dev/blog/2024/c4w#shared-ui-is-overrated but at the same time I'm glad I can work on a project that is web only and Kite can provide a good cross platform solution and then the community can choose what's best for their own requirements.
j
Makes sense, but the whole point of KMP is that we can drop into the target platform when we want to do something platform-specific; I think the problem is that C4W is trying to cover too much ground by replacing the rendering system, which results in massive amounts of duplication of work and an inability to use platform-specific features. If a UI library doesn't get in the way of that, however, and just bridges the gap to native UI components, I think KMP can be leveraged properly to share what can be shared and implement what can't be on a per-platform basis.
👍 1
d
That might indeed be true! Most of the points I make in that post are relevant to CMP, whereas Kite would probably handle them well.
And yeah a lot of the issues stem from forcing an opaque rendering pipeline, so it's really nice you're coming at it from a different direction
Note that your challenge vs Compose is you have to sign up for strong desktop, iOS, and Android support as well, including learning materials and example projects.
j
Yep. I feel like my band of 10 is shaking sticks at a full army. But I also feel like what we're doing is the right approach. The only platforms we don't have yet are SSR and Desktop, and SSR is ~80% complete because I abstracted the vast majority of the JS backend to a common module with the JVM for forming HTML elements.
That's why I'm being so loud here right now though. Unless I can get others to at least view the approach as possible and even good, we're sunk from the start. I'm really hoping to find others who are interested in working on the problem for that reason. I could willingly abandon KiteUI, but I want to try and at least work with someone on using the same general approach.
👍 1
d
Yeah I feel you. I think it could be great if you could find people who went all in with CMP / wasm and ask them 1:1 if they would have preferred using Kite retroactively instead
I think a big hurdle might be how beloved (I think) Compose is on Android. Because I assume the main cross platform case you're aiming for is web + mobile.
j
Exactly. You're seeing all of the same problems I'm hitting.
👍 1
d
I think on web you'd get people willing to try Kite, but Android may be more baked in? Your huge selling point is great web output but I don't think most mobile devs would be aware of that until it's too late. I know I was ignorant of all this just a few short years ago.
But yeah to start probably you'll need to lead: make a handful of great open source projects, small in scope is fine, and bang the drum about them
Also I'll stop talking now because your original goal was to connect with other devs here and you have an exciting project, so let me get out of the way!
j
Thank you so much David. The thing is I haven't really tried reaching out to others to consider the library and the approach until this thread - knowing that there's at least someone out there who believes in the approach helps more than you know.
🤝 1
👍 1
Open in Slack
PreviousNext
Powered by