4 ms·

This is probably a naive question, coming from someone who has written very little JavaScript: Why do we need React? Why can’t the browser do the same job? Ins

This is probably a naive question, coming from someone who has written very little JavaScript: Why do we need React? Why can’t the browser do the same job? Instead of passing a virtual dom to react, and letting it ‘diff/patch’ the real dom, why can’t code regenerate the dom directly, in a similar way? This would seem to save both time, memory and effort, since the browser can do the diff/patch itself, much more efficiently?

quezzle 7y ago
It’s a framework. Similar questions are: Why not build rails into ruby? Why not build Django into python? Why not build qt into c++? It’s a programming flow and model, dom diffing is just one part of it.
- ken 7y ago
  Those examples are all programming languages. "Web browser" is not a programming language. It's practically a complete operating system, and they have not in the past shown much reluctance to add features to that big ball of mud, when it helps programmers.
  - galaxyLogic 7y ago
    Right. I think the value of this "React in 33 lines" article is it shows us such an API would be easy to implement and add on by the browser-makers. Would it be as fast as React? Well it wouldn't need to be, but it well could easily be since it would be implemented in native code. It could be an extension to the Shadow-DOM API, right?
masklinn 7y ago
Because the DOM is a very specific style of API which is both extremely procedural and extremely heavy, your average DOM element is full of cross-links to other elements, so generating a DOM is both a pain in the ass and quite expensive. It's also extremely stateful, so while you could generate a new DOM and replace the old one you'd lose all information in flight e.g. focus. Browsers might be able to provide a lighter vdom layer but… well first I'm not convinced the gain would be that big, and second what would the API be? It's not like there's a clear winner that has emerged, react is quite popular but hardly the only contender, and react has kept evolving its API so the sort of stability you'd want enshrined in a browser isn't exactly there.
jfkebwjsbx 7y ago
Because browsers were initially meant for another job: displaying static, declarative documents. Slowly, they gained more and more features and performance until people started creating single-page apps, where you need to re-render on state changes all the time. So people invented the best ways they could do so within the boundaries of the browser: the diff/patch approach, in order to work around the performance issues of the document model. And in some time, perhaps browsers end up standardizing a way to do this natively. Or perhaps another app-model rather than doc-model (doubtful). They already tried to start with templates and whatnot, somewhat unsuccessfully. In summary: the document model (and browsers) were not designed for that. The Web is a mess of features and features on top of features that has ended up with roughly a secondary operating system on top of a real operating system. The only (but critical) advantage of this model is that it is a de facto standard.
redis_mlc 7y ago
Vanilla-js. Werd.
pier25 7y ago
I've been saying this for years. If reactive data and data binding were solved at the browser level we'd save so many kBs and CPU cycles.
- efdee 7y ago
  If my cat was a cow, she'd give me milk. The hard part is turning my cat into a cow.
  - Silhouette 7y ago
    I'm not sure this is a great argument. Web standards and browser implementations evolve partly through absorbing ideas that lots of people are using anyway. A decade ago, no-one was using CSS variables or HTML media elements, but lots of people were using CSS preprocessors and Flash video players.
    - efdee 7y ago
      But most people are -still- using CSS preprocessors today...
Silhouette 7y ago
The big advantage of a library like React is that you can specify your UI declaratively once, instead of having to specify imperatively how to handle every possible state transition. This can dramatically reduce the number of different rendering cases you have to write if you have a lot of state to manage. All the virtual DOM stuff is just an implementation detail that makes the declarative stuff fast enough to use in production. A more naive implementation that rebuilt your entire (real) DOM on every state change would not be fast enough for anything but the most simple applications, because DOM updates in browsers are currently a relatively slow operation. Browsers could provide an API to more efficiently update large sections of the DOM at once, using a React-style diff algorithm or otherwise, but currently that isn't a feature they offer. If they did, you'd be correct that there would be less need for libraries like React.

quezzle 7y ago

It’s a framework. Similar questions are: Why not build rails into ruby? Why not build Django into python? Why not build qt into c++? It’s a programming flow and model, dom diffing is just one part of it.

ken 7y ago
Those examples are all programming languages. "Web browser" is not a programming language. It's practically a complete operating system, and they have not in the past shown much reluctance to add features to that big ball of mud, when it helps programmers.
- galaxyLogic 7y ago
  Right. I think the value of this "React in 33 lines" article is it shows us such an API would be easy to implement and add on by the browser-makers. Would it be as fast as React? Well it wouldn't need to be, but it well could easily be since it would be implemented in native code. It could be an extension to the Shadow-DOM API, right?

masklinn 7y ago

Because the DOM is a very specific style of API which is both extremely procedural and extremely heavy, your average DOM element is full of cross-links to other elements, so generating a DOM is both a pain in the ass and quite expensive. It's also extremely stateful, so while you could generate a new DOM and replace the old one you'd lose all information in flight e.g. focus. Browsers might be able to provide a lighter vdom layer but… well first I'm not convinced the gain would be that big, and second what would the API be? It's not like there's a clear winner that has emerged, react is quite popular but hardly the only contender, and react has kept evolving its API so the sort of stability you'd want enshrined in a browser isn't exactly there.

jfkebwjsbx 7y ago

Because browsers were initially meant for another job: displaying static, declarative documents. Slowly, they gained more and more features and performance until people started creating single-page apps, where you need to re-render on state changes all the time. So people invented the best ways they could do so within the boundaries of the browser: the diff/patch approach, in order to work around the performance issues of the document model. And in some time, perhaps browsers end up standardizing a way to do this natively. Or perhaps another app-model rather than doc-model (doubtful). They already tried to start with templates and whatnot, somewhat unsuccessfully. In summary: the document model (and browsers) were not designed for that. The Web is a mess of features and features on top of features that has ended up with roughly a secondary operating system on top of a real operating system. The only (but critical) advantage of this model is that it is a de facto standard.

redis_mlc 7y ago

Vanilla-js. Werd.

pier25 7y ago

I've been saying this for years. If reactive data and data binding were solved at the browser level we'd save so many kBs and CPU cycles.

efdee 7y ago
If my cat was a cow, she'd give me milk. The hard part is turning my cat into a cow.
- Silhouette 7y ago
  I'm not sure this is a great argument. Web standards and browser implementations evolve partly through absorbing ideas that lots of people are using anyway. A decade ago, no-one was using CSS variables or HTML media elements, but lots of people were using CSS preprocessors and Flash video players.
  - efdee 7y ago
    But most people are -still- using CSS preprocessors today...

Silhouette 7y ago

The big advantage of a library like React is that you can specify your UI declaratively once, instead of having to specify imperatively how to handle every possible state transition. This can dramatically reduce the number of different rendering cases you have to write if you have a lot of state to manage. All the virtual DOM stuff is just an implementation detail that makes the declarative stuff fast enough to use in production. A more naive implementation that rebuilt your entire (real) DOM on every state change would not be fast enough for anything but the most simple applications, because DOM updates in browsers are currently a relatively slow operation. Browsers could provide an API to more efficiently update large sections of the DOM at once, using a React-style diff algorithm or otherwise, but currently that isn't a feature they offer. If they did, you'd be correct that there would be less need for libraries like React.