engine VS morphorm

It's not, but I appreciate you sharing this anyway – thank you!

I was referring mostly to GSS: https://gss.github.io/

I think it was an interesting idea that unfortunately didn't really work out. This was before both flex and grid layouts were a thing, so anything new in this space was exciting really. It's a much better css layout world today than it was 8-10 years ago, and particularly grid layout is a very welcome change, but I can't help but think some great ideas have been left by the wayside. Maybe for good reasons, but still.

I'd love to see something like constraint layouts in pure CSS. It's an incredibly powerful tool when building user interfaces.

I was really excited to see GSS (http://gss.github.io), however at the time it was far too slow to be usable in real projects.

It's been a while since I messed with it. IIRC, the way it satisfies the constraints tends to support some really complex adaptive sizing behaviors once you learn to anticipate it. But I never ended up using it seriously, because flex is usually (and possibly always) good enough, and I don't think the web port https://github.com/gss/engine ever saw much adoption. Not completely sure they offered a way of talking about lists of child elements.

I started working Rustycan - a small UI framework that focuses on developer ergonomics and uses other frameworks (such as egui/druid/html) for the rendering, except for the layout which I'm planning to use morphorm.

That said, I'd be interested in migrating towards something closer to the Hierarchy trait that morphorm has pioneered. If this is something that's interesting and important to you could you make an issue?

jkelleyrtp has been experimenting with other UI layout strategies, including SwiftUI. On my end, I really want to see morphorm support (based on subform): initial experiments are promising, and it's "refreshingly simple".

There's a few critical subtasks here: - determine the data flow model we'd like to use for our UI. We'd like to integrate tightly into the ECS, but need to figure out how to reduce the boilerplate and improve reliability around working with hierarchies. - swap our layout library. Our current dependency stretch implements the flexbox algorithm, but is unmaintained and has critical bugs :( The three main options here are to fork flex, move to the new morphorm crate, or write a layout library from scratch - consider rearchitecting our UI to be more flexible and compositional: splitting the massive Style component into several parts and moving to a "UI is a collection of behaviors" paradigm - build out more widgets! - more docs and examples!