https://kotlinlang.org logo
#compose-web
Title
# compose-web
n

Norbi

07/04/2021, 7:24 PM
What do you think, would it be a mistake to start a new project using compose-web? Can we realistically expect a production-ready compose-web version eg. in 6 months?
b

Big Chungus

07/04/2021, 7:41 PM
In 6 months? Very unlikely.
😢 2
🙌 1
j

jw

07/04/2021, 8:31 PM
It's already production ready because production ready is, as a concept, entirely subjective and arbitrary
☝️ 1
😆 7
🤨 1
2
💯 5
l

louiscad

07/04/2021, 11:12 PM
Anything can go in production. "Devil" is in the details. In the case of Compose for Web, it's the fact the API is still evolving quite often, and the fact that it lacks the widgets available in Compose for Desktop and Android.
j

jw

07/04/2021, 11:54 PM
The latter is a feature
☹️ 3
👍 1
I hope they never try to emulate that because it's a fools errand
1
😕 3
😡 3
👍 1
c

Colton Idle

07/05/2021, 2:12 AM
To me, reusing composables (the UI) would be a feature, but I'm intrigued as to why not going that route is the right "future" for web. I suppose because web is different, and seo, and a11y and stuff like that?
a

Arkady Bazhanov

07/05/2021, 6:24 AM
The other benefit of HTML renderer is possibility of integration with the existing frontend ecosystem, for example with React.
o

olonho

07/05/2021, 6:55 AM
we hope to release mostly stable HTML API in relatively short timespan (i.e. several months), so if that’s sufficient for your usecases - feel free to use it
🎉 5
👍 5
👍🏻 2
n

Norbi

07/05/2021, 7:04 AM
Thanks, this was the anwer I was hoping for ;)
l

louiscad

07/05/2021, 7:42 AM
I hope they never try to emulate that because it's a fools errand
It doesn't have to be emulation. Some semantic widgets can be adapted for the DOM, while some parts like canvas drawing and gesture recognition can benefit from having a common API for web, desktop and Android (and iOS!).
👍 4
h

hfhbd

07/05/2021, 9:54 AM
Yes, the API is experimental, but the resulting HTML/behavior is stable and works like a charm, I even use Compose Web for a productive application. But I don't share Android widgets, but instead I use Bootstrap.
👍 2
e

epabst

07/07/2021, 4:17 AM
I'd like to use Compose Web with Bootstrap. Do you have any code I can use to get started?
b

Big Chungus

07/07/2021, 6:30 AM
Bootstrap is mainly just css, so just apply right css classes
👍 1
h

hfhbd

07/07/2021, 6:54 AM
@epabst It is just css, but if you want to have some predefined wrappers, you could use https://github.com/hfhbd/bootstrap-compose
👍 1
d

darkmoon_uk

07/10/2021, 5:46 AM
Hey @hfhbd, this looks like an interesting route to me: I'm a mobile/desktop developer with little web experience; but now aiming to write a true web client in Compose/KMM. My main challenge will be layout/styling due to Compose/Web since Compose's own web-widget system barely exists right now. Is this the intent of your bridge to Bootstrap; to make pre-styled components ready via the HTML/DOM side of Compose?
h

hfhbd

07/12/2021, 4:31 PM
@darkmoon_uk This is my idea, as I don't think shared widget are a good UI experience. I experiment with the same idea using SwiftUI, but every device has different input/output possibilities and layout. Mapping touch input from a small screen 1:1 to your bigger window using mouse and keyboard is not the best experience (see Windows 8...) Bootstrap is a well known and good UI library/system for web. Of course you should share your view models, repositories etc.
👍 1
👎 1
d

darkmoon_uk

07/19/2021, 6:24 AM
While I like this library as an option; I'm not convinced that a full-blown, canvas-backed material-Compose widget set for web-browsers wouldn't work TBH. What are some compelling reasons why it wouldn't? The challenge that often gets thrown at full-client running in a browser is SEO, but there are many applications that don't really care about that. From a technical and even UX perspective, why not? The browser as 'just another rich client platform'.
4 Views