Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

react.dev

Post reply on HN
Print view View original

81–90 of 130 posts

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

#81

Post by satvikpendem »

baobabKoodaa wrote: post #67
sunaurus wrote: post #61

Earlier quoted context omitted.

I've seen this criticism several times on HN, but have never been able to relate to it. I've been using hooks since they were introduced, in several teams (at several different companies), and I've never experienced them being complicated to understand, either for myself, or for team mates - even juniors who are new to React. In my experience, it takes very little time ( I wonder if it's the case that many people on…

> I wonder if it's the case that many people on HN are just used to some completely different libraries and thus are coming in to React with a completely different mental model? And that's the cause of this sentiment being so common here. Nope. For me React was the first frontend framework I learned. The mental model of Class components was really easy to understand. I have since "learned" hooks, but they are a const…

You might be interested in learning the reason hooks were invented [0]. I also use hooks in Flutter via a separate package and its creator made a great GitHub issue talking about exactly why class components cannot replicate the hook model [1], simply due to the limitations of how classes work. The code is in Dart but it's simple enough to grasp if you know JS and class concepts in general like overrides and mixins.

[0] https://medium.com/@dan_abramov/making-sense-of-react-hooks-...

[1] https://github.com/flutter/flutter/issues/51752

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

#82

Post by satvikpendem »

For some reason, I see people in this thread whom I believe don't really understand why hooks were invented. Put simply, just like closures hold state in a function, hooks compartmentalize the component's lifecycle, they are basically `function(state, lifecycle)`. I linked to a Flutter thread elsewhere (on the topic of adding hook-like constructs to Flutter as well) that I've seen as one of the best examples of why class components simply cannot replicate the effects of hooks, due to the inherent limitations of classes [0].

The author uses an example of needing to initialize and dispose of a variable, and you must do this manually each time, for each variable. With a hook, you can abstract this behavior and say, given this lifecycle, I need this variable to be automatically initialized and disposed at the correct time. I write it once, and don't have to think about doing it manually anymore. Hooks are an abstraction over lifecycles, just as functions and loops are an abstraction over repeated procedures.

[0] https://github.com/flutter/flutter/issues/51752

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

#83

Post by satvikpendem »

CharlieDigital wrote: post #55
egeozcan wrote: post #49

Earlier quoted context omitted.

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 diffe…

Evan You (Vue author) had a great quote about this: A mutable model that you can reliably understand is better than an immutable one that leaks. The pain and suffer of hooks all roots from the mismatch between a dogmatic belief in the superiority of immutability and the harsh reality of the host language that is JavaScript. React's render cycle is fundamentally mis-aligned with JavaScript since the re-render requires…

It makes sense when you realize that React concepts were originally conceived in OCaml by Jordan Walke, who also made ReasonML as a JS(X)-like syntax over OCaml. OCaml is almost all functional, with immutable variables, so this was brought over to React.

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

#84

Post by satvikpendem »

omeid2 wrote: post #27
Couto wrote: post #25

Earlier quoted context omitted.

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…

The newish `useReducer` is basically redux but tied into react like in elm.

I'm assuming you mean `useReducer` with `useContext`, but note that they are not a replacement for Redux: https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

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

#85

Post by tubthumper8 »

colonelpopcorn wrote: post #69
_heimdall wrote: post #34

Earlier quoted context omitted.

React isn't a Vercel product though, and server components are a react feature rather than a NextJS feature. With regards to incentives, these newer react features only meet their goals if the goal is to use react the open source project as a funnel for Vercel, the for profit hosting company.

Most of the core React devs are employees at Vercel. As much as you may not like it, core parts of React are driven by Vercel 's business model.

Most? Looks like 3 out of 20 people

https://react.dev/community/team

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

#86

Post by azangru »

gardnr wrote: post #71
hyfgfh wrote: post #17

Earlier quoted context omitted.

A new solution could replace some of the tools we use today, making it obsolete and not worth maintaining in the future. Make sense, but the lack of an "oficial" solution doesn't help https://react.dev/learn/start-a-new-react-project

I have been tempted to go back to turn of the century tech: html tables for layout with inline css for styling and smarty template for separation of concerns all driven by php.

> html tables for layout with inline css for styling

Html and css have only been getting better over the past two decades; they are not the problem; no need to resort to inline styles and tables. As for going back to server-side templating with php, this is a very good option.

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

#87

Post by bilekas »

sesm wrote: post #43
mewpmewp2 wrote: post #23

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.

> Because nothing beats immediate-mode-style API in terms of code clarity.

This is not React these days at all. Maybe when it was just an actually useful library. Not a hope now.

> It became the most popular in the landscape where all kinds of other frameworks existed

It became popular because it was simple, when it was simple. Then they did what all JS developers do. Find a problem for a solution.

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

#88

Post by wk_end »

addicted wrote: post #76
sunaurus wrote: post #61

Earlier quoted context omitted.

I've seen this criticism several times on HN, but have never been able to relate to it. I've been using hooks since they were introduced, in several teams (at several different companies), and I've never experienced them being complicated to understand, either for myself, or for team mates - even juniors who are new to React. In my experience, it takes very little time ( I wonder if it's the case that many people on…

I can objectively prove that React devs themselves have at the very least changed how they understand hooks but more likely have been making it up as they’ve gone along. The best example is one of the more problematic hooks, useEffect. Here’s how useEffect is described in the old documentation: https://legacy.reactjs.org/docs/hooks-effect.html > The Effect Hook lets you perform side effects in function components Her…

I think it’s more that the React team’s way of articulating their idea of what a “side effect” is changed than that their idea of what useEffect is for changed. The examples of “side effects” in the old docs are all cases of “external synchronization”. People found the old terminology misleading because they came with their own preconceptions of what a side effect is, so they changed their pedagogical approach. The technical details haven’t really changed, just the presentation.

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

#90

Post by azangru »

azangru wrote: post #75
throwaway220033 wrote: post #18

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.

> The goal behind "hooks" was to make React simpler for beginners. What makes you think this was the goal? React team has been trying to get rid of 'this' for a long time; I believe I saw someone say that it had some undesirable consequences for the fiber architecture and for the "concurrent mode" that eventually was transformed into a set of concurrent features. Alternatively, it is possible that they wanted a bette…

Examples from the conversations of that time:

> ...we want closures to capture the values we rendered with, and to keep "seeing" those values forever. That's really important for concurrent mode where a notion of current value doesn't really exist. Hooks design models a component as being in many non-clashing states at the same time, instead of switching the "current" state (which is what classes model well). People don't really need to think about these details, but they're motivating the design a lot. [0]

> In Concurrent Mode, render may run more then one time, and since this in a class is mutable, renders that should be the same may not be. [1]

[0] - https://github.com/reactjs/rfcs/pull/68#issuecomment-4778866...

[1] - https://tkplaceholder.io/why-function-components-fit-react-b...

Post reply on HN