React's model is very similar to how 3D applications work at a high-level. There is a render loop that is either on-demand or continuous, the latter is more common in 3D. During each iteration, input is collected, background processes are run like AI, etc. and they all change the state of the application's data. The new state is given to the rendering engine, and the rendering engine re-renders the entire scene as efficiently as possible.
It turns out it is a lot easier to program dynamic 3D scenes using this method, rather than trying to do two-way binding like Angular, JQuery, etc do. And the performance is typically better too. Imagine trying to do two-way binding in a AAA game with 1,000s or even 100,000s of individual objects in a scene. It would be a programming nightmare! Instead much of the effort is spent trying to reduce the amount work the GPU has to do when rendering the entire scene such as occlusion culling, distance-based level of detail, etc. React's virtual DOM renderer is also trying to render the scene (DOM) as efficiently as possible. But admittedly it is much simpler than Unreal Engine's renderer, but the high-level concept is similar.
I think this is why React feels so natural to so many people when building dynamic web UIs compared to JQuery, Angular, and even Vue.
Just to correct this a bit, while this is certainly true of AngularJS, this is certainly not true of Angular. Angular since v2 has taken a reactive approach throughout, and even the two-way data bing is just syntactic sugar for an evented pattern powered by rxjs. Perf-wise, other than initial load, Angular is actually a little better from my understanding & based on numbers I’ve seen.
React has certain weaknesses that aren’t seen in other UI libraries/frameworks as well - forms are a complete mess to work with, even with formik, and animations are pretty problematic.
As with anything, there are tradeoffs to approaches. FB isn’t as form heavy in general, so optimizing how it works for the rendering inputs from external sources & dev usability makes sense for their use cases. It’s important not to conflate this by overpraising.
Could you elaborate on this? I've been creating form heavy react apps for a couple of years now and haven't really come across anything that would make it 'a mess'.
I find that the biggest issue with forms and react is attempting to use lifecycle methods and local state to manage the behavior of the controls: at work, I’ve done a bunch of refactorings to replace local state and lifecycle methods with redux and logic in the render method of the parent components, and this has always led to simpler components and has fixed a lot of bugs caused by inconsistencies between props and state.
I think this is because you are using both state and props to manage the values of fields. I generally tend to use only props, with an onChange handler passed in from the parent component. This way, I can always have an up to date mapping of field names to values in the parent component, while simplifying state management in the child.
You made not need redux! Found lot's of projects where they plug redux an turns the project a completly mess. (connected components everywhere), actions to manage local component ui state..
You're right Dan, this is a great framework, but the code complexity behind it is insane. Of course a lot of that complexity is due to HTML/browser, we cannot ignore that.
However, part of that complexity is the fault of React. The choice of HOC vs. Component... two ways to do the same thing. There is also FastForm vs. Form. As we move on over time, now we have hooks being added as well. The mental complexity just to put a simple input on a page is overwhelming.
I think what I'm looking for is React to take some ownership and provide guidance out of the box for these core browser features under the React umbrella.
> I think what I'm looking for is React to take some ownership and provide guidance out of the box for these core browser features under the React umbrella.
So we need React on Rails? An opinionated collection of libraries that work on top on the React Runtime. I personally find this idea compelling.
There are a few of these sorts of things already. I'm not really talking about opinionated frameworks (or collections of various github projects stuff into a big meta project). https://reactjs.org/community/starter-kits.html
What I'm talking about is something more akin to this statement:
https://angular.io/guide/forms-overview "Handling user input with forms is the cornerstone of many common applications"
But isn't that something React wants to avoid? I remember reading somewhere that React does not want to recommend any approach to forms, routing, etc., but leave it to the user.
I mean, I don’t think it’s designed to “put an input on the page”. Tracking things like hover, dirty and pristine states, sync and async validation, etc, is an inherently complex problem.
If you just want to put an input on the page, that’s just three lines with React. (Especially with Hooks.)
I think redux is the only thing that can prevent a react project from becoming a mess: I’ve noticed that the major bug points in the app are where people try to use something else to manage state
I was with you until the past sentence, which seems unsubstantiated. VueJS, at least, uses a similar virtual dom rendering concept. I find Vue's API much more natural than React's, but that's unrelated to their internal implementations. Can you provide further detail?
Yes, I am aware Vue is more similar to React than the others. I probably shouldn't have said anything about Vue. Since I did, here we go.
There is another component to React which I didn't mention that gets inspiration from the 3D world: the API. When I first saw React's API, the first thing I thought was "that looks kinda like OpenSceneGraph, cool!" Now this is the very subjective part, having spent 8-9 years doing 3D graphics React felt natural to me. Given its popularity, I must not be the only one either. I am glad you like the Vue API but it doesn't feel like a 3D engine. For whatever reason, many people seem to prefer the 3D engine feel. On purely technical merits, I think React and Vue are basically the same. But I think there is some intangible difference in how the tools feel. Some people like React and some like Vue and both are right. However more people seem to like React.
> Now this is the very subjective part, having spent 8-9 years doing 3D graphics React felt natural to me. Given its popularity, I must not be the only one either. I am glad you like the Vue API but it doesn't feel like a 3D engine.
I would postulate that the subset of people who are both web developers and have also worked on 3D graphics is a relatively small slice, so I wouldn't be convinced that a 3D engine-like API is the reason for its popularity.
Correct, not directly. My point is that the 3D engine feel seems to have some sort of wider appeal even if you haven't done 3D engine development. It was direct for me because I am in that small slice. Like I said, this part is very subjective.
Under the hood, Vue uses a similar virtual dom model as react, and at its core is based on one-way data binding. Vue's `v-model` is not a two-way binding a la angular, but syntactic sugar for the common (non-flux) react idiom of updating a parent's state based on an event emmitted by the child (which is handled by a vanilla react-style prop function)
I'm not sure I agree at all, 3d engines render loop foregoes any attempt to skip unnecessary rendering to focus on fast, continuous rendering.
React on the other hand tries as hard as possible to avoid rendering, in fact it's whole design of immutability isn't because functional style is better, it's just convenient for it's requirements to avoid rendering.
For me react is more of an antichrist of UI tech, as much as I use it and rely on it, the day I can just mutate some state and that renders (i.e. .. just straight up dom), the better.. if I want to then layer on some immutability patterns then that's entirely in my apps domain.
> 3d engines render loop foregoes any attempt to skip unnecessary rendering to focus on fast, continuous rendering.
3d engines often go to great lengths to avoid sending unnessesary data to the GPU. Frustum culling or more sophisticated occlusion culling are standard practices.
Have you looked at Mithril? Looks a lot like React, but there is no need for immutability, because it redraws after events or xhr calls. You can just mutate a model/store object in event handlers and the UI reflects the changes. Imho, this is a much simpler model and it's what you need 99% of the time.
3D engines have the part where they try to reduce rendering in the engine part, so you don’t deal with it when writing your application, but it’s definitely there.
When I say minimize rendering, I don't mean skipping frames although it could mean that. During a single frame, 3d engines try to minimize the number of triangles, textures, etc that need to be rendered in that frame. Also some non-realtime 3d applications, like CAD, will skip frames. If React has to do animation, then it can't skip frames either.
High performance 3D applications (like games) typically recreate the entire rendering command list from scratch each frame instead of manipulating an existing "scene graph".
React feels more like "retained mode rendering engines" which were popular in the 90's and early 2000's.
React provides an immediate mode API (virtual DOM, which is recreated from scratch on every render) implemented on top of a retained mode API (the actual DOM which is stateful).
Diffing and piecemeal updates are an implementation detail/optimization.
It turns out it is a lot easier to program dynamic 3D scenes using this method, rather than trying to do two-way binding like Angular, JQuery, etc do. And the performance is typically better too. Imagine trying to do two-way binding in a AAA game with 1,000s or even 100,000s of individual objects in a scene. It would be a programming nightmare! Instead much of the effort is spent trying to reduce the amount work the GPU has to do when rendering the entire scene such as occlusion culling, distance-based level of detail, etc. React's virtual DOM renderer is also trying to render the scene (DOM) as efficiently as possible. But admittedly it is much simpler than Unreal Engine's renderer, but the high-level concept is similar.
I think this is why React feels so natural to so many people when building dynamic web UIs compared to JQuery, Angular, and even Vue.