Hacker News Reader

Comment by dreta | Hacker News Reader

It's worrying how sometimes the most basic programming concepts can appear revolutionary to web developers. So much so, they've recently stumbled across the concept of a read input-update-render loop, and are now trying, with frameworks like React, to contort the DOM tree, just to get back to how UI was programmed since decades.

There's a fairly old concept called "immediate mode UI", which even gets rid of the tree structure, and keeps the whole state on the user side, giving you full control over when elements are updated and where they are placed. These days it's used mostly in video games, since they already rely on a 60 FPS loop, and the UI complexity tends to be low.

If not for the necessity to use standard platform form elements due to their various quirks and interactions with the system, I'd be doing UI programming only in immediate mode with custom controls, simply because how convenient, and simple it is.

View on HN

Battery life would take a dive if everyone adopted immediate mode UI for apps.

The compromise is something like Win32, where the OS tells you which rectangles in your app to repaint so most of the time you're not doing anything.

Both of which are a ton of code if all you want to do is display a list of TODO's with custom styling vs. <li> in markup.

The rate at which you have to update, and what you have to update doesn't change between retained and immediate mode. The only difference is that, with retained mode, the library you're using has, by design, all the knowledge it needs, so it can manage all of that for you. The whole point of using immediate mode is to get rid of this black box from your program, so that you can explicitly state what you want to happen, when, and in what order. It's only "a ton of code" if you write everything from scratch, so i fail to see how that's an argument.

I'm using "immediate mode" to mean:

    while (true)
    {
         processInput()
         updateState()
         paint()
    }

That will kill battery unless you write code to not update until input or app state changes, in which case you're building up to your own retained-mode system.

Yes, if you were concerned about battery life, you'd typically not update until input or app state changes.

As for building up to your own retained mode system: not really, at least not in my view. Whether you update at a constant rate, or update only in response to user input (or whatever), you're still doing the key things that differentiate immediate mode-type GUIs from retained mode-type GUIs: firstly, you're regenerating the entire UI from scratch each time; and secondly, you're handling the input events while doing the regeneration.

This is what makes immediate mode-type GUIs so easy to use in many cases. You never have to make sure each widget is linked up with whatever it relates to, and you never have to ensure the widget list is kept in sync with the list of things, and so on. You're always building the widget list from the (authoritative) list of things, and processing the related input events at the same time.

>not update until input or app state changes

That's the hard part that callbacks try to make easier.

Immediate mode is simply a way of designing your API so that there's no creation, destruction, callbacks, etc. It's a convenience to the programmer, because they can explicitly express what they want to happen at a given moment, and the application state is known at any given time. It's a general concept that can be applied to any code you write, and it most certainly doesn't forbid you from keeping track of dirty regions between frames, that would be ridiculous.

I don't know how many times my colleagues and I have half-jokingly suggested just throwing out most HTML and CSS and just draw everything to a canvas.

I'm currently working on an web ide that use the Canvas instead of the DOM. The Canvas is very nice to work with, it's high level and hardware accelerated.

Well, that is the approach of the new Fitbit smartwatch.

It makes use of only SVG, CSS and JavaScript.

The Canvas is much more fun and easier to work with then SVG though.

Reply on news.ycombinator.com