State of Bevy UI and what to do about it

[viridia]

I'm going to assume that BSN is not going to be ready for the 0.16 release, at least it seems that's the way the wind is blowing. There are many reasons as to why it's not ready yet (it's a hard problem), that's not what I want to talk about. Rather, I want to discuss short-term strategy.

The situation we are in today is very different from what it was at the time of the 0.15 or 0.14 release cycles. Specifically, a lot of the fundamental building blocks that make up BSN (like relations and the new spawning API) are now in place. This means that it is now possible for third-parties to build "BSN-like" solutions without actually having "official" BSN. In fact some people (like @villor and @NthTensor) have already done so. Similarly, I have used the new APIs to prototype various reactive solutions that are very similar to what @cart has proposed.

Of course, it has always been possible to create UI frameworks as external crates outside of Bevy, but those crates have been quite divergent from the "official" plans for UI. Any user that adopted egui or sickle_ui, and who then later wanted to migrate to BSN, would have a mountain of porting work to do. What's different today is that it's now possible to build a framework that is semantically a subset of BSN, meaning that the work involved in migrating UIs from that hypothetical framework to BSN could be done by a regex. This would provide an effective temporary solution that could be available now.

However, I and others have been hesitant to actually publish these efforts as Rust crates that other people can use. Speaking for myself, I don't want to take on the burden of supporting a library by myself, especially knowing that in 3 or 6 months that library will be totally obsolete. I suspect others feel the same. (I've already abandoned one library as a dead end, and I'd rather not repeat myself).

It has been suggested that such efforts could be checked in to the bevy editor prototype repo, but that too is unsatisfactory; if you have a project that needs UI and which is not an editor, the editor prototype is not a dependency you want to take on.

One notion I've toyed with is a "bevy labs" crate: this would be a repo and crate that would contain various kinds of "bleeding edge" experiments, with a release cycle much more frequent than regular Bevy. This would be unlike third-party crates in that it would be owned by the Bevy organization, have a formal review process, and would have some limited guarantee of support. Individual projects under "labs" might be end-of-lifed because they were no longer needed or deemed unviable; but they would not simply be simply abandoned because the author disappeared. I can think of a number of projects that would fit under a labs umbrella besides UI (such as user preference storage).

[cart]

This would be unlike third-party crates in that it would be owned by the Bevy organization, have a formal review process, and would have some limited guarantee of support. Individual projects under "labs" might be end-of-lifed because they were no longer needed or deemed unviable; but they would not simply be simply abandoned because the author disappeared.

I think the second we have an "official" upstream solution, anything in the "UI labs category" would be shelved (I don't think we should be in the business of maintaining two upstream libraries). From that perspective, if the goal is a UI library that doesn't disappear, it seems like 3rd party is the way, as it could continue to have a life of its own outside of the bevy project for as long as people are interested in using it.