I wonder how well the event binding works. For me this is the main reason to use React because it avoids all the mess that can come from that. Apart from that, React performance is much better than any naive re-rendering solution, on the other hand it's worse than programmatic diffing with native APIs or jQuery...
I've done that recently, and I had many performance issues. I have a long-ish list of very simple components that are in a sorted order. So when I change the value of one, I re-sort the list. I was hoping React would only rerender the changed items (remove old, insert new). But no, it rerenders the whole list, which takes 500ms. I made sure object references in the list stay the same, that didn't help.
I can implement this thing in vanilla JS, and it would not take more than a few milliseconds. React is cool, but so damn hard to optimize.
The PureRender and componentShouldUpdate methods are "escapes" from the React philosophy, so I don't count them as being "React". They make the code more complicated because, with them, inconsistencies can easily arise.
Making a simple local change to a list of N items, which would normally take O(1) energy, suddenly takes O(N) energy. Even with the PureRender and componentShouldUpdate methods, because React will traverse the complete list to determine which items should be changed (calling componentShouldUpdate for every item).
I agree with you on the DOM. Its speed needs to improve. React offers a nice abstraction which may keep the code simple, but, as explained here, has problems of its own.
I meant for this to be included in the scope of my comment but I was short on time. You stated it better, and you’re completely right. The problem I was alluding to was related to a hook deciding when to rerender based on dependency lists. It was setup such that some people may expect it to rerender in a certain case and others may not, and it wasn’t an uncommon or excessively complicated use-case.
React can’t win here because they have a hard stance on when to value performance (avoiding re-renders) vs. convenience (ease of abstraction usage).
Given that all of the code uses React.FC instead of React.PureComponent or regular React.Component the efficiency obviously lacks, there's no props diffing and everything will be rerendered.
React reduces manual interaction with DOM (which is slow) by calculating the diff between your new render call and the previous one. Imagine building a webapp where each time you need to update the view, you just lazily refresh the whole UI. The library knows to only update the necessary parts.
In fact, the whole api is so simple that I could probably summarize the core for you:
- a `render` method that defines what the view looks like, using variables and such.
- a `setState({variableName, newValue})` call, upon which the render method is called again, but only making DOM modifications where your variable influenced them.
Disadvantage is that creating a new function on every render ruins performance optimizations like `React.PureComponent`. Although that's a pretty minor detail, (you shouldn't prematurely optimize, and sometimes PureComponent is actually more expensive than rerendering since computing whether props have changed can be more expensive than just rerendering.)
I don't think that many junior/early mid React developers know that the whole tree gets re-rendered.
Those that do, I don't think they fully understand when and where to `useMemo` and `useCallback` to optimize. It tends to get overused or used in a way that doesn't actually memoize the parts of the component that doesn't change.
Then adding in state management only makes it more complicated in some cases depending on the state paradigm.
It's a mystery that React is as prevalent as it is given how hard it is to actually do well. I think Solid.js and Vue have a much cleaner paradigm as far as re-renders goes (with React being explicit opt-out and Solid and Vue being opt-in).
To me it was not only that as I didn't do games or highly interactive UI's where DOM updates would really matter but it freed me from the burden of ad-hoc updating with jquery as everybody was used to. Unless you had some framework or had invented ways to centrally store state chances are your code was all over the place.
I tried 2-way binding in ExtJS and it seemed to work well at first then I started adding more and more binds to the component and at certain point performance just tanked.
And it was after I started with React already so I just didn't bother to investigate, issue actually was some kind of loop being formed and things aborting due to hitting limits. Which I guess means I used it somewhat incorrectly but I never had that issue with react.
The author does not state that React components are literally redrawn like Windows views. He simply recognizes a pattern and makes a pretty apt comparison.
> React by itself doesn’t actually solve how to propagate changes
In my experience, it really doesn't solve the problem all that well for a sufficiently complex app. I'm willing to give the author the benefit of the doubt on that point.
Isn't this supposed to be a non issue because react can intelligently compare the higher level components of your application and decide whether they need to be re-rendered?
Well- the React example doesn’t really restart rendering from scratch (as you yourself mentioned). And in larger applications you’d still prefer to not ‘redraw from scratch’ in React either and build on top of a previous setup.
Really what you’re doing is preferring more declarative programming practices over procedural. And as a consequence, more declarative APIs like React.
Like others have said - I think the documentation glosses over how the "rerender" function totally and drastically changes this from a "React alternative" to "backbone with JSX".
The point of React is not the JSX, but rather the unidirectional data flow and automatic re-renders due to prop changes -- essentially modelling your application as a "state machine" and eschewing the need for a "view model" or manual synchronization of DOM state to application state.
With the "rerender" function I fear any nontrivial application will devolve back into the tangled web of event listeners we left behind when moving to React.
Personally - I think a library like this is only useful for a very narrow audience: people with an affinity for JSX that are only building webpages (not web "apps") with some basic progressive enhancement features that can be kept track of pretty easily.
I don't mean to be overly negative here - I just suggest that you alter the documentation to be more clear about the differences/limitations when compared to react. The existing docs/example is almost (unintentionally, I'm sure) misleading in my opinion.
This is not my experience at all. I write some visualization. I want to add a UI to tweak the numbers. I add React. React requires me to re-write all of my state for its `setState` stuff.
Having implemented a code editor, I can assure you that not re-rendering lines and blocks of code is also a worthy effort. It probably just doesn't fit into react's incremental computation model yet?
What you should be doing is just changing the parts that you know have changed. Letting react do the hard work will always lead to worse performance
reply