Planned platform support?

[rbtcollins]

Just curious what the planned set of platforms to support is? Not when, just which ones you think would/won't fit. I did have a look but couldn't see anything setting out this aspect of the vision.

e.g. Windows GUI?
Console UI's ?
iOS?
Android?

[dhardy]

Web? Although Canvas/WebGL/WebGPU can render custom graphics this is harder to make work with standard tools (like search) and assistive technologies, and probably also has portability and performance issues. Constructing a DOM instead may be possible, but probably Dioxus is a better toolkit if this is your target. So my guess is that it's not worth targetting this in Xilem.

Console UI's ?

I assume you mean Text (TUI). I was thinking about this with regards to KAS and think it would probably be possible (but not trivial, requiring a special theme and text layout), but I also don't see much reason to bother (do you need to run a remote GUI app over SSH?). And, if you want to write a TUI app, why not use the tui crate instead of something much, much more complex (text layout, fancy drawing APIs, etc.)?

[rbtcollins]

I should probably have listed Web yes :).

On TUIs, tui's maintainer has run out of time, and there is a new community maintenance team forming around it, but its not clear what its long term future looks like.

In particular tui has some limitations that it will have to change substantially to address, and in fdehau/tui-rs#654 @fdehau referred to the xilem design as one possible route for those changes to the tui crate.

Will tui evolve to meet those limitations? Or will tui be kept roughly as-is but just updated as dependencies etc evole?

[raphlinus]

This is a deep question, let me answer in a few parts.

First, as a long term roadmap we expect to support Linux, Windows, mac, Android, iOS, and possibly some other embedded-ish platforms. We have Vello running on Android and iOS already. Further, we may support web as a demo platform through WebGPU, but don't expect first-class support. It's not clear that can be done in the "render everything yourself" paradigm.

If you did want to support web, that takes you in a pretty different direction - you need to generate output at a higher level, basically DOM nodes. The Blitz renderer within the Dioxus project shows a potential path, working on a native renderer for apps that generate DOM. I'm watching it.

The Xilem architecture is probably suitable for a very wide range of rendering contexts, but this is speculative and so far basically untested. I'd love to have that idea validated, but at present nobody is working on it that I know, and I don't have bandwidth myself. It can probably generate Web at a high level, probably TUI. It's not specific to having the widgets rendered in a particular way. If this does work, it's not obvious whether it makes sense to have a crate (there are questions about how generic the traits should be, as it's not practical in Rust to make traits generic over other traits). The core architecture is not a lot of code, though that might end up growing if there are a lot of nodes for memoization, handling environment, async plumbing, state management patterns, sparsely diffable immutable data structures for views, etc.

So bottom line, this should all be considered research and exploration. I think there's lots to be learned from adapting the Xilem architecture to a TUI context, but it's still murky how that would play out, and is out of scope for this repo.

[nicoburns]

React Native has an interesting take on web support react-native-community/discussions-and-proposals#496. Not dissimilarly to dioxus/blitz, their plan to a large extent seems to support for web APIs to their platform/renderer.

[lordvcs]

Please support web, just canvas render is fine for a lot of apps(it can be part of a website), stuff llike seo is irrelevant for a lot of these apps. Flutter has a canvas renderer