8 ms·

How is it that React gets celebrated for “solving” problems that React created in the first place? The entire paradigm of React keeps changing as each pervious

How is it that React gets celebrated for “solving” problems that React created in the first place? The entire paradigm of React keeps changing as each pervious iteration proves to be “messy” or “over complicated.” createClass? Nah that’s obsolete. Mixins and HOC - oh wait, bad idea, hooks to the rescue! At what point do people start to call BS and say you shouldn’t build around a framework that needs to be reinvented every year or two?

sophiebits 8y ago
(I worked on React.) Many people have adopted React and are happy with it, evidently because they believe the problems it creates are minor compared to the problems it fixes. It’s rather reasonable for them to be excited about a new version that keeps (or improves!) the good parts while having fewer tradeoffs.
- jen729w 8y ago
  React is amazing. I'm teaching myself JS — started October '17 — and I've gone through a few iterations of my little project as I learn more. - Vanilla JS: it works, but holy moly it looks bad and the amount of code I have to write to do even basic stuff really really hurts my brain. (Actually what am I talking about, it never got close to "working" before I moved on to...) - jQuery/Node: ooh, this is better. But still, doing stuff takes ages. - React: OH MY GOD WHAT IS THIS HEAVEN. People will say that "people like me" shouldn't be writing web apps if we don't know what we're doing. To them I say, screw you. These tools enable us to do things that would never have been possible. Thank you from the bottom of my heart for doing whatever it is that you did. :-)
  - dnautics 8y ago
    I was initially resistant to a lot of react, for example, jsx. However as a backend dev (functional) I was very pleased when I could dive into react code and reliably implement features as needed.
- ilovecaching 8y ago
  Thanks for all your great work sophiebits. React is perhaps the most important milestone in bringing functional concepts to the mainstream to date, and the project has been really well managed. It makes backend people like me actually enjoy writing JavaScript! Excited to see what you do next.
hesarenu 8y ago
That is just state management. The basic premise of reactjs has stayed the same.
hombre_fatal 8y ago
Without trying new things, you get stuck with, say, UIKit + CoreData which make me miss React every second I'm building an iOS app. All the KVO stuff that make it hard to actually reason about state changes. Of course React, like any library/framework, is going to have its own idiosyncrasies. That isn't the question. The question is if it's still better than alternatives, and people clearly seem to think so. My first React app I ever made years ago still works on the latest React, seems pretty stable as far as the web client ecosystem goes. Client development isn't trivial on any platform, btw. But I think we have it pretty damn good on the web, relatively.
- pjmlp 8y ago
  We will only have it damn good on the web when it is as easy as doing RAD apps in Delphi, or using Blend to design UI layouts. I see a good possibility with WebComponents, which React seems to be the only framework not going for them.
  - crooked-v 8y ago
    To me, Web Components are bound by the fundamental anti-pattern of having to globally register unique tag names. Didn't people already learn the problems with doing this from Angular 1?
    - pjmlp 8y ago
      Because the best practice is to prefix them anyway, following up on XML namespaces?
      - crooked-v 8y ago
        The contrast I mean to emphasize is React, where the tag you use is either an actual var declaration or a string placeholder for a browser (or other environment) built-in.
emilsedgh 8y ago
React resolved very big problems. These pattern changes are tiny improvements. Basically they are improving the syntax a bit.
sutantog 8y ago
no other framework lets you do so much by learning so little. React has the best learning curve to value ratio
johnfn 8y ago
This seems pretty disingenuous to me. React didn’t create the problem of class methods not binding this correctly. That’s purely a javascript problem, which react now provides a way to solve.
- hombre_fatal 8y ago
  React's original createClass() even tried to solve that problem with autobound methods but they decided it wasn't worth it: https://reactjs.org/blog/2015/01/27/react-v0.13.0-beta-1.html#autobinding https://reactjs.org/blog/2015/01/27/react-v0.13.0-beta-1.htm...
mpweiher 8y ago
This is a question that’s been puzzling me for quite a while. For one, react is a fairly competently done, roughly MVC UI framework. The components are views, render() is drawRect. Being in the browser, render() doesn’t draw into a bitmap, but rather returns structured objects. That also means painting optimization is diff-based rather than damage-rect based. Which brings us to what appears to be the biggest difference: traditional MVC GUI toolkits such as Cocoa clearly separate creating a UI from updating the UI with data. For updating the UI from the model (and the model from the UI), you follow MVC, which specifies how the Views map the model to the display and vice versa. The actual views stay the same during that time, the data changes. React combines these two steps into one, conceptually recreating the entire UI at each step like a game. While this solves some issues that have crept into toolkit programming due to a shift towards handling dynamic aspects via changes in the view/widget hierarchy, it is conceptually rather muddled[1]. This conceptual muddle, claiming that the UI is a “pure” function of the state when it is clearly not, seems to the major source of those problems that keep needing to be solved. To me it would seem that looking dispassionately at the problems react solves without the conceptually troublesome baggage might be useful, but that’s just my € 0.02. [1] https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...
- jasim 8y ago
  The linked post is a great comparison of functional and object-oriented approaches to building UIs. Thanks. I think the crux of the issue is here: > "So if we don't make the incorrect assumption that UIs are unstable (pure functions of model), then we don't have to expend additional and fragile effort to re-create that necessary stability." In Cocoa, and generally in desktop UIs, your assumption is true. A UI is a set of "slots" into which dynamic data is displayed. But on the web this is a lot more fluid. You can have visibility toggles across the application, and the UI can vary drastically between one state to another. I think this is the fundamental mismatch between the object-oriented approach to UI and the functional approach to UI. Also, in the "Lists" section, the functional approach would not be to create a persistent Map, which then has to be invalidated as its source data changes. Instead, the mental model in the functional approach is to always re-compute everything; memoization is an optimization that should be transparent.
deleted 8y ago
[deleted]

sophiebits 8y ago

(I worked on React.) Many people have adopted React and are happy with it, evidently because they believe the problems it creates are minor compared to the problems it fixes. It’s rather reasonable for them to be excited about a new version that keeps (or improves!) the good parts while having fewer tradeoffs.

jen729w 8y ago
React is amazing. I'm teaching myself JS — started October '17 — and I've gone through a few iterations of my little project as I learn more. - Vanilla JS: it works, but holy moly it looks bad and the amount of code I have to write to do even basic stuff really really hurts my brain. (Actually what am I talking about, it never got close to "working" before I moved on to...) - jQuery/Node: ooh, this is better. But still, doing stuff takes ages. - React: OH MY GOD WHAT IS THIS HEAVEN. People will say that "people like me" shouldn't be writing web apps if we don't know what we're doing. To them I say, screw you. These tools enable us to do things that would never have been possible. Thank you from the bottom of my heart for doing whatever it is that you did. :-)
- dnautics 8y ago
  I was initially resistant to a lot of react, for example, jsx. However as a backend dev (functional) I was very pleased when I could dive into react code and reliably implement features as needed.
ilovecaching 8y ago
Thanks for all your great work sophiebits. React is perhaps the most important milestone in bringing functional concepts to the mainstream to date, and the project has been really well managed. It makes backend people like me actually enjoy writing JavaScript! Excited to see what you do next.

hesarenu 8y ago

That is just state management. The basic premise of reactjs has stayed the same.

hombre_fatal 8y ago

Without trying new things, you get stuck with, say, UIKit + CoreData which make me miss React every second I'm building an iOS app. All the KVO stuff that make it hard to actually reason about state changes. Of course React, like any library/framework, is going to have its own idiosyncrasies. That isn't the question. The question is if it's still better than alternatives, and people clearly seem to think so. My first React app I ever made years ago still works on the latest React, seems pretty stable as far as the web client ecosystem goes. Client development isn't trivial on any platform, btw. But I think we have it pretty damn good on the web, relatively.

pjmlp 8y ago
We will only have it damn good on the web when it is as easy as doing RAD apps in Delphi, or using Blend to design UI layouts. I see a good possibility with WebComponents, which React seems to be the only framework not going for them.
- crooked-v 8y ago
  To me, Web Components are bound by the fundamental anti-pattern of having to globally register unique tag names. Didn't people already learn the problems with doing this from Angular 1?
  - pjmlp 8y ago
    Because the best practice is to prefix them anyway, following up on XML namespaces?
    - crooked-v 8y ago
      The contrast I mean to emphasize is React, where the tag you use is either an actual var declaration or a string placeholder for a browser (or other environment) built-in.

emilsedgh 8y ago

React resolved very big problems. These pattern changes are tiny improvements. Basically they are improving the syntax a bit.

sutantog 8y ago

no other framework lets you do so much by learning so little. React has the best learning curve to value ratio

johnfn 8y ago

This seems pretty disingenuous to me. React didn’t create the problem of class methods not binding this correctly. That’s purely a javascript problem, which react now provides a way to solve.

hombre_fatal 8y ago
React's original createClass() even tried to solve that problem with autobound methods but they decided it wasn't worth it: https://reactjs.org/blog/2015/01/27/react-v0.13.0-beta-1.html#autobinding https://reactjs.org/blog/2015/01/27/react-v0.13.0-beta-1.htm...

mpweiher 8y ago

This is a question that’s been puzzling me for quite a while. For one, react is a fairly competently done, roughly MVC UI framework. The components are views, render() is drawRect. Being in the browser, render() doesn’t draw into a bitmap, but rather returns structured objects. That also means painting optimization is diff-based rather than damage-rect based. Which brings us to what appears to be the biggest difference: traditional MVC GUI toolkits such as Cocoa clearly separate creating a UI from updating the UI with data. For updating the UI from the model (and the model from the UI), you follow MVC, which specifies how the Views map the model to the display and vice versa. The actual views stay the same during that time, the data changes. React combines these two steps into one, conceptually recreating the entire UI at each step like a game. While this solves some issues that have crept into toolkit programming due to a shift towards handling dynamic aspects via changes in the view/widget hierarchy, it is conceptually rather muddled[1]. This conceptual muddle, claiming that the UI is a “pure” function of the state when it is clearly not, seems to the major source of those problems that keep needing to be solved. To me it would seem that looking dispassionately at the problems react solves without the conceptually troublesome baggage might be useful, but that’s just my € 0.02. [1] https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...

jasim 8y ago
The linked post is a great comparison of functional and object-oriented approaches to building UIs. Thanks. I think the crux of the issue is here: > "So if we don't make the incorrect assumption that UIs are unstable (pure functions of model), then we don't have to expend additional and fragile effort to re-create that necessary stability." In Cocoa, and generally in desktop UIs, your assumption is true. A UI is a set of "slots" into which dynamic data is displayed. But on the web this is a lot more fluid. You can have visibility toggles across the application, and the UI can vary drastically between one state to another. I think this is the fundamental mismatch between the object-oriented approach to UI and the functional approach to UI. Also, in the "Lists" section, the functional approach would not be to create a persistent Map, which then has to be invalidated as its source data changes. Instead, the mental model in the functional approach is to always re-compute everything; memoization is an optimization that should be transparent.

deleted 8y ago

[deleted]