4 ms·

So Immutability is Facebook's solution to excessive virtual DOM checks, which is Facebook's solution to the render everywhere problem, which is Facebook's solut

by JDDunn9 11y ago

So Immutability is Facebook's solution to excessive virtual DOM checks, which is Facebook's solution to the render everywhere problem, which is Facebook's solution to state change, which is a problem created by abstracting away DOM manipulation, which was never a real problem in the first place...

spion 11y ago
Maybe it wasn't, but being able to declare the UI as a function from state (viewmodel) to DOM just once, and never having to manually patch the UI to get it to the right state... is a huge development time saver. Angular did the same but went on a different path: watching the state (scope) for changes and then digesting the resulting spaghetti updates React users are simply adopting well known techniques from functional programming languages because they work well with the virtual dom concept. Except for that concept, there is nothing new being invented here.
jasim 11y ago
The chain of reasoning is wonderfully put, but DOM manipulation was definitely a problem. When elements are inserted or removed from lists, you'd have to do a dance of many jQuery() steps. There is no concept of state, it is all tangled up in DOM values, and the most elegant solution was to use $.serialize() if it works in that context. This mess was why people hated front-end programming. It has only been a year or two since Angular/React became mainstream and allowed us to think of state as plain JS objects. Lest we forget, it was truly bad times before.
Nemcue 11y ago
> which was never a real problem in the first place... You obviously haven't worked on any legacy app built in jQuery.
mambodog 11y ago
> abstracting away DOM manipulation, which was never a real problem in the first place Until you try to build a large app and get murdered by maintainability problems (eg. treating the DOM as a store of mutable state, managing event listener binding lifecycles, etc) and performance issues (eg. DOM reads and writes to occurring in an interleaved fashion inside inner loops)

by JDDunn9 11y ago

spion 11y ago

Maybe it wasn't, but being able to declare the UI as a function from state (viewmodel) to DOM just once, and never having to manually patch the UI to get it to the right state... is a huge development time saver. Angular did the same but went on a different path: watching the state (scope) for changes and then digesting the resulting spaghetti updates React users are simply adopting well known techniques from functional programming languages because they work well with the virtual dom concept. Except for that concept, there is nothing new being invented here.

jasim 11y ago

The chain of reasoning is wonderfully put, but DOM manipulation was definitely a problem. When elements are inserted or removed from lists, you'd have to do a dance of many jQuery() steps. There is no concept of state, it is all tangled up in DOM values, and the most elegant solution was to use $.serialize() if it works in that context. This mess was why people hated front-end programming. It has only been a year or two since Angular/React became mainstream and allowed us to think of state as plain JS objects. Lest we forget, it was truly bad times before.

Nemcue 11y ago

> which was never a real problem in the first place... You obviously haven't worked on any legacy app built in jQuery.

mambodog 11y ago

> abstracting away DOM manipulation, which was never a real problem in the first place Until you try to build a large app and get murdered by maintainability problems (eg. treating the DOM as a store of mutable state, managing event listener binding lifecycles, etc) and performance issues (eg. DOM reads and writes to occurring in an interleaved fashion inside inner loops)