Simple is subjective. I find the React way of making web UIs, where you just write a `render` function, way simpler than manually mutating existing UI widgets to match the data every time it changes. Or some weird manual data binding via model wrappers.
Maybe it's a tiny bit more code in the very beginning, but it becomes worth it very soon (as soon as you get past hello world pretty much).
That being said, we could always have better tooling, even for this paradigm.
Maybe there's a similarity in how it worked under the hood, but the users of those APIs most definitely could not write UIs in that style.
In Win32 code, you still have persistent windows with child "windows" (UI controls/widgets) on them, that have UI-specific internal state (such as text, position, links to their own child windows, etc.) that is different and separate from your application's state (variables, data structures).
Then you have to manually mutate (SetWindowText, ListView_InsertItem, CreateWindowEx, DestroyWindow etc.) the UI when something in your application's data changes.
Unless you don't use any native UI controls and just draw everything manually I guess, but people generally didn't do that.
> In Win32 code, you still have persistent windows with child "windows" (UI controls/widgets) on them, that have UI-specific internal state (such as text, position, links to their own child windows, etc.) that is different and separate from your application's state (variables, data structures).
I don't get it. This is a property of every UI toolkit. In other words, this goes for the web as well. In the underlying structures, all data exists independently of your application.
If you mean that there's libraries for the web (angular 1) that make it easy to pretend this isn't true, that the contents of your variables are really on screen, similar libraries exist for windows apps as well. Hell, all of those database things like Access, in a way, have just this concept (the language/tooling pretends that the form field for field X IS field X, through bidirectional synchronization).
Also, except for windows 3.0 apps, nobody ever called things like SetWindowText themselves.
Persistence, and the lack of options to turn it off is one the of major pain points with the web as a platform. Even canvas is persistent, which makes no sense at all to me.
And for me at least, there's two huge differences. On windows, very big apps could work together and be open a dozen at a time. A dozen of single-page-app tabs will, on the other hand, slow my Xeon-backed chrome to a crawl. Secondly, I have never seen any webapps that approach the complexity of normal windows apps. The most complex web apps currently are things like Google Docs, and the average is something like a webform. How many years of the web platform do we need to conclude that it has found some way to prevent feature-full applications from being written ?
I've developed plenty of applications for both windows desktop and for the web, and it's pretty clear to me: the web enforces extremely complex methods of doing things. Markup, javascript, RPC (can be HTTP), other language, another data language is the default layer. Adding a single field to a single record type requires knowing HTML, JavaScript, HTTP (how to use HTTP and encode stuff in it), and then backend language (let's say Java), then SQL. ALL of them need to be modified to just modify a record type.
The web is extremely lacking in performance, and is far, far more complex than it needs to be.
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.
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.
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.
Maybe it's a tiny bit more code in the very beginning, but it becomes worth it very soon (as soon as you get past hello world pretty much).
That being said, we could always have better tooling, even for this paradigm.