I understand 'functional' to be used as the direct contrast to 'procedural'! Is that not your understanding?
> So what is the actual innovation? It is more or less directly and visibly expressing the UI in code.
The 'visibly' part here doesn't really actually hold true, does it? Once you've componentized your <swiftui/react/html/[VFL](https://developer.apple.com/library/archive/documentation/Us...>, it's probably not super visibly understandable.
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
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”.
Click on the links, there are live examples.
> Hmm...sounds just a bit like what they were trying to achieve was something along the lines of "Cocoa for the Web".
More like native UI for the web? I'd take your point if he only mentioned macOS or iOS. Check your bias!
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.