4 ms·

In short - the DOM was often used to store state. And this just isn't a very efficient approach. By some people, sure, but separating state and business logic

In short - the DOM was often used to store state. And this just isn't a very efficient approach. By some people, sure, but separating state and business logic from presentation and rendering logic was a well-known idea many, many years before React was around. I think the basic premise of the article here is correct. The important development with React that hadn’t previously been widely seen in front-end, JS-based web development wasn’t the virtual DOM, it was the declarative description of the rendered content — building it in absolute terms from the current state, not in relative terms from the current and previous state. The virtual DOM is a means to that end: it makes that approach fast enough that it can be used with acceptable performance for a lot of realistic applications. This doesn’t change the fact that the declare-and-diff strategy is extremely expensive compared to actively observing only necessary changes in the underlying state and making only necessary local updates in the (real) DOM. In a typical web app, if there is such a thing, that might not matter very much. In more demanding cases, say when you’ve got tables with thousands of cells or you’re drawing a complicated diagram with SVG, it’s still all too easy to run into performance lag with any library that uses this strategy. Then you start using escape hatches like shouldComponentUpdate or using lifecycle methods to manipulate the (real) DOM directly rather than rendering through React, at which point you’re not really benefitting from React at all for that particular component (though of course you might still be benefitting from it for the other 90% of your UI code and incorporating the rest into the same overall design using those escape hatches might make sense in that situation).

oraphalous 7y ago
>By some people, sure, but separating state and business logic from presentation and rendering logic was a well-known idea many, many years before React was around. My claim is that this isn't a good representation of the FE culture as a whole - even if there were islands of enlightment out there. Hell, just about all of the enterprise codebases I get contracted to work on are STILL do state management the old way. So no - I don't agree the basic premise of the article is correct. >The important development with React that hadn’t previously been widely seen in front-end, JS-based web development wasn’t the virtual DOM, it was the declarative description of the rendered content — building it in absolute terms from the current state, not in relative terms from the current and previous state. You are ignoring that fact that the VDOM was the imperative implementation they used under the hood to make the declarative api work. It's the VDOM that allowed them to take state management out of the DOM - and thus why they claimed that the VDOM was faster than the DOM. Sure - if other folks are finding other implementation approaches that allow one to keep state out of the DOM in even better ways - that's great. That doesn't mean it wasn't reasonable at the time to identify the VDOM with that central innovation since there wasn't many other people doing it in other ways. >This doesn’t change the fact that the declare-and-diff strategy is extremely expensive compared to actively observing only necessary changes in the underlying state and making only necessary local updates in the (real) DOM. I'm not arguing this case one way or another... I don't claim to know. The OP is certainly welcome by me to try to continue making that case. I think that's a good contribution to make. I'm saying that OP could do this without crapping all over React's contribution - which tbh honest smells like a status move in order to obtain more market share. Wanting more market share is fine - but it should be enough to just compare the performance between the two to make that case. Don't straw man a "meme" to attack a competitor's status.
- Chris_Newton 7y ago
  My claim is that this isn't a good representation of the FE culture as a whole - even if there were islands of enlightment out there. I can’t really dispute that since I don’t have any useful statistical evidence. All I can say is that in my experience there were mostly two types of people working on front-ends to run in browsers in the early days: Web designers who learned programming, and programmers who learned the basic Web technologies and/or plugins. (Today, with the industry being somewhat more mature, I’d say there’s a third group, who come straight into full-on front-end programming of JS-based web UIs at the same time as they’re learning HTML and CSS.) Crucially, this means you have some web developers who have broader programming experience and/or formal training, and others whose knowledge mostly comes from online tutorials and QA sites and from the knowledge and culture passed on by their peers. The former type probably have some understanding of software architecture for more substantial applications, and might well have had a reasonably systematic data model, separated business rules from the rendering(s) of the underlying data, and so on. The latter type often aren’t aware of these concepts and tend to write much more hacky code — such as keeping application state in the DOM — because they don’t know any better. Adopting a comprehensive framework can mitigate that lack of knowledge to some extent, which I suspect is a big part of why the heavyweight frameworks caught on in front-end work just as they did in desktop UI work earlier, but ultimately there’s still no substitute for knowing what you’re doing. Today the same type of people who used to keep their application state in an ad-hoc mix of scattered variables and the DOM are trying to build their entire application architecture with React components and either scattering the state and business logic throughout those components or, in some cases, adopting a heavyweight data management architecture like Redux instead.
  - infinite8s 7y ago
    There is a fourth group of people who used to build desktop apps applying the same approach to building webapps (no server generated HTML, treat the DOM as a retained mode widget set, and have a pure js data model). Two examples of this are JupyterLab and VSCode.
- ups101 7y ago
  > It's the VDOM that allowed them to take state management out of the DOM - and thus why they claimed that the VDOM was faster than the DOM. Do you have a reference to this claim?
ng12 7y ago
> but separating state and business logic from presentation and rendering logic I think the parent was referring to something different. When you work directly with the DOM your _view_ logic is stateful. In the old days (jQuery, Bootstrap, Knockout, etc) you were spending a time simply keeping your data and your view in sync -- and god forbid you were trying to re-use some of that view logic in multiple places.
- Chris_Newton 7y ago
  In the old days (jQuery, Bootstrap, Knockout, etc) you were spending a time simply keeping your data and your view in sync -- and god forbid you were trying to re-use some of that view logic in multiple places. Sure, and we had the era of one-way or two-way data binding libraries as a response to doing that manually, which at least provided a quick, simple solution to that problem in the relatively common case where you were presenting a set of mostly independent data points. However, we also had designs that were based on ideas like MVC (the original one, not the server-side framework style that hijacked the term later) where you had part of your code storing the real state, event handlers triggering updates to that state in response to user actions, and rendering code that was triggered in turn to redraw the relevant parts of the UI or update the contents of any affected form fields. This sort of architecture was using essentially the same set of software architecture ideas that we’d been using in desktop or more traditional client-server software for a long time and applying them in the context of JS (or Flash, Java, etc.) running the browser.
madeofpalk 7y ago
> it was the declarative description of the rendered content this is absolutely the 'revolution' that React brought front end centre - declarative UI's for the web. This is why people that enjoy working with react enjoy it so much, whether they know it or not.

oraphalous 7y ago

>By some people, sure, but separating state and business logic from presentation and rendering logic was a well-known idea many, many years before React was around. My claim is that this isn't a good representation of the FE culture as a whole - even if there were islands of enlightment out there. Hell, just about all of the enterprise codebases I get contracted to work on are STILL do state management the old way. So no - I don't agree the basic premise of the article is correct. >The important development with React that hadn’t previously been widely seen in front-end, JS-based web development wasn’t the virtual DOM, it was the declarative description of the rendered content — building it in absolute terms from the current state, not in relative terms from the current and previous state. You are ignoring that fact that the VDOM was the imperative implementation they used under the hood to make the declarative api work. It's the VDOM that allowed them to take state management out of the DOM - and thus why they claimed that the VDOM was faster than the DOM. Sure - if other folks are finding other implementation approaches that allow one to keep state out of the DOM in even better ways - that's great. That doesn't mean it wasn't reasonable at the time to identify the VDOM with that central innovation since there wasn't many other people doing it in other ways. >This doesn’t change the fact that the declare-and-diff strategy is extremely expensive compared to actively observing only necessary changes in the underlying state and making only necessary local updates in the (real) DOM. I'm not arguing this case one way or another... I don't claim to know. The OP is certainly welcome by me to try to continue making that case. I think that's a good contribution to make. I'm saying that OP could do this without crapping all over React's contribution - which tbh honest smells like a status move in order to obtain more market share. Wanting more market share is fine - but it should be enough to just compare the performance between the two to make that case. Don't straw man a "meme" to attack a competitor's status.

Chris_Newton 7y ago
My claim is that this isn't a good representation of the FE culture as a whole - even if there were islands of enlightment out there. I can’t really dispute that since I don’t have any useful statistical evidence. All I can say is that in my experience there were mostly two types of people working on front-ends to run in browsers in the early days: Web designers who learned programming, and programmers who learned the basic Web technologies and/or plugins. (Today, with the industry being somewhat more mature, I’d say there’s a third group, who come straight into full-on front-end programming of JS-based web UIs at the same time as they’re learning HTML and CSS.) Crucially, this means you have some web developers who have broader programming experience and/or formal training, and others whose knowledge mostly comes from online tutorials and QA sites and from the knowledge and culture passed on by their peers. The former type probably have some understanding of software architecture for more substantial applications, and might well have had a reasonably systematic data model, separated business rules from the rendering(s) of the underlying data, and so on. The latter type often aren’t aware of these concepts and tend to write much more hacky code — such as keeping application state in the DOM — because they don’t know any better. Adopting a comprehensive framework can mitigate that lack of knowledge to some extent, which I suspect is a big part of why the heavyweight frameworks caught on in front-end work just as they did in desktop UI work earlier, but ultimately there’s still no substitute for knowing what you’re doing. Today the same type of people who used to keep their application state in an ad-hoc mix of scattered variables and the DOM are trying to build their entire application architecture with React components and either scattering the state and business logic throughout those components or, in some cases, adopting a heavyweight data management architecture like Redux instead.
- infinite8s 7y ago
  There is a fourth group of people who used to build desktop apps applying the same approach to building webapps (no server generated HTML, treat the DOM as a retained mode widget set, and have a pure js data model). Two examples of this are JupyterLab and VSCode.
ups101 7y ago
> It's the VDOM that allowed them to take state management out of the DOM - and thus why they claimed that the VDOM was faster than the DOM. Do you have a reference to this claim?

ng12 7y ago

> but separating state and business logic from presentation and rendering logic I think the parent was referring to something different. When you work directly with the DOM your _view_ logic is stateful. In the old days (jQuery, Bootstrap, Knockout, etc) you were spending a time simply keeping your data and your view in sync -- and god forbid you were trying to re-use some of that view logic in multiple places.

Chris_Newton 7y ago
In the old days (jQuery, Bootstrap, Knockout, etc) you were spending a time simply keeping your data and your view in sync -- and god forbid you were trying to re-use some of that view logic in multiple places. Sure, and we had the era of one-way or two-way data binding libraries as a response to doing that manually, which at least provided a quick, simple solution to that problem in the relatively common case where you were presenting a set of mostly independent data points. However, we also had designs that were based on ideas like MVC (the original one, not the server-side framework style that hijacked the term later) where you had part of your code storing the real state, event handlers triggering updates to that state in response to user actions, and rendering code that was triggered in turn to redraw the relevant parts of the UI or update the contents of any affected form fields. This sort of architecture was using essentially the same set of software architecture ideas that we’d been using in desktop or more traditional client-server software for a long time and applying them in the context of JS (or Flash, Java, etc.) running the browser.

madeofpalk 7y ago

> it was the declarative description of the rendered content this is absolutely the 'revolution' that React brought front end centre - declarative UI's for the web. This is why people that enjoy working with react enjoy it so much, whether they know it or not.