Previously we had been doing retained-mode rendering. We would modify & shuffle around the pieces of the page.
React's components were there to let you re-render the app quickly. When state changed, a new render happened, with new elements emitted. You didn't think of what elements used to be there.
React was about the virtual dom. It was about creating an abstraction to let us not have to regard what was on the page, when we were deciding what is on the page. Incidentally, imo, that involved components, but components, while comprising numerous html elements, serve a very similar function to html elements (especially to web components), and were not, imo, a particularly novel part of React. Yes, there was a lot to their creation & implementation, there was a lot of tech work that went into making Components a thing. But components, to me, are far outshadowed by the vdom, by the performance & speed of a data-system designed to go diff & en-act desired state into the live DOM tree.
In kubernetes world, we'd call the vdom a controller. It reads the canonical state, the component tree, and insures the target DOM machinery is kept up to date & reflects this desired state.
The vdom is interesting, but the right history isn't starting there. The premise was the ability to build bigger, better, more reliable, easier to understand/maintain/refactor apps. Components with declarative render + top down data flow enable that, vdom is just the only way to make it work without being too slow.
Everything interesting & notable about components relates to the fact that they are immediate-mode things. Nothing else is particularly notable or interesting or important about them, has parity with what HTML Elements did/do.
Regardless of intent or deliberation, this, to me, is the clear & obvious technical difference that underpins whatever goals the team thought they were shooting for. It's the major characterization of how React was different from other webdev we'd tried. Everything else is downstream of that specific choice, for how to "draw" HTML: immediate-mode.
Immediate mode has a specific meaning that isn't really what React is doing. There's no concept of avoiding double buffering, immediate mode re-renders everything every frame while vdom avoids as much work as possible and updates are only triggered by actions.
But there's more interesting to them than just being declarative. A pure render function, a standardized prop boundary, top down data flow, and lifecycles (further improved by hooks, which are basically algebraic effects, which make real hot reloading work), are just as important, and all of those fall under "components".
Enyo, the WebOS framework, actually had a great declarative component model without vdom many years before React.
> Immediate mode has a specific meaning that isn't really what React is doing. There's no concept of avoiding double buffering, immediate mode re-renders everything every frame while vdom avoids as much work as possible and updates are only triggered by actions.
I've shown above others with similar framing to my own. I think you are over-focusing & refusing to see a similarity that is quite present. From a programmer perspective, react is about calling React.render(myJsx, domElement), again and again and again. How much more immediate mode does it get? "Redraw the world" is the premise.
As for double buffering, that's pretty much what the vdom is doing! There's the current buffer, there's the new world, and the vdom machinery is pushing the new buffer onto the old buffer once the render completes.
> But there's more interesting to them than just being declarative. A pure render function, a standardized prop boundary, top down data flow, and lifecycles (further improved by hooks, which are basically algebraic effects, which make real hot reloading work), are just as important, and all of those fall under "components".
These are all good characteristics of React, and part of it's total package that defines it. Interesting, yes! I think I am under-attributing the different feel of components versus where the web was before. A lof of this, feels, to me, like an incident discovery to a bigger phase change, from retained to immediate. I see a lot of those finger prints in other immediate mode rendering places. But it's very new to the web, best I can tell. I need to go back & re-review Enyo. Been a while. Ahh the heady days of two way data-binding!!
To hash up some specific points? Declarative is only part of it. The DOM is declarative. But the DOM is not immediate mode rendering, it's a retained system. The declarativeness feels normal?
Pure render functions are neat to see on the web, yeah. A lot of other immediate mode systems have this, geometry shaders being a large class of systems that often are pure functions.
The prop boundary seems like something the DOM already has & used a lot, if not quite so heavily bounded. This is just properties on elements, only expressed in a slightly different way: that distinction doesn't draw any major note for me, is an interesting twist, but just a re-embodiment of what was. That it's a harder boundary now doesn't do a ton for me- elements have been powered by their properties since DOM1 & it's very normal on Custom Elements.
Top down data-flow again feels like something relatively naturally emergent most scene-graph rendering systems, not unique to React. The web itself is a big top down renderer, always has been. It's weird because I both see tons of parallels between templates (which often nest or accept children or slots) and React components, but also I see that the feel is quite different, that components somehow are different, although I struggle to characterize how they really are and how this has changed webdev.
Not sure how I feel about lifecycle either. Willing to give this one to componenents. Definitely not a very immediate-mode idea, more like something we'd see in a scene-graph though.
Web components are primarily about trying to add new virtual HTML tags to "extend the platform".
React and other frameworks are about trying to build interactive applications that require larger-scale UI management, efficiently, on top of the DOM, by defining pieces of that UI as a tree of reusable components (and using techniques that web components don't have available to them).
If I want to add a color picker to an otherwise static HTML page, I might use a color picker web component.
If I want to build a meaningful-sized app, I'd reach for React.
React is awesome because it allows feature-aligned separation of concerns (each component has a single job - render everything about a specific element - which is usually a well defined part of a specific use case).
Jsx is the best UI system ever in terms of productivity - speaking from experience: I’ve implemented production apps using dozens of UI frameworks/platforms - Html, WYSIWYG, Flash, WindowsForms, WebForms, Ajax, Asp.Net Mvc, Razor, WPF, Xaml, Silverlight, Knockout, Handlebars, PhoneGap, Ionic, Bootstrap, MaterialUI, Angular2, React w/ Class Components, React w/ Mobx, React w/ Hooks
I can tell you pros/cons of each of those. But at the end of the day I can develop an entire app in days in React+Hooks which would take me weeks in most any other.