4 ms·

Your talking about the difference between immediate mode vs retained mode, immediate mode being the "self contained render" method. This is nice and clean up to

by laythea 10y ago

Your talking about the difference between immediate mode vs retained mode, immediate mode being the "self contained render" method. This is nice and clean up to a point in complexity, and then the advantages of retained mode (or "manually mutating existing UI widgets to match the data every time it changes") outweigh the disadvantages, namely the management of the UI/data interface.

realharo 10y ago
What are the advantages of retained mode UI (genuinely curious)? Assuming you have good enough primitives to work with (i.e. you write your render function in terms of HTML elements and other React components - or something similar, not raw lines and rectangles), then I just don't see any.
- laythea 10y ago
  Rather than repeat, I will just link you to: http://gamedev.stackexchange.com/questions/24103/immediate-gui-yae-or-nay http://gamedev.stackexchange.com/questions/24103/immediate-g...
  - realharo 10y ago
    That talks about game UIs, which are indeed much more difficult to work with, e.g. >The GUI library consists of one-shot "RenderButton", "RenderLabel", "RenderTextBox"... functions >all RenderXXX functions that have user interaction like a buttons or checkbox have return values that indicate whether e.g. the user clicked into the button. But React is nothing like that. Writing JSX very much resembles writing HTML, which makes the tree structure easy to read/write, you bind event handlers to elements (`onClick={this.helloClicked}`) just like you could with HTML, passing data (props) to child components is trivially simple etc. That's why I wrote "assuming you have good enough primitives to work with" in my previous comment. With game UI libraries, you often don't, and often there are limitations in the language itself that prevent the libraries from being good enough. When you have a nice environment to work with, all that retained mode does is duplicate the state - so you have your application data, plus the internal state of the UI component, or even the larger structure of the components - and it places the additional burden of keeping them in sync on your shoulders.

by laythea 10y ago

realharo 10y ago

What are the advantages of retained mode UI (genuinely curious)? Assuming you have good enough primitives to work with (i.e. you write your render function in terms of HTML elements and other React components - or something similar, not raw lines and rectangles), then I just don't see any.

laythea 10y ago
Rather than repeat, I will just link you to: http://gamedev.stackexchange.com/questions/24103/immediate-gui-yae-or-nay http://gamedev.stackexchange.com/questions/24103/immediate-g...
- realharo 10y ago
  That talks about game UIs, which are indeed much more difficult to work with, e.g. >The GUI library consists of one-shot "RenderButton", "RenderLabel", "RenderTextBox"... functions >all RenderXXX functions that have user interaction like a buttons or checkbox have return values that indicate whether e.g. the user clicked into the button. But React is nothing like that. Writing JSX very much resembles writing HTML, which makes the tree structure easy to read/write, you bind event handlers to elements (`onClick={this.helloClicked}`) just like you could with HTML, passing data (props) to child components is trivially simple etc. That's why I wrote "assuming you have good enough primitives to work with" in my previous comment. With game UI libraries, you often don't, and often there are limitations in the language itself that prevent the libraries from being good enough. When you have a nice environment to work with, all that retained mode does is duplicate the state - so you have your application data, plus the internal state of the UI component, or even the larger structure of the components - and it places the additional burden of keeping them in sync on your shoulders.