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

101–110 of 130 posts

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

#101

Post by slmjkdbtl »

cal85 wrote: post #93
slmjkdbtl wrote: post #29

Earlier quoted context omitted.

I feel embarrassed when some of the great back end / system programmers I work with have to go in the front end code base and write React. They can submit patches to linux source like it's nothing but understanding React is just too hard for them.

There’s an interesting assumption here that frontend engineering should always be very simple, such that engineers in other disciplines should be able to hop over and dabble with frontend engineering on the side with no difficulty. Or perhaps the assumption is that React specifically should only focus on the fluffy, junior-friendly end of frontend and leave the more advanced frontend stuff to other toolkits?

I think React (hooks) invents a convoluted solution to a problem that can be solved in a more direct way, and there's a lot of big caveats hidden behind the interface that can cause big performance problem and bug. Their invention also requires a specific way of thinking that contradicts a lot of programming intuitions. Complexity is definitely fine if it comes from the problem itself (rendering), but for React most of the complexity is introduced by itself.

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

#102

Post by sesm »

bilekas wrote: post #87
sesm wrote: post #43

Earlier quoted context omitted.

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.

Did you write React with class-based components? Do you think CWM/CWU/CWRP is better than useEffect, or constructor/setState is better than useState?

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

#103

Post by satvikpendem »

cooperadymas wrote: post #92
satvikpendem wrote: post #82

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

I am certain your comment was well intentioned, but it is quite striking how frequently the you are arguing against it, so clearly you must be an idiot defense pops up any time someone criticizes React[0]. [0] https://news.ycombinator.com/item?id=35278169

I'm not saying they're an idiot, but it takes time to learn tools. Frontend devs and React devs in particular are usually more novice than other types of coders (in my experience), likely due to so many courses pushing out MERN devs over the last 10 years or so, so it is very likely that most just went with the flow and never actually sat down to read the docs and understand their tools.

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

#104

Post by selfmodruntime »

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…

I do not get that class components are in any way simpler. Before, you had to think about explicit configuration states during the components entire lifecycle. Now, you just... don't?

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

#105

Post by notpachet »

satvikpendem wrote: post #103
cooperadymas wrote: post #92

Earlier quoted context omitted.

I am certain your comment was well intentioned, but it is quite striking how frequently the you are arguing against it, so clearly you must be an idiot defense pops up any time someone criticizes React[0]. [0] https://news.ycombinator.com/item?id=35278169

I'm not saying they're an idiot, but it takes time to learn tools. Frontend devs and React devs in particular are usually more novice than other types of coders (in my experience), likely due to so many courses pushing out MERN devs over the last 10 years or so, so it is very likely that most just went with the flow and never actually sat down to read the docs and understand their tools.

Isn't this an implicit argument in favor of simpler tools with less thorny undersides than React Hooks?

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

#106

Post by satvikpendem »

notpachet wrote: post #105
satvikpendem wrote: post #103

Earlier quoted context omitted.

I'm not saying they're an idiot, but it takes time to learn tools. Frontend devs and React devs in particular are usually more novice than other types of coders (in my experience), likely due to so many courses pushing out MERN devs over the last 10 years or so, so it is very likely that most just went with the flow and never actually sat down to read the docs and understand their tools.

Isn't this an implicit argument in favor of simpler tools with less thorny undersides than React Hooks?

Sure, but every technology has its own problems. It just depends which tradeoffs you want to make.

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

#107

Post by CharlieDigital »

zarzavat wrote: post #99
CharlieDigital wrote: post #55

Earlier quoted context omitted.

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…

I agree with the sentiment that JS is the wrong language for React, but it’s not such a big deal in practice. The key is to write your own hooks specialized for the project, then the complexity is isolated into one place where you are expecting it, instead of dispersed across your project. If you are trying to write everything using the built-in hooks then you’re going to have a bad time.

    > you’re going to have a bad time
Have a good time and use any of the other options available. Vue, Solid, Preact, Svelte, Lit, Vanilla.

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

#108

Post by codethief »

omeid2 wrote: 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/

Speaking of Elm, what is the state of that project? Development seems to have slowed down significantly.

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

#109

Post by codethief »

satvikpendem wrote: post #73
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 No, it had nothing to do with making it "simpler for beginners." It was to functionalize state changes in a way that was impossible with classes and other OOP constructs like mixins. There is actually a great issue thread on the Flutter GitHub that explains exactly why other solutions do not work correctly when compared to hooks [0]. What people don't…

> There is actually a great issue thread on the Flutter GitHub that explains exactly why other solutions do not work correctly when compared to hooks [0]

Interesting. I assume you are referring to this comment in particular -> https://github.com/flutter/flutter/issues/51752#issuecomment... ?

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

#110

Post by satvikpendem »

codethief wrote: post #109
satvikpendem wrote: post #73

Earlier quoted context omitted.

> The goal behind "hooks" was to make React simpler for beginners No, it had nothing to do with making it "simpler for beginners." It was to functionalize state changes in a way that was impossible with classes and other OOP constructs like mixins. There is actually a great issue thread on the Flutter GitHub that explains exactly why other solutions do not work correctly when compared to hooks [0]. What people don't…

> There is actually a great issue thread on the Flutter GitHub that explains exactly why other solutions do not work correctly when compared to hooks [0] Interesting. I assume you are referring to this comment in particular -> https://github.com/flutter/flutter/issues/51752#issuecomment... ?

The whole thread is worth a read, the first post in particular lays out why traditional class-based solutions don't work, while that comment by Dan Abramov is good in its own way, viewing hooks through the lens of algebraic effect handlers.
Post reply on HN