Indeed, I genuinely do not. Rather than passive-aggressively insulting my intelligence, why not explain it for me? As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI, so it seems like web developers do in fact want to build immediate-mode UIs, and in fact are constantly complaining about the nightmarish complexity of the status quo.
[1] I loathe this term, by the way. It's one of those terms that, I think, belong to a discipline of developers who love to obfuscate everything, even simple concepts, with unnecessarily opaque terminology until nobody can understand what the hell anyone is talking about anymore.
>As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI
the problem is that the typical modern web page is considered as a combination of immediate-mode and retained-mode.
therefore, as it is wasteful to update all the page when only a few components on the page change, people want to only update parts of the page immediately when changes happen.
furthermore the typical modern web page only makes sense in the context of the modern web site, so some pages are almost everything on the page needs to update all the time, some pages are nothing here needs to update until the user does anything, some pages are nothing here needs to update at all, and other pages are just a couple components need to update all the time based on various things.
This context of what a web site is like is very much determined by the type of the site, where many e-commerce sites are affected by all sorts of data that occur outside of whatever page the user is on and need to update all sorts of different components on a page, many governmental sites are almost just static, with all sorts of variations in between.
I was just responding to the usage that the parent commenter had which was
>As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI
which I interpreted as the only possible meaning, in relation to React, being UI components that must rerender as close to immediately as possible vs. UI components that do not need immediate rerendering when the underlying data has changed.
I realize that is not a particularly correct use of the phrases, but then that is what happens when you use a concept from one type of development metaphorically in another type of development, memetic slippage as it were.
> In immediate mode, the scene (complete object model of the rendering primitives) is retained in the memory space of the client, instead of the graphics library. This implies that in an immediate mode application, the lists of graphical objects to be rendered are kept by the client and are not saved by the graphics library API. The application must re-issue all drawing commands required to describe the entire scene each time a new frame is required, regardless of actual changes.
React is simulating immediate mode by having the developer describe the full rendered result from the current data state. The developer / app code doesn't need to keep track of what changes need to be done to get the browser from its current state to the desired state, React does that for you.
Retained mode is where the developer / app does have to concern itself with the current browser state and issue the desired updates themselves, like how everything was done in the jquery era and earlier.
I am no web developer but whenever I built the UIs, re-rendering a page by doing some big DOM change through JS as always led to stutter. So maybe its just inefficient and can't be optimised.
No horse in this race, but your phrasing seems a bit weird, honestly... If reduced, your comments read as:
"You don't know about X? Well, at least I know about X and Y..." Doesn't seemed like a good faith comment to me either?
And then you say "You misunderstood my intentions so I'm going to disengage". For what it's worth, I didn't interpret your argument as insulting someone, but also it wasn't a useful or productive comment either.
What did you hope to achieve with your comments? Was it simply to state how you know something the other person doesn't? What purpose do you think that serves here?
I guess I misinterpreted your comment? I do apologise if that's the case. I certainly didn't intend to "jump down your throat", I was asking you to explain your comment further because I don't understand what you're getting at.
To be perfectly fair, you accused me of insulting you and said you "loathe" a word which I thought was a fairly inert term of art. Would you believe I didn't actually notice that you wanted me to say more? :) More than happy to give the benefit of the doubt though, the shoe's been on the other foot for me more than once.
For my part, I also loathe the insensate writhing mass of frameworks, patterns and dependencies that is "modern" frontend development. Where you and I differ is I recognize a handful of extremely good ideas hidden in the morass. But I am perfectly happy dismissing the majority of it; if nothing else, you shouldn't come away thinking of me as a React fanboy.
Writing is a lossy medium for thought, and programming is no exception. I'd say at a minimum that you and I are on the side of programmers whose code is a medium for their own thought.
All of these choices really just comes down to cognitive bandwidth, context, domain, taste, any number of things, really. Which is what was behind my first (admittedly terse, slightly salty) comment.
What I condemn is someone who opts out of making choices for themselves in their software. Web dev just happens to have an unfortunately high concentration of this sort of thoughtlessness.
