3 ms·
Immediate mode is such an outdated approach for a modern UI framework. It's a deal-breaker imo.
by rafale 5y ago
Immediate mode is such an outdated approach for a modern UI framework. It's a deal-breaker imo.
- coldtea 5y agoImmediate 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 5y agoYou'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 5y agoReact 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.
- IshKebab 5y agoFlutter 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 5y ago>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.
- jcelerier 5y agoWords 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.
- coldtea 5y agoThe 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 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.
- pier25 5y agoFlutter 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 5y ago>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 5y agoThanks, I didn't know about the HTML renderer. Is there any demo online?