I remember more than a few arguments here on the forums about the pros and cons of immediate mode UI frameworks, and the general consensus at the time seemed to be that while they were cool for quick demos, various issues around performance and state management meant they were generally not all that useful.

Fast forward a few years (during which I mostly ignored web technologies), and I see that React and it's native aspects have taken over a significant portion of the web and mobile app space. React is, among other things, a pretty straightforward expression of immediate mode UI - you have a stateless render() function that simply describes what should be rendered (and handles state updates), and the framework takes care of manipulating any stateful retained mode backend constructs under the hood.

What I lack is the historical perspective on how this came to be. When did immediate mode make the jump from a handful of game-specific libraries to the mainstream?

When have web developers *ever* made good decisions about technology choices?

Someone decides they want something easy and minimal now, they make it available for the unwashed masses, and it spirals out of control for years.  Wash, rinse, repeat.

4 hours ago, Nypyren said:

When have web developers *ever* made good decisions about technology choices?

Lol.

Web development is the new entry-level programming framework that people are learning nowadays. Coding bootcamps are churning new web developers every month. In the past few years, how many times have they switched frameworks? From Angular 1.3 to 2.x. Now, there are Polymer, React, Vue, among jazillions of many other Javascript/CoffeeScript/TypeScript/CSS/Less frameworks out there, each claiming better and simpler than ever before?

Many times I have felt blessed that it was games that introduced me to programming.

So this "immediate mode" UI is a bad thing then? I'm not a graphics guy. So this is lost on me. If IM is bad, then what should they be using?

My experience with GUIs is that they have a whole lot of state which can be preserved between updates.  If you resize your window, the layout needs to change.  If you move your mouse over a button, there might be a mouse-over highlight.  But if you're not constantly resizing the window, you don't need to redo the layout.  If you're not constantly moving the mouse, you don't need to collision check every button or other clickable element.

Keeping the UI state stored somewhere between updates so that it can be reused is called "retained mode".  Usually there is no choice:  Immediate mode is typically built on top of retained mode, and the code to actually render the GUI is inevitably draw calls.  You can implement a pure immediate mode render-only GUI by just making draw calls, but if you discard layout and input state you end up having to redo all of your layout computations every time you want to render. The issues I've experienced with immediate mode is that the additional wrapper on top of retained mode is inefficient.  If the immediate mode API doesn't include control identifiers, the wrapper layer has to spend time looking these up on each call.

Retained mode GUIs have SEPARATE functions which update just what is actually needed at the moment (layout, mouse rect tests, keyboard input goes directly to whatever control has focus, etc).  And those functions are only called when a change occurs.  Immediate mode GUIs often jam literally everything into one function hierarchy representing the GUI hierarchy, and each individual control's function switches on what is happening (layout, input handling) and adjusts its internal retained mode state.  The problem is that these APIs typically traverse the entire call hierarchy even if you don't need to, because they use the call order to determine which retained mode control ID is being referenced by the immediate mode function.  If you skip calling a "Button" function in one case your entire GUI stops working.

Particularly egregious examples of immediate mode GUI are Unity's OnGUI mehod, GUI and GUILayout classes.  Unity basically calls your OnGUI method once per "event" (layout, paint, input handling, that kind of thing).  Since much of the code in your OnGUI method may only be relevant to one or two of the event types, if you do anything other than GUI.* calls you're wasting time calculating things that will be discarded. Trying to do anything complicated with them can very quickly wreck performance.  The hoops you can optionally jump through to increase performance (by avoiding irrelevant calculations in specific 'event' phases) are like writing a retained-mode interface wrapper on top of that.  Unnecessary additional layers of abstraction when ideally you could just control the retained mode GUI under the hood.

I haven't personally used any of the web-specific UI frameworks since I avoid web development like the plague, but my understanding is:  The HTML elements are a 'retained mode' equivalent.  The browser handles their layout and rendering.  Why anyone would want to build immediate mode on top of that is beyond me.

I guess the answer to "when" is somewhere around customizable blog platforms becoming widespread along with portfolio sites for every creative profession. Though I don't know the method of making an immediate  mode GUI on top of HTML/Javascript, it''s seems conflicting with the working of HTML/Javascript as Nypyren pointed out. I guess  the reason is that many feel these frameworks are still easier to use than HTML/Javascript.

On 12/17/2017 at 4:35 AM, alnite said:

Lol.

Web development is the new entry-level programming framework that people are learning nowadays. Coding bootcamps are churning new web developers every month. In the past few years, how many times have they switched frameworks? From Angular 1.3 to 2.x. Now, there are Polymer, React, Vue, among jazillions of many other Javascript/CoffeeScript/TypeScript/CSS/Less frameworks out there, each claiming better and simpler than ever before?

Many times I have felt blessed that it was games that introduced me to programming.

I second that. Web programming scares me. It's not something simple anymore!

web development is such a mess. Why must something as simple as rendering text / images and controls be so fricking complex. 

Im really praying webassembly gets some traction, if they can give us an api to render basic ui elements without manipulating the DOM the sky is the limit. Build custom render engine that downloads on the fly (cached long term). A simple version check for any site that uses that engine. Commercial tooling can then compete and drive some progress. The same paradigm as video game dev. 

I think we would see some very interesting user experiences. Immersive content rather than add laden click bait.

1 hour ago, RivieraKid said:

rather than add laden click bait.

But how would that change how they make money (or are unable to make money, in many cases)?

My 2018 prediction is that plain old news sites will begin adding cryptominers to their own pages to increase revenue.

14 hours ago, Nypyren said:

But how would that change how they make money (or are unable to make money, in many cases)?

My 2018 prediction is that plain old news sites will begin adding cryptominers to their own pages to increase revenue.

fewer higher quality websites can find other revenue sources, the 1 you mentioned is a possibility. Subscriptions, donations, patreon as well. These are quite popular with video because its a well understood format with a massive industry of tools & techniques. 

A quick idea of the top of my head - a video game review in video format and 1/2 way through the review the host says "why don't you have a go?", through the power of streaming content we are able to briefly take over the gameplay for 10-20 seconds. The technology just simply isn't there to do this. Sure there are other barriers such as download rate and existing of a gpu but we can't even get to that point to test the waters, not without some heavy plugins/custom tools (mostly rejected by web gurus)

Remember when you first saw a HD video on a tv within a video game? We are constantly amazed by the new techniques that video games throw at us but unfortunately this level of innovation is not present in websites. Imo there should be seamless integration between desktop/web/gaming, the user experience should not be vastly different as you transition between mediums. I ask for a lot, maybe I am naive, but we should shoot high. Maybe VR can bridge the gap.