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?

In 6 months? Very unlikely.

It's already production ready because production ready is, as a concept, entirely subjective and arbitrary

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.

The latter is a feature

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?

The other benefit of HTML renderer is possibility of integration with the existing frontend ecosystem, for example with React.

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

Thanks, this was the anwer I was hoping for ;)

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

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.

I'd like to use Compose Web with Bootstrap. Do you have any code I can use to get started?

Bootstrap is mainly just css, so just apply right css classes

@epabst It is just css, but if you want to have some predefined wrappers, you could use https://github.com/hfhbd/bootstrap-compose

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?

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

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