Hacker News new | ask | show | jobs
by codeflo 1957 days ago
I’ve recently become interested in immediate mode UIs, and find that there are surprising similarities to React. In both cases, components are just functions that must explicitly render their child components and pass down any shared state. It’s conceptually a very clean way to handle UI state.

However, React introduces a lot of complexity to avoid unnecessary DOM updates, which makes me wonder about the viability of an immediate mode GUI in the browser using canvas.

3 comments

The problem, as always, is how to make immediate mode stuff work with accessibility tools.

The value of essentially creating and mutating a tree structure like the DOM is that things like screen readers and UI automation tools can read it. With canvas they just see a big bitmap.

These are WebGL/WASM based:

- https://github.com/Erkaman/pnp-gui

- https://github.com/jnmaloney/WebGui

I guess accessibility is what takes the biggest hit with these implementations.

I've worked on an app with an IMGUI on canvas. It was amazingly fast and responsive. Nothing which was built after that to try and replace it was anywhere near as performant.
Given how IMGUI is a bunch of branches with code that redraws the same pixels all the time, 60x per second, I'm still surprised this is considered very (if not most) efficient UI. It would imply retained-mode UI frameworks are strongly undershooting their theoretically possible performance.
See for yourself ;)

https://floooh.github.io/sokol-html5/imgui-highdpi-sapp.html

There are also demos for other immediate-mode UI systems on the parent page (Nuklear and microui):

https://floooh.github.io/sokol-html5/

As I wrote in another thread, Immediate Mode UI doesn't imply how the UI rendering is implemented, only how the API works.