Hacker News Reader

Comment by jitl | Hacker News Reader

All of this tricky reasoning about what executed when - and what is closed over vs not - is challenging for most developers. The class version is the most straight forward by a wide margin compared to either React function components or Solid functions. I am happy writing hooks and figuring out the right way to express my effect conditions, but I read a lot of code that gets it wrong, and when I talk to devs they often don’t have as strong a mental model for lexical scope, lifetimes, and closures. Ultimately I think either function API is too subtle for the median developer I’ve worked with.

View on HN

The class version is the most straight forward by a wide margin compared to either React function components or Solid functions.

Dan Abramov wrote a great explanation a few years ago about an important difference between classes and functions for components, and a particular feature of classes that makes it harder to work with them at scale - prop capturing. https://overreacted.io/how-are-function-components-different... It's worth reading if you think classes are more straightforward.

Dan Abramov destroyed modern React when he turned his back on Redux.

Redux has very little to do with React. It's not bound to React, you can use it with any framework, or without a framework. You can't 'destroy React' by stopping dev on a library that's not a part of it.

Plus redux is still maintained. You can still use it if you want to. In my opinion there are better options that plain Redux available now (some based on Redux eg RTK or Redux-Query, and some not eg Jotai, tRPC, react-query). RTK is even recommended by the Redux team.

The fact Dan chose to work on other things is great. He's a talented dev and it's good that other projects benefit from his knowledge.

Hi, I'm the current primary Redux maintainer, and have been since 2016, when Dan handed the maintainer keys to myself and Tim Dorr.

I'm actually genuinely _not_ sure what you mean here.

For clarity, the timeline was:

- Summer 2015: Dan and Andrew created Redux

- November 2015: Dan got hired at FB to work on React

- Jan-Mar 2016: I got involved writing some Redux docs, and Dan gave me commit rights

- Summer 2016: Dan, who was now busy working on React, gave me and Tim full ownership of the project.

He's had some advisory thoughts and suggestions since then (most notably a couple tweaks to our proposed React-Redux hooks API in early 2019), but has otherwise _not_ been involved with Redux's development since 2016.

Honestly, this has been a _good_ thing. Based on my conversations with Dan, he most likely would have mostly left Redux's design and API as it was in 2016-ish: very minimal, and requiring _lots_ of handwritten boilerplate code to do anything useful.

Instead, I came up with the idea for our Redux Toolkit package that wraps the Redux core and provides a better API for writing standard Redux logic, worked with others to build that, wrote the documentation, shipped it, wrote new tutorials using RTK as the default, designed and shipped React-Redux hooks, and did the work to encourage folks to use the newer Redux APIs. For that matter, React-Redux version 5, which had some major perf improvements, only happened because a user offered to PR the rewrite they'd done for themselves, and I worked to oversee that effort and make sure it covered all the edge cases.

I honestly don't think Dan would have done any of that, both because he would have been splitting his efforts between working on React as his day job and Redux on the side, and also because I don't think he would have felt the need to push Redux forward and improve its usage patterns.

So, the actual history _was_ for the best. Dan got to focus on React, and I was able to pick up Redux and modernize it.

Some further reading for background and history:

- https://blog.isquaredsoftware.com/2019/10/redux-toolkit-1.0/

- https://blog.isquaredsoftware.com/2022/06/presentations-mode...

- https://blog.isquaredsoftware.com/2018/11/react-redux-histor...

- https://redux.js.org/introduction/why-rtk-is-redux-today

Yeah I absolutely love hooks, but it definitely has a learning curve. But damn, you can do nearly anything with it. One of my favorite projects involved using hooks to manage p2p connections using WebRTC, which would have been a nightmare to write without hooks. Haven't looked into signals yet, it's interesting that it almost looks identical. I wonder how it decides when to rerender.

So you're building business logic into your view components? This used to be simple in the old days when we used MVC.

No it wasn't, MVC was a mess because your views would trigger your controllers, which would propagate changes back down to your views in entirely unpredictable and inconsistent ways.

With hooks you're still free to manage business logic elsewhere, it just means that you can trivially reuse them across your application without worrying about order-dependence. So I was able to write a hook that returned connection state, and then drove my views off of that reactively.

I think you're thinking of MVVM, not MVC.

Which honestly was most SaaS products. My first internship was MVVM and killed my motivation to ever do web development.

9 years later my new work involves some react (barely 15% of the job tbh) and I really don't hate it as much.

It's MVC. Having your views driven off models is nice in theory, but a disaster in practice as the number of models proliferates. You lose control over how and when your views render, which results in all sorts of subtle and strange bugs that are difficult to debug. Each view may have its own logic for what to do when the model changes in specific ways, and what controller events to fire in response. Without unidirectional data flow, trying to even reproduce a bug becomes a nightmare.

MVC is unidirectional.

Nope, not between views. View triggers controller, updates model, triggers some random set of views to update, which triggers controllers, which triggers other models, etc. There is no hierarchy there, nor any batching to avoid rendering inconsistent intermediate state. You have no control of how an update affects your UI.

With React, data flows down from the top of the component hierarchy, always. And it doesn't render until all state changes have been made, so you only render after your data has reached consistency.

Incorrect. In fact, you can use React as the 'V' in MVC. That's how it was orignally designed. See here: https://github.com/facebook/react/tree/015833e5942ce55cf31ae...

I am done with this thread.

One of my complaints about reading computer science and/or programming books in the early 2000(or late 1990s?) was the contradictory definitions of MVC in books I read at the time. I think one book even indicated that MVVM(I think) was often referred to as MVC as an explanation for why this happened. So it understandable people still have conflicting definitions.

Here is a random example[1] I pulled up of someone one thinking MVC is not unidirectional but MVVM is. I am not commenting on the correctness of this impression.

> MVVM is better than MVC/MVP because of its unidirectional data and dependency flow. Dependency is one way,...

[1] https://dev.to/vtsen/mvc-vs-mvp-vs-mvvm-design-patterns-443n....

That's not what we're talking about at all, and you've lost the plot. The reason why React has won out for over a decade is because of the abject failure of MVC to materialize its benefits. It just doesn't scale.

What about it doesn't scale? Most UI frameworks, including ASP.NET Core, JSP and JSF (Java based frameworks), Ruby on Rails, and Django (Python) are all based on MVC. If MVC doesn't scale the folks who maintain those frameworks would have noticed by now.

The issue is that React was never (as far as I'm aware, please correct me if I'm wrong) encorporated into a full MVC (or similar) framework; its original intent was to be just the V, taking state (the model) and rendering it.

But what happened instead is that people wrote the controller parts into React components as well. In some codebases there's a very clean separation - 'logic' components that handle and manipulate state, and simpler 'view' components that just take props and render something.

But I haven't yet seen a framework that uses React as just a view layer.

I think it's more than the median developer, and I think part of it may be due to React being a victim of its own success in some ways. The scope of requirements for many kinds of common hooks has expanded dramatically. Yesterday I found a problem in a hook that is part of a library downloaded 1M+ times a week.

IMO it's more like anyone who doesn't spend over 50% of their time thinking about React re-renders whenever they're in a React component. The level of effort to properly use hooks is insane, so them being touted as a "less boilerplate!" way of writing "more functional" (literally the opposite in practice) code is egregious.

I meant for this to be included in the scope of my comment but I was short on time. You stated it better, and you’re completely right. The problem I was alluding to was related to a hook deciding when to rerender based on dependency lists. It was setup such that some people may expect it to rerender in a certain case and others may not, and it wasn’t an uncommon or excessively complicated use-case.

React can’t win here because they have a hard stance on when to value performance (avoiding re-renders) vs. convenience (ease of abstraction usage).

because they don't have a hard stance*

important typo there.

Yep, here is the React Router team getting it wrong(among other things): https://github.com/remix-run/react-router/issues/7634

> All of this tricky reasoning about what executed when

I may be too battle hardened, but here’s a simple rule for React: As soon as you have to reason about execution ordering, you have taken a wrong step and something is wrong.

Your code shouldn’t depend on effect ordering. Trying to do that is like trying to write code that depends on the precise ordering of thread execution in a multi-threaded program. You’re gonna have a bad time.

There might be a subtle rationalization of lack of competence indeed. Which is complicated because the ego can't accept that. People is used (and to be fair it really needs) to market itself plenty competent even when is not (impostor's syndrome conversations come out of this). But this goes way beyond React hooks. A lot of hate of OOP is due to self-incompetency on doing proper libraries doing the right powerful abstractions from the start.

For an erudite writer it would be painful to hear non-erudite writers blame the pen and paper for the underperforming outcome that they expected to see on their writing. And the cost of correcting that issue in them when modesty is so scarce would make the cost so high an even dangerous, that should be no surprise that only their silence gets in return. Mediocrity posing as great work rejoices.

Software really has inadequate training. People get very diverse training experiences and that can be a source of friction between developers at different qualities and competencies.

It also moves so quickly that things don't settle and people have time to get intimate with frameworks and paradigms - I'm talking like 5 year timelines with libraries doing only maintenance updates. Front-end was bad for this because of the browser wars and JS's foundations gave it a really rocky start. The allure of starting over with a new library to get away from the current "bad" way of doing things is often repeated: SPA frameworks over vanilla/jQuery sites, hooks, and now maybe signals?

There are also jobs asking you to be spread very thin among things, while keeping deadlines, so you end up googling around to get it to work, even if it violates some principles of the frameworks you're using. That doesn't really lead to expertise.

Yeah: I remember drawing boxes and arrows in CS61A at UC Berkeley when learning about closures, but not everyone I work with took that class, remembers that stuff, or was taught it in the first place. Very few people can on-the-job Google to learn a mental model that takes undergrads a few weeks of diligent practice.

Reply on news.ycombinator.com