4 ms·

It's basically like creating a diff patch, so you're close.

amelius 11y ago
It is like this: 1. Create full new version 2. Run a diff with the old version 3. Patch Because of 1, it is bound to be slow (in a computational complexity sense). Based on the popularity of React and its wide acceptance, I wonder if people learn computational complexity theory anymore these days? PS: yes I know there are tricks to make 1 faster, but these are really hacks (require extra thinking and are error-prone) and deviate from the original "React" philosophy (they are basically the old style of doing things), so these don't count.
- MrBra 11y ago
  What would it the the new style of doing things, for the non-academic rest of us ?
- lobster_johnson 11y ago
  Part of implementing an efficient React app is making sure that prop/state transitions are minimized. Coincidentally, this is also (abstractly) true about any UI technology, not just React. But React sacrifices a little bit of speed in order to make the UI declarative, as opposed to the finicky, error-prone and messy way we used to do it before with frameworks like Backbone. Have you actually developed a large React app? Because you might be surprised at how fast React really is in practice.
  - marknutter 11y ago
    Large React apps are actually no faster than large apps written in Ember or Angular, and I've personally been surprised by how slow React got on a large app. At some point, in every framework, you will run into bottlenecks and none of them provide silver bullets.
    - abritinthebay 11y ago
      > Large React apps are actually no faster than large apps written in Ember or Angular This is (more or less) true now. It wasn't when React first showed up. Angular is also only just as fast when you actively code your apps in the same way as React (basically using a prop/state system but in an Angular way). This isn't also the method generally championed in Angular (1.x anyhow). Ember was always pretty fast but post-React it changed a lot of how it did it's rendering... influenced by React! So claiming that React apps are no faster is a bit disingenuous as the reason for that is because the other frameworks saw what React was doing and agreed with it.
      - marknutter 11y ago
        Actually, simply using "track by" in Angular puts it on par with React's performance regardless of whether or not you follow React's patterns. You do understand that Angular 1.x's $scope is essentially a virtual DOM inasmuch as it's a javascript representation of the DOM which provides a more efficient means of diffing (dirty checking in Angular's case). "Virtual DOM" is just a fancy buzzword for React's solution to figuring out what to change. React's requirement that the entire DOM tree be re-rendered any time any state changes meant that dirty checking would be prohibitively expensive, so they had to come up with a clever workaround which, to their credit, ended up being just as performant as Angular's dirty checking. You can use Angular 1.x in exactly the same way you use React by only ever using 1-way binding and constructing your entire application out of directives scoped to elements. The only thing Angular 1.x doesn't let you do is use JSX, but then again, you could just use plain old javascript and imperatively build up your DOM elements (which is what JSX does under the hood anyways) if you really don't want to have .html files.
    - lobster_johnson 11y ago
      Sure, but the fact that React is as fast as those other frameworks, with none of the code overhead of having to manually patch the DOM, is a benefit. React doesn't need to be faster, it just needs to be comparably fast.
      - 11y ago
- abritinthebay 11y ago
  mmm not quite. Step 1 would be slow if it created it in a real dom but as it's not (that's why it's called a "Virtual DOM") and is in fact just an object representation of the dom it's actually rather fast. After all - it's just an object tree, and that's quite fast to parse. The diff part is probably the slowest part in the React chain actually - because it actually has to compare to the other (virtual) representation of the DOM. Deep comparisons are just... well they'll never be trivial. But no, it's really not extra thinking, it's not error prone, and it's basically due to it not really being what you're describing it as.
  - amelius 11y ago
    I think you totally missed the point. Let's say that you have a page containing a billion little images. On every update, your React-enabled code needs to create a virtual DOM containing all those images. This takes time, regardless of whether the virtual DOM is fast. Hence my point. And even if it may be only a few milliseconds for a hundred images, it will take seconds or even minutes for millions of images. And even if only 1 of the images changed. This is of course not acceptable. Most programmers are already happy if it works for 100 images. However, imagine that the inventor of quicksort invented bubblesort instead, stating it is fast enough for 100 elements. From a CS point of view, this situation is just ridiculous.

It is like this: 1. Create full new version 2. Run a diff with the old version 3. Patch Because of 1, it is bound to be slow (in a computational complexity sense). Based on the popularity of React and its wide acceptance, I wonder if people learn computational complexity theory anymore these days? PS: yes I know there are tricks to make 1 faster, but these are really hacks (require extra thinking and are error-prone) and deviate from the original "React" philosophy (they are basically the old style of doing things), so these don't count.

MrBra 11y ago
What would it the the new style of doing things, for the non-academic rest of us ?
lobster_johnson 11y ago
Part of implementing an efficient React app is making sure that prop/state transitions are minimized. Coincidentally, this is also (abstractly) true about any UI technology, not just React. But React sacrifices a little bit of speed in order to make the UI declarative, as opposed to the finicky, error-prone and messy way we used to do it before with frameworks like Backbone. Have you actually developed a large React app? Because you might be surprised at how fast React really is in practice.
- marknutter 11y ago
  Large React apps are actually no faster than large apps written in Ember or Angular, and I've personally been surprised by how slow React got on a large app. At some point, in every framework, you will run into bottlenecks and none of them provide silver bullets.
  - abritinthebay 11y ago
    > Large React apps are actually no faster than large apps written in Ember or Angular This is (more or less) true now. It wasn't when React first showed up. Angular is also only just as fast when you actively code your apps in the same way as React (basically using a prop/state system but in an Angular way). This isn't also the method generally championed in Angular (1.x anyhow). Ember was always pretty fast but post-React it changed a lot of how it did it's rendering... influenced by React! So claiming that React apps are no faster is a bit disingenuous as the reason for that is because the other frameworks saw what React was doing and agreed with it.
    - marknutter 11y ago
      Actually, simply using "track by" in Angular puts it on par with React's performance regardless of whether or not you follow React's patterns. You do understand that Angular 1.x's $scope is essentially a virtual DOM inasmuch as it's a javascript representation of the DOM which provides a more efficient means of diffing (dirty checking in Angular's case). "Virtual DOM" is just a fancy buzzword for React's solution to figuring out what to change. React's requirement that the entire DOM tree be re-rendered any time any state changes meant that dirty checking would be prohibitively expensive, so they had to come up with a clever workaround which, to their credit, ended up being just as performant as Angular's dirty checking. You can use Angular 1.x in exactly the same way you use React by only ever using 1-way binding and constructing your entire application out of directives scoped to elements. The only thing Angular 1.x doesn't let you do is use JSX, but then again, you could just use plain old javascript and imperatively build up your DOM elements (which is what JSX does under the hood anyways) if you really don't want to have .html files.
  - lobster_johnson 11y ago
    Sure, but the fact that React is as fast as those other frameworks, with none of the code overhead of having to manually patch the DOM, is a benefit. React doesn't need to be faster, it just needs to be comparably fast.
    - 11y ago
abritinthebay 11y ago
mmm not quite. Step 1 would be slow if it created it in a real dom but as it's not (that's why it's called a "Virtual DOM") and is in fact just an object representation of the dom it's actually rather fast. After all - it's just an object tree, and that's quite fast to parse. The diff part is probably the slowest part in the React chain actually - because it actually has to compare to the other (virtual) representation of the DOM. Deep comparisons are just... well they'll never be trivial. But no, it's really not extra thinking, it's not error prone, and it's basically due to it not really being what you're describing it as.
- amelius 11y ago
  I think you totally missed the point. Let's say that you have a page containing a billion little images. On every update, your React-enabled code needs to create a virtual DOM containing all those images. This takes time, regardless of whether the virtual DOM is fast. Hence my point. And even if it may be only a few milliseconds for a hundred images, it will take seconds or even minutes for millions of images. And even if only 1 of the images changed. This is of course not acceptable. Most programmers are already happy if it works for 100 images. However, imagine that the inventor of quicksort invented bubblesort instead, stating it is fast enough for 100 elements. From a CS point of view, this situation is just ridiculous.