Live data from Hacker News

Scheduling in React

philippspiess.com

71–80 of 109 posts

Re: Scheduling in React

#71

I think this is a great point made. I wonder if it makes sense to build into the core of react to have render method execute on priority levels configured for the components themselves. I agree that this adds a good deal of complexity otherwise for quicker projects.

What complexity are you referring to? If you don’t use finer grained control then your React apps work exactly the same ways as they did before. The extra control is opt-in and you don’t have to use it.

Re: Scheduling in React

#72
post #6

Impressive, but I don't think there's much of a use case for this. Sure that last example ran at close to 60fps, according to the meter, but did it really? I mean, as a user I experienced no performance gains, because I was focused on that lower part of the UI and I think most users would as well.

I found the second example to be way less janky. I want to be able to see what I type as I type it (e.g. for spelling mistakes). Taking a second to correlate that with results I am willing to accept, but if an app is janky with basic interactions I am leaving.

I want to emphasise both of examples are intentionally janky (even though second is less so). As the article states, it literally has a for loop that doesn’t do anything to simulate an overly expensive tree (think thousand of DOM nodes).

You can see the difference between first and second approaches that way. Although both would be fast if we remove that artificial slowdown (simulating a larger app).

However I also want to note that you shouldn’t base your idea of what Concurrent Mode will feel like based on an alpha version demo. It’s work in progress and we didn’t mean to imply it’s ready to be denied at face value. https://twitter.com/dan_abramov/status/1103769293479653376

Re: Scheduling in React

#73
post #67

As users, don't you get mad when you type "mustang" in an input and it displays "msutgna" because of some badly handled onChange event? We are overriding so much of the browser's default behavior that we need to reimplement its basic features.

Yes. I wish native browser inputs would step out of 1994, but at the same time my preferred answer to this case is simply using an uncontrolled input rather than piling more layers of complexity on top of it.

Re: Scheduling in React

#75
post #62

Earlier quoted context omitted.

Sorry, I know you're heavily involved in this ecosystem, I just don't really see the need for any of this. create-react-app is mostly about webpack, isn't it? Redux works fine on its own.

FWIW, I'm a Redux maintainer, and I built this specifically in response to how I've seen people _want_ to use Redux, and the concerns they've raised about using Redux. [0] Almost everyone uses `redux-thunk` [1]. Adding that to a plain Redux store takes a few steps. Adding middleware _and_ setting up the Redux DevTools Extension adds another couple steps [2] So, RSK's `configureStore()` does that by default [3]. Accid…

That was a very defensive response.

Look it's excellent for you that many people want to use your work and think it looks awesome. I am just not one of those people, for reasons developed over years of using Redux professionally.

It seems like you think I am just missing something, and that's why I don't agree with you. You should really be more open to the idea that others might think very differently from you and the people you surround yourself with, even after fully considering your ideas.

I also knew you were a Redux contributor when I first responded. I was wondering how long I could disagree with you before you pulled rank.

Re: Scheduling in React

#76
post #23

I feel that this low-level performance stuff should exist in browser-land and not in framework-land. Kudos to React for finding a good implementation though

Yes it's highly unsatisfactory that frameworks are implementing "threads" (i.e., fibers) now, while the OS already provides native threads.

Perhaps it would not have been so bad if they just kept the interface the same ...

Re: Scheduling in React

#77
post #23

I feel that this low-level performance stuff should exist in browser-land and not in framework-land. Kudos to React for finding a good implementation though

We’ll end up with threads in JS one day.

Hopefully without a "Global Interpreter Lock".

Re: Scheduling in React

#78
post #67

As users, don't you get mad when you type "mustang" in an input and it displays "msutgna" because of some badly handled onChange event? We are overriding so much of the browser's default behavior that we need to reimplement its basic features.

I've never experienced that. Mind sharing an example?

Re: Scheduling in React

#79

Earlier quoted context omitted.

If you delay the artificial slowness that I added in the Text component after the rendering, it sure will be faster. The point is to simulate an expensive component tree with this. If we keep that in ( https://codesandbox.io/s/93yv4j129p ), my previous comment holds true: https://news.ycombinator.com/item?id=19332577 Here is by the way a version with all artificial slowness removed: https://codesandbox.io/s/9859x0wm9…

The important part btw is that in Concurrent Mode we can interrupt a render in the middle if user does an interaction, and handle that interaction first. Without blocking the thread. This is something setTimeout is incapable of helping with. Because even if you delay the work, at some point it’s still gonna block. In either case this example is very simplified and doesn’t illustrate the subtle difference as much. We’…

>in Concurrent Mode we can interrupt a render in the middle if user does an interaction

Can you interrupt an arbitrary user-written function that's called inside the rendering stack?

Re: Scheduling in React

#80
post #13

I understand the need but this adds serious complexity and wouldn't recommend that this becomes the standard for UX in React. A user is often ok with a delay and it may not worth the tech debt. That said, a very well written article.

> it may not worth the tech debt

Management is complaining that our website is less responsive than our competition's ...

Post reply on HN