I think this is really nice for very small systems, but anything near the size of a RPi .. I’m unconvinced.

Building a UI toolkit that works well is really, really hard. The old “last 10% takes 90% of the effort” adage is 10x worse for UI frameworks. The last 1% takes 50% of the time IME. I would much, much rather see good integration with an existing and mature technology like QtQuick. It is declarative, provides all sorts of absolutely wonderful features and flexibility, including the ability to inline OpenGL shaders etc. And it works a dream on small-ish devices that can run a moderately modern OS like Linux, including RPi grade hardware.

Sequential programming of UIs is, outside of special cases like low-level game development, done imho. It is not realistic for the average human developer to produce UIs that fit modern expectations with a sequential API. The need to manage interactions between components, animations, data, etc. is just tool complex. When the more-or-less-static UI paradigm of WIMP started to die, that was really the end of sequential UI programming. For that reason, having a declarative UI system, as seen in QtQuick, is currently the best route.

(Prior to my current focus back on distributed systems, I spent ~15 years doing UI/UX R&D at medium and large companies .. the above is borne of that experience

Like everyone else, excited for this project. Has there been any updates since? Watched this talk a couple of months ago and sort of forgot about it until now. Would love to tinker with it

Love to see the interest. Was just reading the above thread…

Think of it is that it is a retained-mode model specifically designed to take advantage of OTP.

All UI scenes are GenServers. Scenes can reference (embed) other scenes. Input is all message passing/filtering/handling. This also means that developers can build “components”, which are just scenes/GenServers that can be reused by other devs. Nice for extensibility.

Drivers (rendering) are abstracted away from the scenes so that they can be swapped to run on different hardware without re-writing the UI logic. This allows me to run my app on Mac to debug, change a target, and build firmware for a raspberry on Nerves. Everything looks and works the same across the two.

The driver model has also been really good for getting remoting working. More on that later…

A big thing I’m going for is reliability. Devices in the field are going to encounter errors, whether it be code, unexpected data, malfunctioning sensors or whatever. This was harder to get right than I expected, but now any piece of UI can crash and things recover sensibly into a good state.

Multiple people have said they can tell it looks like something someone with game experience would make. Partly that was to get my dependencies down to just OGL. But also because transforms are just a great way to manipulate things.

As far as overall status goes, I’ve stopped adding features and am now focused on the large amount of supporting things around it. (Including stripping out the code from various dead-ends and experiments). I want the API to be pretty stable before it goes out to lots of people.