3 ms·

>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 aro

>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?
atan 7y ago
> I'm saying that OP could do this without crapping all over React's contribution What are some specific quotes from the article that you feel are "crapping all over React's contribution"? Genuinely curious, because I don't take the tone of the article that way at all.

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?

atan 7y ago

> I'm saying that OP could do this without crapping all over React's contribution What are some specific quotes from the article that you feel are "crapping all over React's contribution"? Genuinely curious, because I don't take the tone of the article that way at all.