Hacker News Reader

Comment by palmdeezy | Hacker News Reader

Hi, it's Jared (the OP)...

Well said. Perhaps my deeper point is that hooks and soon Concurrent Mode force devs to come to terms with the fact that they _don't_ understand React internals (hence my usage of black box) and that their mental models were wrong this whole time (although some might argue still pretty productive).

I also think Crank is SUPER interesting on so many levels. I built a few demos with it and am fairly impressed. However, practically speaking (and I'm putting my developer relations hat on), I think its generator API is just too intimidating to junior developers.

View on HN

Isn't the wider problem that people don't try to understand the internals? Some of us may read the code of modules we "require", but experience tells me this is a rarity.

For those that do, this isn't an issue, and for those that don't, this isn't an issue either. Their mental model may be flawed, but as long as the IO is the same, do they really care?

Concurrent mode isn't really a black box. Its just a shortcut to throw away work that would otherwise be invalidated.

I noticed at the end of the blog post you stated that you're very excited about the debut of the upcoming Concurrent Mode (CM) in React. I've read about the problem that Concurrent Mode is working to address; but I'm confused as to why React needs this additional feature set when I'm unaware of any other UI frameworks which have a feature set that seem to mirror that of CM. Vue or Svelte do not seem to need these additional features to achieve comparative rendering benchmark speeds to React, and I'm unaware of any holes in these frameworks that something like CM would adequately address. (?).

Is Concurrent Mode basically a way of addressing performance problems in React, or is this in some way a feature that adds something novel? Or is it just a side effect of an unwillingness to move away from functional programming?

I write React at work, but write Svelte or Vue at home, and I've always found React's abstractions to be the most hard to reason about, and from the looks of it CM will make this more challenging (??). Thanks.

I usually explicitly tell devs to not worry about React internals. Let React decide when to re-render or how to batch state updates. React's API is small, developer time is better spent understanding the API than wondering how React works under the hood.

That said it's still a mental shift. Sometimes I feel like I'm writing React and not writing JavaScript.

Reply on news.ycombinator.com