5 ms·

> react wasn't particularly innovative on that front (e.g. the declarative model already existed in angular, knockout, etc) React was absolutely a breath of fr

> react wasn't particularly innovative on that front (e.g. the declarative model already existed in angular, knockout, etc) React was absolutely a breath of fresh air when it was released. Knockout was similar to Solid.js in that they both have functions that you call which then log a data dependency, then when the data changes the UI updates. This led to lots of pain, because instead of a plain value, you have functions which return values, and you need to be very careful about when those functions are called, otherwise the data dependency might not be tracked properly. Angular had a similar issue, as its state-based observation relied on special scopes. Updates in the wrong scope could be lost or delayed. React’s approach of only diffing the rendered UI rather than trying to drive updates based on diffs of the input data was vastly simpler, it was much easier to understand the data flow through explicit state and props.

ricardobeat 5y ago
We also had ractive.js, we had mithril, intercooler.js (now htmx), we even had (fab).js as far back as 2010 with functional rendering. A 'breath of fresh air' pretty much depends on what you had been breathing.
- mst 5y ago
  React wasn't exactly innovative as such so much as it was a very carefully designed (I don't mean they didn't make mistakes, mind, only that they clearly put effort into making new and exciting mistakes) implementation of the model that successfully broke into the mainstream. The phrase "an idea whose time had come" springs to mind. (this comment is intended to read as professional respect, not fanboying - the extent to which I succeeded in that intension must inevitably be left as an exercise for the reader)
  - robertlagrant 5y ago
    > they clearly put effort into making new and exciting mistakes Very good.
lhorie 5y ago
React also requires that you call functions to trigger rendering (be it via setState or `[, setFoo] = useState()`) and it definitely has warts that trip people up too (e.g. semantics of calling setState twice synchronously). The dependencies array in useEffect is also conceptually the same mechanism you claim causes pain in Knockout. IMHO, historically, the bigger pain point with the reactive model was data marshaling/unmarshaling (e.g. updating some subtree of data and then needing to send the root of the data tree to the server while maintaining reactive bindings across a large app and being careful not to fragment source of truth). Ironically, React can also end up in this predicament, because the encapsulation model of its `state` mechanism means extracting the actual state of the component tree is non trivial unless you're using a third party state lib to avoid it altogether in the first place, or at least use useReducer, which is a relatively new addition to React (and even then, it's kinda jank). These days, React is a hodge podge of many different implementation approaches. Yes, there are props, but Context also exists - and is used extensively in the wild - precisely because props get clunky, and then there's data diffing happening to support `memo`, on top of the virtual dom change tracking. Suspense basically requires your code to adhere to semantic restrictions, i.e. you're not even in control of when your component function is called, which leads to having to tip-toe around that scope w/ extra closures, which in turn leads to all the issues that the article touches on. The hodge podge issue isn't specific to React; Vue is also seeing pain points from having so many ways of doing things now that they're trying to push a v3 and realizing ecosystems tend to slog. To your point, yes React was relatively simple when it came out, but as I mentioned, it wasn't the first to take a stab at the declarative model, nor the simplest. It just benefited greatly from the popularity wave of the golden years of Facebook OSS engineering. And from a practical perspective, it doesn't really matter what React was. Idiomatic usage is a thing, and React development today isn't like React development 7 years ago.

ricardobeat 5y ago

We also had ractive.js, we had mithril, intercooler.js (now htmx), we even had (fab).js as far back as 2010 with functional rendering. A 'breath of fresh air' pretty much depends on what you had been breathing.

mst 5y ago
React wasn't exactly innovative as such so much as it was a very carefully designed (I don't mean they didn't make mistakes, mind, only that they clearly put effort into making new and exciting mistakes) implementation of the model that successfully broke into the mainstream. The phrase "an idea whose time had come" springs to mind. (this comment is intended to read as professional respect, not fanboying - the extent to which I succeeded in that intension must inevitably be left as an exercise for the reader)
- robertlagrant 5y ago
  > they clearly put effort into making new and exciting mistakes Very good.

lhorie 5y ago

React also requires that you call functions to trigger rendering (be it via setState or `[, setFoo] = useState()`) and it definitely has warts that trip people up too (e.g. semantics of calling setState twice synchronously). The dependencies array in useEffect is also conceptually the same mechanism you claim causes pain in Knockout. IMHO, historically, the bigger pain point with the reactive model was data marshaling/unmarshaling (e.g. updating some subtree of data and then needing to send the root of the data tree to the server while maintaining reactive bindings across a large app and being careful not to fragment source of truth). Ironically, React can also end up in this predicament, because the encapsulation model of its `state` mechanism means extracting the actual state of the component tree is non trivial unless you're using a third party state lib to avoid it altogether in the first place, or at least use useReducer, which is a relatively new addition to React (and even then, it's kinda jank). These days, React is a hodge podge of many different implementation approaches. Yes, there are props, but Context also exists - and is used extensively in the wild - precisely because props get clunky, and then there's data diffing happening to support `memo`, on top of the virtual dom change tracking. Suspense basically requires your code to adhere to semantic restrictions, i.e. you're not even in control of when your component function is called, which leads to having to tip-toe around that scope w/ extra closures, which in turn leads to all the issues that the article touches on. The hodge podge issue isn't specific to React; Vue is also seeing pain points from having so many ways of doing things now that they're trying to push a v3 and realizing ecosystems tend to slog. To your point, yes React was relatively simple when it came out, but as I mentioned, it wasn't the first to take a stab at the declarative model, nor the simplest. It just benefited greatly from the popularity wave of the golden years of Facebook OSS engineering. And from a practical perspective, it doesn't really matter what React was. Idiomatic usage is a thing, and React development today isn't like React development 7 years ago.