"The core idea with react, and this is the only thing that matters, so don't view components as a react innovation. Components have been around forever. You build any sort of native application on Windows or macOS or iOS and there's a notion of component, some call it a view or whatever, but the idea of composing components out of other components has been around since the dawn of time.
I don't know why we weren't doing it on the web. I think we were just, I don't know, being stubborn or something. But that's not a new innovation."
Hmm...sounds just a bit like what they were trying to achieve was something along the lines of "Cocoa for the Web".
But what does he know?
¯\_(ツ)_/¯
Anyway, he does go on to say that the core innovation is having the UI be a pure function of some state. But that's the part that isn't actually true. It ain't a pure function. See Dan Abramov's comment:
Support for local state and side effects is absolutely a core feature of React components and not something we avoid for “purity”.
So if it's not a "pure function" of the state, then it's some mapping of the state. All UI is some sort of mapping of the state, otherwise it's not really a UI.
Hmm...
So being a "pure function" of the state is not the innovation, because it isn't true, and being some mapping of the state is also not the innovation, because all UI is a mapping of the state.
Hmm...
So what is the actual innovation? It is more or less directly and visibly expressing the UI in code. And since all our languages are essentially procedural (functional, OO) that means expressing the UI as a procedure (function/method).
And so the "pure function of the state" turns out not to be a feature of this model, but a (squishy) requirement. Because in order to make the UI definition a procedure, you have to re-run that procedure at arbitrary times (and ideally also run it partially). And so the requirement is "sufficiently pure that we can re-run it".
And that is an innovation, and it's kinda cool. But it does break down rather quickly, which is why all these frameworks keep iterating, and iterating, and iterating.
The best definition i can think of for declarative UI frameworks is probably something closer to 'frameworks that optimize for your ability to make a pure function representing state'.
(After all `[[UIViewController alloc] init]` does indeed purely say 'you have view controller' — that's just not super granular!)
In this light, isn't SwiftUI just a setup more optimized in this direction
That isn’t innovation either, it’s just game developers who are too busy to tell us immediate mode gui stories all day. The only innovation it has is solving the problem natural to the web only – dom changes suck, amplified by a historical lack of a cell concept (which is a core disaster). They partially “fixed” that by diffing vdoms. Everything else is just opinionated bargain on top of that.
Basically an element without its own geometry that renders in multiple locations on the screen. E.g. if a dom table (or a grid) has 10 columns x 1000 rows, it must have 10k real td (div) elements. A table in most desktop frameworks will only have 10 cells which will be rendered at multiple (visible only) y-positions. When you scroll, they render a few in advance on a scroll-cache surface. This saves memory and reduces reflow pressure because a framework knows the geometry of a cell.
Of course if a table (any collection really) contains differently looking items, it may have more than 10 cells, and rendering controller may choose between them based on which row/column is rendered.
React mentions in their docs a plugin which simulates exactly that (forgot the name, something like react-dynamic-scroll).
Also, some frameworks use cells to render active elements basics, e.g. an input without a frame, or a check mark cell without a background. This helps to make controls editable without instatiating a real input/check/button element at the coordinates of a cell. This makes every button in a container a single button which signals clicks to its container, which based on x,y knows which item that is and signals rendering controller that item X was “clicked on the button B”.
Wow, I've been trying to come up with a way to do this on the web for a while now, but haven't cracked it yet. Had no idea it was a common thing in other UI technologies.
https://futureofcoding.org/episodes/011
17:30
"The core idea with react, and this is the only thing that matters, so don't view components as a react innovation. Components have been around forever. You build any sort of native application on Windows or macOS or iOS and there's a notion of component, some call it a view or whatever, but the idea of composing components out of other components has been around since the dawn of time.
I don't know why we weren't doing it on the web. I think we were just, I don't know, being stubborn or something. But that's not a new innovation."
Hmm...sounds just a bit like what they were trying to achieve was something along the lines of "Cocoa for the Web".
But what does he know?
¯\_(ツ)_/¯
Anyway, he does go on to say that the core innovation is having the UI be a pure function of some state. But that's the part that isn't actually true. It ain't a pure function. See Dan Abramov's comment:
Support for local state and side effects is absolutely a core feature of React components and not something we avoid for “purity”.
So if it's not a "pure function" of the state, then it's some mapping of the state. All UI is some sort of mapping of the state, otherwise it's not really a UI.
Hmm...
So being a "pure function" of the state is not the innovation, because it isn't true, and being some mapping of the state is also not the innovation, because all UI is a mapping of the state.
Hmm...
So what is the actual innovation? It is more or less directly and visibly expressing the UI in code. And since all our languages are essentially procedural (functional, OO) that means expressing the UI as a procedure (function/method).
And so the "pure function of the state" turns out not to be a feature of this model, but a (squishy) requirement. Because in order to make the UI definition a procedure, you have to re-run that procedure at arbitrary times (and ideally also run it partially). And so the requirement is "sufficiently pure that we can re-run it".
And that is an innovation, and it's kinda cool. But it does break down rather quickly, which is why all these frameworks keep iterating, and iterating, and iterating.