7 ms·

React is not pure at all, and has a few gotchas related to updates. That being said, the JSX and composability of it is unmatched and I think the main reason Re

by bloomca 11mo ago

React is not pure at all, and has a few gotchas related to updates. That being said, the JSX and composability of it is unmatched and I think the main reason React "won". I think a logical continuation of this model is something like Solid.js, where there is no concept of re-rendering, just atomic DOM updates when observables change their values, but somehow this approach didn't get critical traction.

greener_grass 11mo ago
It exists, but as a Haskell library called Reflex. This is why it didn't gain traction ;)
kybernetikos 11mo ago
Knockout js worked something like that. There are complexities with the observable approach though, especially around batched updates and avoiding update loops.
- embedding-shape 11mo ago
  Not to mention debugging Knockout.js applications was as complex as debugging jQuery applications, mutable state that can be changed from anywhere and from any direction makes it really hard to see what's going on. React was a breadth of fresh air when it appeared.
embedding-shape 11mo ago
Nothing of value is 100% "pure", eventually you are gonna need to draw something to the screen, so trying to reach that sort of utopia seems futile. With that said, the "mental model" of React, or maybe the focus, is "pure" where it matters, namely that you have data, pass it through a function, and you get a view/UI, and if you pass the same data, you get the same UI, regardless of what happened before. When it appeared, was very different from us web developers were used to, where sometimes the DOM even was our data store, and mutation was the name of the game. So when people say "React is pure", I don't think they're talking about internally, or "100% pure", just that the mental model you need to adjust to is that the UI gets created from (mostly) pure functions. Of course, this all breaks down once the frontend application actually runs in a browser, but that doesn't mean it isn't valuable for the developer as things gets a lot simpler. Not disagreeing with you in the end I guess, just clarifying for those who might not be familiar with React, and get confused when some people say it's pure, while others don't. Both are right :)
- valenterry 11mo ago
  Nope, that is precisely what pure functional programming is about: to turn actions like "draw something to the screen" into regular values that you can store into a variable, pass around, return from a function and so on. It's not an utopia. It will eventually happen and it will replace how react.js currently works. effect.website will probably be the foundation.
  - embedding-shape 11mo ago
    I'm well aware of what "pure functional programming" is about, I spend most of my time in Clojure during a normal work day, and done my fair deal of Haskell too :) And yes, even the most pure functional language eventually needs to do something non-pure, even if the entire flow up until that point is pure, that last step (IO) just cannot be pure, no matter how badly you want it to. With that said, you'd have to pry my pure functions out of my cold dead hands, but I'm not living under the illusion that every function can be pure in a typical application, unless you have no outputs at all.
    - deleted 11mo ago
      [deleted]
    - valenterry 11mo ago
      That last step is still pure, because it's still just return a value. A data-structure. You did Haskell, so you should know how it works.
dmix 11mo ago
> I think a logical continuation of this model is something like Solid.js, where there is no concept of re-rendering, just atomic DOM updates when observables change their values, I believe Vue is going in that direction https://www.vuemastery.com/blog/the-future-of-vue-vapor-mode/#how-vues-vapor-mode-works https://www.vuemastery.com/blog/the-future-of-vue-vapor-mode...
mpweiher 11mo ago
> React is not pure at all Yeah, my pull request to make the documentation honest about this has languished. https://github.com/reactjs/react-basic/pull/12 https://github.com/reactjs/react-basic/pull/12

by bloomca 11mo ago

greener_grass 11mo ago

It exists, but as a Haskell library called Reflex. This is why it didn't gain traction ;)

kybernetikos 11mo ago

Knockout js worked something like that. There are complexities with the observable approach though, especially around batched updates and avoiding update loops.

embedding-shape 11mo ago
Not to mention debugging Knockout.js applications was as complex as debugging jQuery applications, mutable state that can be changed from anywhere and from any direction makes it really hard to see what's going on. React was a breadth of fresh air when it appeared.

embedding-shape 11mo ago

Nothing of value is 100% "pure", eventually you are gonna need to draw something to the screen, so trying to reach that sort of utopia seems futile. With that said, the "mental model" of React, or maybe the focus, is "pure" where it matters, namely that you have data, pass it through a function, and you get a view/UI, and if you pass the same data, you get the same UI, regardless of what happened before. When it appeared, was very different from us web developers were used to, where sometimes the DOM even was our data store, and mutation was the name of the game. So when people say "React is pure", I don't think they're talking about internally, or "100% pure", just that the mental model you need to adjust to is that the UI gets created from (mostly) pure functions. Of course, this all breaks down once the frontend application actually runs in a browser, but that doesn't mean it isn't valuable for the developer as things gets a lot simpler. Not disagreeing with you in the end I guess, just clarifying for those who might not be familiar with React, and get confused when some people say it's pure, while others don't. Both are right :)

valenterry 11mo ago
Nope, that is precisely what pure functional programming is about: to turn actions like "draw something to the screen" into regular values that you can store into a variable, pass around, return from a function and so on. It's not an utopia. It will eventually happen and it will replace how react.js currently works. effect.website will probably be the foundation.
- embedding-shape 11mo ago
  I'm well aware of what "pure functional programming" is about, I spend most of my time in Clojure during a normal work day, and done my fair deal of Haskell too :) And yes, even the most pure functional language eventually needs to do something non-pure, even if the entire flow up until that point is pure, that last step (IO) just cannot be pure, no matter how badly you want it to. With that said, you'd have to pry my pure functions out of my cold dead hands, but I'm not living under the illusion that every function can be pure in a typical application, unless you have no outputs at all.
  - deleted 11mo ago
    [deleted]
  - valenterry 11mo ago
    That last step is still pure, because it's still just return a value. A data-structure. You did Haskell, so you should know how it works.

dmix 11mo ago

> I think a logical continuation of this model is something like Solid.js, where there is no concept of re-rendering, just atomic DOM updates when observables change their values, I believe Vue is going in that direction https://www.vuemastery.com/blog/the-future-of-vue-vapor-mode/#how-vues-vapor-mode-works https://www.vuemastery.com/blog/the-future-of-vue-vapor-mode...

mpweiher 11mo ago

> React is not pure at all Yeah, my pull request to make the documentation honest about this has languished. https://github.com/reactjs/react-basic/pull/12 https://github.com/reactjs/react-basic/pull/12