5 ms·
It's solving performance issues that React and other virtual DOM libraries currently suffer. This is massively important for low power mobile devices. It's not
by trueadm 10y ago
It's solving performance issues that React and other virtual DOM libraries currently suffer. This is massively important for low power mobile devices. It's not an ego driven project, all research is going back into the open-source community to make better libraries and implementations inclusion React.
- spriggan3 10y ago> It's solving performance issues that React and other virtual DOM libraries currently suffer. But isn't "performances" the point of React? As I understand things, people were moving from AngularJS to React because the virtual DOM was supposed to be the most performant technique to handle UI mutation and rendering. So what is the reality behind the supposed speed of React ?
- Keats 10y agoReact can be fast but is the slowest amongst pretty much every virtualdom libraries
- dangoor 10y agoPerformance is not the point of React. Predictability is. Bunches of bugs are eliminated and others are easier to find.
- deckard1 10y ago> Bunches of bugs are eliminated and others are easier to find. Got a link to the research for that? My pet peeve is unsubstantiated bullshit claims. We let sooooo much nonsense fly, especially in JS land.
- marshalltony 10y agoI will go write a blog post on medium claiming some research I did and link to it. The stuff I read on here makes me never want to come back to this website again.
- dangoor 10y agoI don't know if Facebook has done any formal studies. Here's one way to think about it: if you have a webapp and have state in JS objects that you have to synchronize with the DOM, that generally takes a fair bit of code. React provided an approach for eliminating synchronization code entirely. My own experience and that of the many others that created webapps pre-React and then adopted it is that its model simplifies our work and removes bugs. That's why we use it. It's also why there are a bunch of other vdom libraries and Ember and Angular have both moved toward similar one-way data flow models. There's a lot that we do day-to-day that doesn't have research to back it up. At some point, we have to try things out for ourselves to see how they work for us.
- cageface 10y agoAnecdotally I can certainly back this up from my own experience. My React based UIs are so much easier to build and maintain than the jQuery stuff they replaced.
- kentor 10y agoYou can ask for research and proof sure, but it should be very intuitive that a delcarative, "re-render everything from props and state with a call to setState()" system is less error prone than the two way binding digest mess that is angular, or manual dom manipulations for that matter. Reminder: VirtualDOM is just an optimization of the rerender everything problem.
- rspeele 10y agoI can't make comparisons to Angular as I've never used that library. However, the point of React and the many virtual DOM libraries like it is to simplify UI code. You write a function that takes the current model state and returns the DOM tree that should be displayed in that state. If you want to change something on the UI, you swap in a new state and the whole thing is re-rendered -- at least that's the abstraction. It's a programming model that's easy to understand and hard to get wrong. That's the great thing about it! The bad thing about it is that if you implemented it naively, by actually re-rendering all the HTML for your single-page app on every state change, the performance would be awful. Virtual DOM diffing is a solution to that performance problem, and it makes applications written this way perform adequately. You can't read about React without the DOM diffing being mentioned, and library authors love to compare benchmarks, so it's easy to see virtual DOM as the feature. It's just a means to an end though.
- shados 10y agoPerformance was never the point of React. The point is to be able to (from a developer's point of view) re-render "everything", with every change, top down, without having to worry about the details. Doing that normally would be horribly slow, so React makes it adequately fast. So it's not "super mega high speed lib". It's "Gives you the ability to have a function which, given argument, renders an entire app, and can be called over and over and over" at pragmatic speed, allowing for easier code to reason about. If your primary goal is performance above all else, it's actually not that great a library.