Live data from Hacker News

React Labs: What We've Been Working On – February 2024

react.dev

41–50 of 130 posts

Re: React Labs: What We've Been Working On – February 2024

#41

The goal behind "hooks" was to make React simpler for beginners. I build client-side apps since 2007, and React is getting too magical and complex for even for me. The NextJS influence is really making things worse, "use server" "use client" tags do not scale at all. The project clearly lacks mission, goal, leadership and direction. I'll use Preact in the next projects.

Can't help but agree. It's very hard, even for experienced developers, to understand what is going on with hooks. Even knowing why they are needed requires a deep understanding of what is happening. Definitely feels like complex implementation details leaking upwards and influencing the public API.

I was able to grasp hooks after an initial distaste. But once I started hearing about hydration, I just felt this…weariness. It’s why I’ve never been interested in NextJS and definitely not interested in RSC.

I’m open to having my mind changed, but I really don’t like having abstractions cross the network boundary.

Re: React Labs: What We've Been Working On – February 2024

#42
post #22

MobX and chill. No compiler necessary. If React created better extension points for pluggable reactivity we wouldn't even need observer() wrappers. This is all getting kinda bonkers.

+1 for mobX. Dead straightforward, does one thing and does it well. Only worry is that it increasingly feels like an outsider in React. I'm working on an app that uses React, web components and mobX, and upgrading to React 18's concurrent rendering breaks stuff, and I'm not sure which of my relatively niche technologies (mobX or WC or maybe the interaction of the 2?) causes it.

Preact has been looking increasingly attractive as a library that does its own thing and nothing more. Anyone knows if preact signals are basically a drop in replacement for mobX?

Re: React Labs: What We've Been Working On – February 2024

#43

I don't think React is approachable. It is just the most popular framework and has the biggest ecosystem, that is why it is used. Otherwise it is just not good in my view compares to others. Also I don't think useMemo or useCallback were a reasonable compromise ever.

It became the most popular in the landscape where all kinds of other frameworks existed. Because nothing beats immediate-mode-style API in terms of code clarity.

Re: React Labs: What We've Been Working On – February 2024

#45
All these features sound interesting in isolation, but I can't help thinking that react is stuck on the same treadmill its been on for years.

They keep solving important problems like memorization bugs, but these problems are all self inflicted. The API keeps getting more complex, and with a goal of backwards compatibility everything is additive.

Actions as a generic concept look interesting, but the idea of having every library expose both onSubmit and submitAction is just going to make things more confusing. I guess you use events for old code, and actions when you want the option to send the event to the server depending on the "use server" directive or pragma? And when the next thing comes along, I guess every library exposes 3 different ways to handle a form submit event?

Re: React Labs: What We've Been Working On – February 2024

#47
post #14

> One way to think about this is that React currently re-renders when object identity changes. With Forget, React re-renders when the semantic value changes — but without incurring the runtime cost of deep comparisons. There's got to be another word for 'magic' to describe this kind of behavior because this is on a whole other level. People complain about observers, or transpiling being too magical, but at least thos…

> There's got to be another word for 'magic' to describe this kind of behavior because this is on a whole other level

As far as I understand that quote, it's just about "reference equality" vs "value equality", something most programmers deal with often but maybe frontend programmers aren't used to it? Not sure why the quote doesn't include that naming for it, maybe it would help people connect it to concepts they already understand.

FWIW, I also think React has gotten to complicated and bloated, but I've been thinking that since hooks were introduced if not before, and mainly use React indirectly via Reagent, not directly.

Re: React Labs: What We've Been Working On – February 2024

#48
post #31

It’s getting harder to keep track of all the shiny new features. UI devs already deal with TS->JS compiler, tailwind compiler just to name two. Can’t imagine adding another compiler to the mix. Our already complex and fragile build pipelines just keep getting worse. I understand the problems in scaling UI development. Just don’t think the solution is to build another layer of complexity atop the shaking foundation.

> Just don’t think the solution is to build another layer of complexity atop the shaking foundation

Why would we try to solve UI development issues any different than other parts of the stack? Building layers on top of shaky foundations is a true and tested approach in computer science and seemingly the only way to move forward somewhat.

Re: React Labs: What We've Been Working On – February 2024

#49
post #47
post #14

> One way to think about this is that React currently re-renders when object identity changes. With Forget, React re-renders when the semantic value changes — but without incurring the runtime cost of deep comparisons. There's got to be another word for 'magic' to describe this kind of behavior because this is on a whole other level. People complain about observers, or transpiling being too magical, but at least thos…

> There's got to be another word for 'magic' to describe this kind of behavior because this is on a whole other level As far as I understand that quote, it's just about "reference equality" vs "value equality", something most programmers deal with often but maybe frontend programmers aren't used to it? Not sure why the quote doesn't include that naming for it, maybe it would help people connect it to concepts they al…

The problem is a library changing language semantics mostly as a consequence of their own earlier design decisions.

So I can totally explain someone how there is no pass-by-reference in Go, and I can also explain why equal sets of different identity are not really equal in JS (following the records proposal, with my fingers crossed, and happy with it because it's a language change), but when libraries introduce different semantics via their own compilers, that's a line I don't like getting crossed.

That's actually why I never really got into Svelte.

Re: React Labs: What We've Been Working On – February 2024

#50
post #25
post #10

I have been using React at least since 2017 so not a hater; but how many version are we away from elm at this point? https://elm-lang.org/

React was closer to elm during the times of stateless functions and redux. Since then it's getting further apart from elm. Redux was kinda of a poor man's elm but it got the right principles. However the JS community hates boilerplate code so, new, more complicated abstractions appeared. Also, it was too easy, with redux, to shoot yourself in the foot. Since then, with hooks, things are just getting harder and more c…

Redux had some strange "features" that increased boilerplate without bringing anything worthwhile: mapDispatchToProps (I see it is gone since hooks, I could never find any sensible reason to use it the way authors wanted), global reducer, serializable state, serializable actions.

I once counted how many things you had to do to add new button with new action (it was when class components were still acceptable) - you had to change 4 files in 7 different places. This was completely insane for me. After little fighting with Redux (so I could pass nonserializable actions) I went down to 2 changes in 2 files (to dispatch action and to reduce it).

Redux is better now but I do not think its principles were that good.

Post reply on HN