[denverkarma]

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]

(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]

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]

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]

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.

[hombre_fatal]

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]

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]

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]

Because the best practice is to prefix them anyway, following up on XML namespaces?

[crooked-v]

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.

[johnfn]

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]

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.htm...

[emilsedgh]

React resolved very big problems.

These pattern changes are tiny improvements. Basically they are improving the syntax a bit.

[sutantog]

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

[mpweiher]

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-functio...

[jasim]

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.

[mpweiher]

> great comparison of FP/OO approaches to UI

Thanks!

I think your analysis is very insightful, but there are some additional wrinkles. I don't really think it's just OO vs. FP or Desktop vs. Web, though those aspects definitely play a role.

First, if it's an actual User Interface, something that the user interacts with, stability is not something imposed by platform convention or frameworks, but an inherent requirement: if I edit text, my text field (or editor) better be stable as I type, or it will be impossible (and infuriating) to actually interact with. If I interact with a list, that list better be stable. etc.

If it's just (mostly) visualisations that I consume mostly passively, that's a different matter (and then there are games, where you interact with a full-screen visualization).

That's not to deny your observation that interfaces have become more fluid, certainly on mobile and web, and that there isn't a certain kind of desktop application with very static/forms based interfaces (business CRUD...). You can be more static on desktop because you have the screen real estate, and disabled but visible controls are generally considered to be better than things that hide/show/slide.

So there's a bit more going on, and I think a crucial difference is how the more dynamic parts of interfaces are created. After all, it's not as if "classic" user interfaces are incapable of doing dynamic visulations and interfaces: you create a view, and within your view your drawRect: (Cocoa) method draws whatever you want however dynamically you want it. As an extreme example, 3D games tend to have an OpenGLView (now a MetalView) and inside that you have all the action.

After all, "object orientation" has both: data-structures and methods that act on them, and OO user interfaces also have both, meaning you can get as "functional" as you want. You can compose objects, draw procedurally/functionally and mix and match both to your heart's content.

For some reason, or maybe set of reasons, that doesn't seem to happen much any longer. Instead "object oriented" appears to be interpreted more in the way of "object oriented graphics", where you have a set of shapes (or widgets) that you can assemble, but without the part where objects can have arbitrary behaviour.

What this unwillingness or inability to embrace the full capabilities of OO means is that when you have dynamically varying content, you now have to dynamically change the composition of your objects/widgets. Which, admittedly, those frameworks were not created for, I am guessing at least partly because they have a different mechanism for achieving those effects.

> [Lists, functional approach, re-compute ]

If you look at NSTableView and related, you will see that they also provide a fully lazy interface to the data source[1], which can be infinite. However, the caveat from above applies: those lists better be at least somewhat stable if you want to be able to interact with them.

[1] https://developer.apple.com/documentation/appkit/nstableview...

[jasim]

I really think we should talk about this over a proper medium like email or Zoom or something :)

The point about stability as an inherent need for good UIs is true. I'll keep it in mind when thinking about this problem.

Here's two examples I can quickly think about where web interfaces are more fluid than desktop ones: 1) new UIs on hover. 2) accordions. In https://unsplash.com/, when you hover over any image, three new buttons appear; all of them are interactive elements. And accordions are anything that expands on click to reveal more content - expanding a Twitter thread in the web UI is one example.

These kind of interfaces were very rare in the desktop world. Winamp was one of the rare UIs in popular memory that worked like that. I think they were rare because the tooling - static widget-based UIs made with form builders like Delphi and VB6 - made them very difficult.

But even if we fully code the UI using objects; like say in Qt, or even in Cocoa, I think the development experience and the robustness of the code is better expressed in a functional paradigm.

I think both of us are ultimately using the affordance of writing UIs to judge OO and FP as computational paradigms. I think UI is one of the most concrete but underlooked ways to discuss this topic and measure relative trade-offs.

I've been doing OO programming for about a decade, but recently something clicked about "computation" which I've tried explaining in the first section here: https://protoship.io/blog/how-functional-is-ruby/. It is something around "OO vs FP = Stateful programming vs Explicit/pure programming = Turing Machine vs Lambda Calculus"

[jasim]

Just to add, I wish I was able to articulate clearly why I prefer one over the other. One way might be to contrast both OO and FP approaches with a reference UI and have discussions based on concrete code. But that's a lot of work. For now having worked with both approaches, I have a visceral preferences to express UIs as a function of state.

I'm interested in this area because I've been trying to figure out a way to express UIs visually (like thru erstwhile Delphi or VB6 forms, or today's vector drawing tools like Sketch), but unlike all existing renditions, they have to be composable, reusable, and Turing complete. This is a little more tractable than it might seem if we use Lambda Calculus rather than Turing Machines to think of the problem, and so expect the interface to be pure and side-effect free.

[hesarenu]

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