[coldtea]

Immediate vs retained is not about "modern" vs "outdated", both are about as old as computer graphics themselves. One is better in some cases, the other in others.

In any case, the fashion (for the last ~10 years) is to consider immediate mode the modern approach, and retained mode an awkward practice of the 90s. So you can call "immediate mode" a lot, but you can't call it "outdated" when most consider it the new black...

[IshKebab]

You're thinking of React and Flutter and so on. They aren't immediate mode. They're more like retained mode with a non-traditional way of keeping the UI state up to date. Very different to egui.

[coldtea]

React and Flutter aren't immediate mode only because they're build on top of the DOM as primitive. Otherwise, conceptually they are evolutions of immediate mode.

And they inspired plenty of GUIs outside the web to go "immediate" mode themselves.

[jcelerier]

Words don't have any meaning anymore if react (and the HTML DOM) is considered anything close to "immediate mode".

For starters the DOM is a declarative thing - immediate mode means that you have a function called for each frame with imperative function calls written by the user of the immediate mode GUI toolkit for rendering each element of the GUI every time (unlike retained mode where a framework hides that behind some object model). It's not really possible to be more opposite to a declarative approach.

[mockery]

Perhaps confusingly, the term "immediate mode GUI" usually describes an API style. NOT an implementation detail.

It suggests a particular implementation, but in practice most nontrivial "immediate mode" GUI libraries (including egui [1] and the famous Dear-IMGUI [2] [3] ) retain some "shadow state" between frames. The existence or scope of that state is a (sometimes-leaky) implementation detail that shouldn't distract from the fact that the API presented is still "immediate mode."

[1] https://github.com/emilk/egui#ids

[2] https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-a...

[3] https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...

[coldtea]

The key point of the comparison is than in React, as in immediate mode, you tell what you want shown every time (for every "frame") as opposed to having references to and controlling instantiated widget objects (an object graph).

In React's case, you tell it declaratively (your JSX component tree) with some procedural stuff thrown in (JS parts in the JSX). In classical immediate mode, by calling paint functions. But in both cases you tell every time - as opposed to performing actions on a pre-created widget graph. With the caveat that in React's case, behind the scenes, there is a widget graph, the DOM. But that's an implementation detail, as far as the dev writing React is concerned, they re-describe every GUI state.

So, you can say that React is an "immediate mode" abstraction over the retained DOM. In fact that's exactly what devs say about it:

https://twitter.com/ibdknox/status/413363120862535680

That's the inspiration from "immediate mode" that React brought - the GUI intention described by creating a new state, as opposed to manipulating state. And the diff algorithm is also inspired by the diffing algorithms used in immediate mode to draw less for each frame.

That React does this with DOM widgets under the hood as opposed to painting commands, and that those are higher level widgets and not lines and rectangles is not the part of the analogy people emphasize.

retained: user instantiated widgets, and changes their state (e.g. to clicked).

traditional immediate: for every 'tick', user issues commands to draw the new GUI state, usually with some smart diffing under the hood to minimize paint commands.

React immediate: for every tick, user describes the arrangement of widgets, text, etc for the next GUI state, usually with some smart diffing under the hood to minimize DOM changes.

Calling a "draw button" function, as opposed to declaring a "<Button>" in a JSX structure, is not that crucial of a difference, compared to the conceptual change between "manipulating objects" and "telling everything about how the UI should look at each tick".

Heck, a dev doing an "actual" immediate mode could trivially wrap the "draw button" function call to be driven from a declarative file (if you parse the term "button": call draw button, etc). It still wouldn't be retained mode.

And React and co also inspired interest in immediate mode GUIs, and inspired some new actual bona-fide immediate mode, with graphic calls and everything.

[IshKebab]

Your own comment makes it pretty clear that React is not immediate mode. Not the immediate mode that everyone understands anyway. Your "traditional immediate" and "react immediate" are just terms you made up.

React is clearly a different thing to immediate mode and retained mode. You don't have to cram everything into those two categories. We could do with a word for it though.

I don't think the guy you linked is a React Dev.

[coldtea]

>Not the immediate mode that everyone understands anyway. Your "traditional immediate" and "react immediate" are just terms you made up.

The terms, yes. The descriptions and understanging of React (as an immediate mode wrapper over DOM) is shared across the community, all the way to Wikipedia:

"One way to have the flexibility and composability of an immediate mode GUI without the disadvantages of keeping the widget tree only in function calls, with the lack of direct control of how the GUI is drawn in the rendering engine would be to use a virtual widget tree, just like React uses a virtual DOM".

What you're arguing is little details about "how things were always done in immediate land" as this was set in stone.

Well, React and descriptions of the UI such as SwiftJS, also shown that you can apply the immediate UI concept to something other than direct drawing calls - namely, controlling a retained mode UI underneath with the same logic you'd call paint functions (or abstract them to "drawButton" and such).

It's not that you're wrong. It's just that you're right about the trees, not the forrest. It's the concept that matters, not the implementation details -- which is like complaining that "Linux can't be UNIX, it doesn't derive from ancient blessed code". Yeah, but it's still UNIX to everybody - and in fact today's de facto UNIX.

>I don't think the guy you linked is a React Dev.

I didn't say he was. In fact it says up there on the tweet he's doing Aurora, and that in that he was inspired from React and its immediate mode approach (he's the guy behind Lighttable/Aurora/Eve).

[pier25]

Flutter on the web uses the DOM?

I seem to recall discussing here on HN with people from the Flutter team how they didn't use the DOM on purpose.

[coldtea]

>Flutter on the web uses the DOM?

Yes. On the web it actually has 2 renderers, a HTML (which uses the DOM) and a Canvas based one (which doesn't).

But I mostly wanted to write about what's the case with React - I just wrote quickly and also kept the reference to Flutter from the parent comment which mentioned them together...

[pier25]

Thanks, I didn't know about the HTML renderer.

Is there any demo online?

[IshKebab]

Flutter isn't built on top of the DOM. And anyway that's not why they're not immediate mode. Take a look at some egui code and you'll see huge differences, e.g. in how button clicks are handled, when code runs, etc.

[coldtea]

>Flutter isn't built on top of the DOM.

The web version has a DOM-based HTML Rendered in addition to a separate Canvas one. So (on the web, where the DOM is applicable anyway, it kinda is).

In any case, I didn't intend to go about Flutter, which I don't use, just wanted to write about React. I mentioned it while answering because the parent comment mentioned them together, and I didn't paid much attention.