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

51–60 of 130 posts

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

#51

Post by preommr »

diggan wrote: post #47
preommr wrote: 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…

I think they're doing a little bit more. I should've linked the article I quoted since it's not in the submission post but a link the submission post, from march of last year.[0]

They go on to explain :

> Under the hood we use a custom code representation and transformation pipeline in order to do low-level semantic analysis. However, the primary public interface to the compiler will be via Babel and other build system plugins. For ease of testing we currently have a Babel plugin which is a very thin wrapper that calls the compiler to generate a new version of each function and swap it in.

> As we refactored the compiler over the last few months, we wanted to focus on refining the core compilation model to ensure we could handle complexities such as conditionals, loops, reassignment, and mutation. However, JavaScript has a lot of ways to express each of those features: if/else, ternaries, for, for-in, for-of, etc.

[0]https://react.dev/blog/2023/03/22/react-labs-what-we-have-be...

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

#52

Post by diggan »

preommr wrote: post #51
diggan wrote: post #47

Earlier quoted context omitted.

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

I think they're doing a little bit more. I should've linked the article I quoted since it's not in the submission post but a link the submission post, from march of last year.[0] They go on to explain : > Under the hood we use a custom code representation and transformation pipeline in order to do low-level semantic analysis. However, the primary public interface to the compiler will be via Babel and other build syst…

Oh wow, yeah, that definitely sounds like more magic that I thought at first. Thanks for expanding the context a bit :)

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

#53

Post by Timon3 »

iamflimflam1 wrote: post #24
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.

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.

> Definitely feels like complex implementation details leaking upwards and influencing the public API.

This describes it very well. I recently started writing React code after using Vue 3's composition API for a long time, and it's hard to explain just how much more low-level and manual the primitives feel.

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

#54

Post by throwaway257ash »

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.

I'm building frontend apps since 2012. I did not like hooks but ok fine. But NextJS seamed to became the default way of building React apps. I could never grasp how people in twitter and everywhere seemed to be fine with all this complexity it brought. All of this for reducing some milliseconds in load times? How can this be the default? With create-react-app you could just compile your app and host it at S3 with CDN for pennies. With NextJS you can do static site but you have to be aware of several gotchas. It seems like made up problem and solution to make return for the VC money, what am I missing?

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

#55

Post by CharlieDigital »

egeozcan wrote: post #49
diggan wrote: post #47

Earlier quoted context omitted.

> 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 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 that you correctly manage state and references in the path of the render cycle by moving it out of the way with a hook.

It all feels quite unnatural as someone who has been writing JavaScript since the last 90's.

https://twitter.com/youyuxi/status/1629636673519894528

https://twitter.com/youyuxi/status/1629636967473496064

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

#56

Post by martpie »

Lots of valid points about the increase in complexity for React over the years, and that one should pick another more modern tech stack (Svelte, Solid, html, whatever), and I used to be thinking like that

But since maybe 1-2 years, I am back and betting on React for most of my serious projects (for the ecosystem, the ease of hiring, etc), but the most important point is the following:

React backwards compatibility is really good, and will stay so for a good reason: a LOT of Meta’s UI code is using old features (classes syntax etc), and Meta cannot afford to break those. If there are breaking changes, they must be “codemodable” (so, usable by everyone).

Meaning in terms of stability, I know my codebase today will still work fine in years ( or upgrade-able with minimal efforts). Of course there will be new shiny features, but I or my team will not have to rewrite old code all the time following tedious migration guides.

disclaimer: I am kind of biased as I work at Meta, but far from React.

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

#59

Post by lairv »

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.

I agree but a major selling point of React is its ecosystem, and libraries are not compatible with Preact by default

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

#60

Post by zarzavat »

larodi wrote: post #26
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.

React like angular seems to me very much a solution from a bygone time. The time when internet was slow and expensive. I find very little reason for anyone, except services in the insta scale, to actually use this abomination, since CSS and html deliver the same user experience with plain SSR.

I get that some people only work on web pages, but can we at least have some acknowledgement that web apps exist?

Some people (me) use React to build interactive web apps. That’s what it was designed for, and it works rather well. SSR is completely useless for me.

Post reply on HN