ECS design

[matthunz]

I've noticed quite a few comments mentioning a future refactor to an ECS based design, which I think would be great to bring back! The ECS paradigm seems to fit us well here by making it easy to parallelize our state management and render pipeline.

I think bevy_ecs would be the perfect fit for us, especially since we may be able to integrate with their Accesskit, and Winit support (among other things).

Outline

This sounds like a major change so just to outline the steps I think we could take:

• Replace our current node tree using raw pointers with a bevy_ecs::World, using bevy_hierarchy::Children to maintain the document hierarchy
• Replace the Node struct with a series of components:
  • Components such as Hidden and Hovered can be attached to a node dynamically https://github.com/DioxusLabs/blitz/blob/caa3bbf8f5f0f8080fcf4580fd04468f8321e80b/packages/blitz-dom/src/node.rs#L72-L73
  • Systems can access these components in parallel, running multiple parts of a render at the same time

Finally we may be able to replace our rendering logic with systems, potentially simplifying the crates here and increasing performance. This I imagine could be a longer term goal, but one I think that would come with major benefits.

Sharing more with Bevy

• By using the UICamera with custom UINodes we design for the web we could share code for accessibility, rendering, and running shaders.
  • Another option could be to use bevy_vello as our canvas, letting us re-use more code we currently have
• bevy_winit and bevy_a11y could work well with an ECS-based node hierarchy

[nicoburns]

I'm open to potentially switching to an ECS, but I'm a little wary of it:

• It's a bit architectural shift which probably wouldn't be very easy to undo
• We shouldn't just assume that it will be better. It may well have performance issues and other complexities we haven't anticipated.
• A lot of the benefits of ECS (e.g. parallel processing) don't really apply to tree-traversals which are what Blitz is mostly doing.

I suspect it won't ever make sense to go down the full bevy_ui route. Blitz's DOM is considerably more capable at rendering HTML than bevy_ui, and bevy probably won't want to take on all the legacy code required to implement that. I think we should continue down a route of modular crates where it makes sense (winit, taffy, parley, cosmic-text, accesskit, wgpu, vello, etc - and maybe bevy_ecs), but not attempt to share glue code where we may well want to diverge on the implementation.

[matthunz]

Huh I think I see your points, but I have grown really fond of the Rust + ECS combo. I think it helps with maintainability quite a bit, even if a custom solution like stylo's would probably be ideal, hopefully we can still get close to that multi-threaded performance. I remember chatting about this for Masonry's design and yeah ECS doesn't pair too great with trees, but with systems only accessing what they need and Query::par_iter we can potentially run a lot of our current pipeline concurrently.

IIRC the last few versions of Blitz featured an ECS so I was hoping those comments were indicative we were doing the same here 👀

Also I guess I do agree it doesn't make sense to use parts of bevy_ui. Blitz DOM's capabilities now are something I hope we can preserve doing this change, and bevy_ui might be too hard to bend into shape. I do still think bindings like bevy_vello, bevy_winit, and bevy_a11y would fit well here for the lower level gaps.