7 ms·

React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unaccepta

React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unacceptably slow. DOM diffing isn't there to make React faster than everything else ever imagined. It's there to let you stop thinking about the DOM and focus on the world state of your frontend instead. I wasn't truly interested in React until I read this, which does a better job of spelling out React's real advantages than I ever could: http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome http://jlongster.com/Removing-User-Interface-Complexity,-or-... Here's a choice quote: "Rerendering everything (and only applying it to the DOM when something actually changed) vastly simplifies the architecture of our app. Observables+DOM elements is a leaky abstraction, and as a user I shouldn't need an intimate knowledge of how the UI is kept in sync with my data. This architecture opens up lots of various ways to optimize the rendering, but it's all completely transparent to the user."

iSnow 11y ago
The author however has focused specifically on the often read speed advantages. They use it themselves and he apparently likes it.
- feedjoelpie 11y ago
  I guess the point I'm getting at is that the virtual DOM's speed is really just the answer to the question "But isn't re-rendering the whole world over and over really slow?" Which is the first thing anyone deeply familiar with web UIs would ask. It's the solution to a problem that arises when you move to this programming model. It's the programming model that's the real advantage. The virtual DOM's speed is worth mentioning because it remedies what would otherwise make React completely impractical in the real world.
  - axemclion 11y ago
    Virtual DOM makes rendering fast, but it has extra costs in eventing and in javascript timers. Virtual DOM is not free IMHO. Some quantitative results - http://blog.nparashuram.com/2015/03/performance-comparison-on-javascript.html http://blog.nparashuram.com/2015/03/performance-comparison-o...
mikeryan 11y ago
There's an interesting video by Netflix where they discuss using React in their stack. To increase performance on many of Netflix's TV or Console based UI's they have their own rendering engine they're using instead of the manufacturer's browser engine. This means any of React's "speed" improvements are a moot point so instead they use it because of its simplicity for UI layouts. https://www.youtube.com/watch?v=eNC0mRYGWgc https://www.youtube.com/watch?v=eNC0mRYGWgc
- untog 11y ago
  Along that line of thinking, Flipboard created React Canvas, which renders directly into a <canvas> tag, bypassing a lot of the DOM: https://github.com/Flipboard/react-canvas https://github.com/Flipboard/react-canvas
Touche 11y ago
> DOM diffing isn't there to make React faster than everything else ever imagined. This is not how React has been sold.
- andybak 11y ago
  I've been following the rise of React fairly closely and the speed thing has never felt oversold to me. It was more: "Faster than angular on complex pages unless you jump through lots of hoops" and that still seems fairly reasonable.
- dangoor 11y ago
  I've seen several React talks given by Facebook people and the pitch they make is that React makes things simpler to reason about with acceptable out of the box performance (and levers to make it faster as needed). There may be some people pitching the speed angle, but I don't think it's the Facebook people.
- vruiz 11y ago
  I disagree. The main message I got was never "React faster than everything" it was rather "React makes complete DOM re-renders fast".
- dmak 11y ago
  This is the ONLY way I hear about it being sold.
strictfp 11y ago
I just have to add that this is how pages were generated server-side before XmlHttpRequest emerged. This was deliberate. Addressable and re-loadable states were part of the original design by Tim Berners-Lee. The fact that we have had this whole circus with mutable state on the client side is just a joke to me. I hope that someone invents a sane client-side lib with sane page generation quite soon. Should certainly be possible. Oh and not even performance-critical stuff like video games deal with the big mess that is mutable state. If game devs redraw their stuff at 100+ FPS and haven't needed mutable state, how come that web devs fall right into that trap? Crazy.
- mmarklar 11y ago
  I'm no AAA game dev but I'm pretty sure games are all about mutable state. I'd love to see some examples of what you're talking about.
  - strictfp 11y ago
    Sorry I should have said view state.
    - kaoD 11y ago
      The DOM is not a view. In fact it stands for Document Object Model :P I know it's confusing since it's where you create the view for your app, but the DOM is actually a model of your view (i.e. the V on your app's MVC is built manipulating the M on the browser's MVC). Why can't the web draw at 100 FPS from immutable data? Because the web renders through constraints based on the DOM, and constraints cascade, which is a problem more akin to physics in games (which are mutable for a reason) than their graphics. The bottleneck is updating such model. Also, game physics constraints are usually faster to calculate because action at a distance is unusual and there are optimizations like quad-trees. In web pages, inserting a single DOM node can trigger a huge change, making it more like simulating hydrodynamics that the common solids found in videogames.
      - strictfp 11y ago
lucisferre 11y ago
The leaky abstraction thing is at the core of everything that is wrong the the AngularJS model. I still like a number of things about AngularJS, but the data-binding model was really poorly thought out and implemented. As far as I can tell this has been recognized even by the core team and is a major reason for the sizeable changes in 2.0. It surprises me how many people in the community continue to defend it as "OK" when even the AngularJS team has arguably admitted it's mistakes.
- waps 11y ago
  I second this. The issue with angular is it's attempt to approach a functional paradigm in the UI : the UI fully mirrors the state of the data and vice-versa. React, by contrast, doesn't do state change detection and instead counts on the programmer to tell it when the state's changed. What this article is saying is that if you use the advanced hacks in angular to disable large parts of that state reflection, then angular is (almost) as fast as react. This is true, but it's very misleading : if you don't use angular the way it's designed, the way it's used in every one of their tutorials and start manually updating things ... then it's fast. That's great, but using frameworks in a way which is working around their core design principles is going to be very unpleasant.
gcb0 11y ago
> pleasant to work with if you're a startup or small shop. if you have to deal with any native code that expects to know something about the dom, now you just forced that code to do expensive and constant polling algos because you completely pulled the dom from under its feet.
- nroman 11y ago
  > small shop Like Facebook? Netflix? The BBC?
  - gcb0 11y ago
    netflix = have their own renderer. that is lot of hours of good engineers dedicated to that. facebook = probably hack away all the low level stuff they need to tweak. bbc = they probably have the same problem we have here. that does not stop them or we to boast that we use react all over the place. doesn't mean we like it.
    - ConAntonakos 11y ago
      He forgot to add Airbnb to that list.
- zem 11y ago
  i'm not a web dev, so i could be missing something obvious, but i can't think of any use cases for inspecting the dom from native code. example?
  - mc808 11y ago
    The comment makes some sense if you replace "native" with "plain" or "vanilla" JavaScript.
    - gcb0 11y ago
      yep. like 99.9% of the code ad networks expect. they want to check DOM state to make sure you are not a sleazy publisher hiding the ads under the content or if you are not being shown in an iframe on some porn site. with react, they will get inconclusive results because their code might run while they are virtualized or god forbid during the render. and you will only get garbage ads because now they consider you a garbage publisher.
agmcleod 11y ago
I completely agree. Trying out react and learning how to structure things with it. It all just felt natural.
curun1r 11y ago
> Observables+DOM elements is a leaky abstraction The DOM itself is also a leaky abstraction. Render cycles are so prohibitively slow that we've started maintaining a parallel DOM and implementing diffing algorithms in JavaScript. As brilliant as that may be, it's also crazy that it's come to that. This is a problem that should be solved in the browser. HTML5 should add a simple API to transactionally update the DOM and only render after all changes are committed. This would prevent every single framework from having to implement this logic.
- michaelchisari 11y ago
  Seeing as how ES6/7, HTML5 and CSS3 specs haven't been afraid to incorporate ideas that started in external libraries, I do hope we see this baked directly into the browser at some point.
- sanderjd 11y ago
  For what it's worth, transactional DOM update is a fantastic idea that I hadn't heard before your comment. Are you familiar with anyone actively exploring such a thing?
- mikaraento 11y ago
  The DOM _is_ only rendered after your JavaScript is finished running - as long as you don't ask for properties that can only be known By rendering it out.
- yid 11y ago
  It's not "crazy", it's basically just double buffering, a technique that has been around for a very long time.
- aflinik 11y ago
  I remember React devs saying they always remember about that, so the whole library is designed to be easily detachable from the DOM, or whatever renderer you might be using. They're also kind of proving that now with ReactNative, and knowing what's coming in the next React versions it's gonna be even better. Nice thing about React is that even after you remove the Virtual DOM it still encourages a really good model of programming and makes it effortless to build your app.
jszymborski 11y ago
The little time I've spent learning Mithril [1] makes me think it's a nice middle ground between speed and pleasurable coding experience. Their benchmarks have it at 8x faster at rendering (uncompiled) and 28x faster to load (although Benchmarks Lie (TM)). It feels like writing vanilla javascript for the most part, which is delightful and exciting. The Views part however, which is most comparable with React since React only deals with views, is extremely reminiscent of React, and you can even write MSX, which is just basically JSX with some subtle differences. [1] http://mithril.js.org/ http://mithril.js.org/ EDIT: Link
- zserge 11y ago
  Mithril is awesome (been using it for 7 months now). I really like that they finally have implemented components and described how they should be made.
  - ufo 11y ago
    Whats the situation about components now? Last time I checked this a while ago React would encourage having lots of components with internal state and calling setState on a subcomponent would only update the DOM on that subtree. On the other hand, most other virtualdom frameworks they would encourage you to keep a single global model object to describe the whole page.
- kholbekj 11y ago
  "It feels like writing vanilla javascript for the most part, which is delightful and exciting." - this sentence makes me shiver. That being said, this looks interesting, thanks for bringing it to attention!
  - jszymborski 11y ago
    ahaha I understand why it would. I meant that the framework is extremely unobtrusive. All you do is create the beautiful expressive javascript objects which act as your models and controls, and then you just mount it with a mithril command, and that's it!
whoisthemachine 11y ago
I agree completely - I've been recently using React to build a static website, and it's a joy to use over standard HTML, or something rendered server side. Being able to split apart the different parts of your page into small components makes it easy to reason about without needing to take an entire page in. The fact that you can then transfer that to a dynamic website with reasonably good performance is huge IMO.
rowdybully 11y ago
Ugh, React people... Please stop saying "Reason about". Did you ever use that phrase even once in your life before you started using React? Just say that the code is more understandable or whatever.

iSnow 11y ago

The author however has focused specifically on the often read speed advantages. They use it themselves and he apparently likes it.

feedjoelpie 11y ago
I guess the point I'm getting at is that the virtual DOM's speed is really just the answer to the question "But isn't re-rendering the whole world over and over really slow?" Which is the first thing anyone deeply familiar with web UIs would ask. It's the solution to a problem that arises when you move to this programming model. It's the programming model that's the real advantage. The virtual DOM's speed is worth mentioning because it remedies what would otherwise make React completely impractical in the real world.
- axemclion 11y ago
  Virtual DOM makes rendering fast, but it has extra costs in eventing and in javascript timers. Virtual DOM is not free IMHO. Some quantitative results - http://blog.nparashuram.com/2015/03/performance-comparison-on-javascript.html http://blog.nparashuram.com/2015/03/performance-comparison-o...

mikeryan 11y ago

There's an interesting video by Netflix where they discuss using React in their stack. To increase performance on many of Netflix's TV or Console based UI's they have their own rendering engine they're using instead of the manufacturer's browser engine. This means any of React's "speed" improvements are a moot point so instead they use it because of its simplicity for UI layouts. https://www.youtube.com/watch?v=eNC0mRYGWgc https://www.youtube.com/watch?v=eNC0mRYGWgc

untog 11y ago
Along that line of thinking, Flipboard created React Canvas, which renders directly into a <canvas> tag, bypassing a lot of the DOM: https://github.com/Flipboard/react-canvas https://github.com/Flipboard/react-canvas

Touche 11y ago

> DOM diffing isn't there to make React faster than everything else ever imagined. This is not how React has been sold.

andybak 11y ago
I've been following the rise of React fairly closely and the speed thing has never felt oversold to me. It was more: "Faster than angular on complex pages unless you jump through lots of hoops" and that still seems fairly reasonable.
dangoor 11y ago
I've seen several React talks given by Facebook people and the pitch they make is that React makes things simpler to reason about with acceptable out of the box performance (and levers to make it faster as needed). There may be some people pitching the speed angle, but I don't think it's the Facebook people.
vruiz 11y ago
I disagree. The main message I got was never "React faster than everything" it was rather "React makes complete DOM re-renders fast".
dmak 11y ago
This is the ONLY way I hear about it being sold.

strictfp 11y ago

I just have to add that this is how pages were generated server-side before XmlHttpRequest emerged. This was deliberate. Addressable and re-loadable states were part of the original design by Tim Berners-Lee. The fact that we have had this whole circus with mutable state on the client side is just a joke to me. I hope that someone invents a sane client-side lib with sane page generation quite soon. Should certainly be possible. Oh and not even performance-critical stuff like video games deal with the big mess that is mutable state. If game devs redraw their stuff at 100+ FPS and haven't needed mutable state, how come that web devs fall right into that trap? Crazy.

mmarklar 11y ago
I'm no AAA game dev but I'm pretty sure games are all about mutable state. I'd love to see some examples of what you're talking about.
- strictfp 11y ago
  Sorry I should have said view state.
  - kaoD 11y ago
    The DOM is not a view. In fact it stands for Document Object Model :P I know it's confusing since it's where you create the view for your app, but the DOM is actually a model of your view (i.e. the V on your app's MVC is built manipulating the M on the browser's MVC). Why can't the web draw at 100 FPS from immutable data? Because the web renders through constraints based on the DOM, and constraints cascade, which is a problem more akin to physics in games (which are mutable for a reason) than their graphics. The bottleneck is updating such model. Also, game physics constraints are usually faster to calculate because action at a distance is unusual and there are optimizations like quad-trees. In web pages, inserting a single DOM node can trigger a huge change, making it more like simulating hydrodynamics that the common solids found in videogames.
    - strictfp 11y ago

lucisferre 11y ago

The leaky abstraction thing is at the core of everything that is wrong the the AngularJS model. I still like a number of things about AngularJS, but the data-binding model was really poorly thought out and implemented. As far as I can tell this has been recognized even by the core team and is a major reason for the sizeable changes in 2.0. It surprises me how many people in the community continue to defend it as "OK" when even the AngularJS team has arguably admitted it's mistakes.

waps 11y ago
I second this. The issue with angular is it's attempt to approach a functional paradigm in the UI : the UI fully mirrors the state of the data and vice-versa. React, by contrast, doesn't do state change detection and instead counts on the programmer to tell it when the state's changed. What this article is saying is that if you use the advanced hacks in angular to disable large parts of that state reflection, then angular is (almost) as fast as react. This is true, but it's very misleading : if you don't use angular the way it's designed, the way it's used in every one of their tutorials and start manually updating things ... then it's fast. That's great, but using frameworks in a way which is working around their core design principles is going to be very unpleasant.

gcb0 11y ago

> pleasant to work with if you're a startup or small shop. if you have to deal with any native code that expects to know something about the dom, now you just forced that code to do expensive and constant polling algos because you completely pulled the dom from under its feet.

nroman 11y ago
> small shop Like Facebook? Netflix? The BBC?
- gcb0 11y ago
  netflix = have their own renderer. that is lot of hours of good engineers dedicated to that. facebook = probably hack away all the low level stuff they need to tweak. bbc = they probably have the same problem we have here. that does not stop them or we to boast that we use react all over the place. doesn't mean we like it.
  - ConAntonakos 11y ago
    He forgot to add Airbnb to that list.
zem 11y ago
i'm not a web dev, so i could be missing something obvious, but i can't think of any use cases for inspecting the dom from native code. example?
- mc808 11y ago
  The comment makes some sense if you replace "native" with "plain" or "vanilla" JavaScript.
  - gcb0 11y ago
    yep. like 99.9% of the code ad networks expect. they want to check DOM state to make sure you are not a sleazy publisher hiding the ads under the content or if you are not being shown in an iframe on some porn site. with react, they will get inconclusive results because their code might run while they are virtualized or god forbid during the render. and you will only get garbage ads because now they consider you a garbage publisher.

agmcleod 11y ago

I completely agree. Trying out react and learning how to structure things with it. It all just felt natural.

curun1r 11y ago

> Observables+DOM elements is a leaky abstraction The DOM itself is also a leaky abstraction. Render cycles are so prohibitively slow that we've started maintaining a parallel DOM and implementing diffing algorithms in JavaScript. As brilliant as that may be, it's also crazy that it's come to that. This is a problem that should be solved in the browser. HTML5 should add a simple API to transactionally update the DOM and only render after all changes are committed. This would prevent every single framework from having to implement this logic.

michaelchisari 11y ago
Seeing as how ES6/7, HTML5 and CSS3 specs haven't been afraid to incorporate ideas that started in external libraries, I do hope we see this baked directly into the browser at some point.
sanderjd 11y ago
For what it's worth, transactional DOM update is a fantastic idea that I hadn't heard before your comment. Are you familiar with anyone actively exploring such a thing?
mikaraento 11y ago
The DOM _is_ only rendered after your JavaScript is finished running - as long as you don't ask for properties that can only be known By rendering it out.
yid 11y ago
It's not "crazy", it's basically just double buffering, a technique that has been around for a very long time.
aflinik 11y ago
I remember React devs saying they always remember about that, so the whole library is designed to be easily detachable from the DOM, or whatever renderer you might be using. They're also kind of proving that now with ReactNative, and knowing what's coming in the next React versions it's gonna be even better. Nice thing about React is that even after you remove the Virtual DOM it still encourages a really good model of programming and makes it effortless to build your app.

jszymborski 11y ago

The little time I've spent learning Mithril [1] makes me think it's a nice middle ground between speed and pleasurable coding experience. Their benchmarks have it at 8x faster at rendering (uncompiled) and 28x faster to load (although Benchmarks Lie (TM)). It feels like writing vanilla javascript for the most part, which is delightful and exciting. The Views part however, which is most comparable with React since React only deals with views, is extremely reminiscent of React, and you can even write MSX, which is just basically JSX with some subtle differences. [1] http://mithril.js.org/ http://mithril.js.org/ EDIT: Link

zserge 11y ago
Mithril is awesome (been using it for 7 months now). I really like that they finally have implemented components and described how they should be made.
- ufo 11y ago
  Whats the situation about components now? Last time I checked this a while ago React would encourage having lots of components with internal state and calling setState on a subcomponent would only update the DOM on that subtree. On the other hand, most other virtualdom frameworks they would encourage you to keep a single global model object to describe the whole page.
kholbekj 11y ago
"It feels like writing vanilla javascript for the most part, which is delightful and exciting." - this sentence makes me shiver. That being said, this looks interesting, thanks for bringing it to attention!
- jszymborski 11y ago
  ahaha I understand why it would. I meant that the framework is extremely unobtrusive. All you do is create the beautiful expressive javascript objects which act as your models and controls, and then you just mount it with a mithril command, and that's it!

whoisthemachine 11y ago

I agree completely - I've been recently using React to build a static website, and it's a joy to use over standard HTML, or something rendered server side. Being able to split apart the different parts of your page into small components makes it easy to reason about without needing to take an entire page in. The fact that you can then transfer that to a dynamic website with reasonably good performance is huge IMO.

rowdybully 11y ago

Ugh, React people... Please stop saying "Reason about". Did you ever use that phrase even once in your life before you started using React? Just say that the code is more understandable or whatever.