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

RFC: Intent to Ship React 18

github.com

Post reply on HN
Print view View original

21–30 of 75 posts

Re: RFC: Intent to Ship React 18

#21

Post by danielvaughn »

brundolf wrote: post #11
judofyr wrote: post #9

Earlier quoted context omitted.

I’ve worked on React applications where a single key press would cause lags over 300ms. The React profiler wasn’t able to show any latency in my render functions and using the browser profiler I saw that all time was spent somewhere inside React’s internal. There’s some real overhead of React’s virtual DOM.

That's bizarre; I've spent a lot of time spot-optimizing React apps and never had something like that happen The VDOM definitely carried overhead in my case, but it was easy to profile and optimize (with the React tools). In many cases, reflowing the sheer size of the DOM we were generating was a bigger bottleneck than the time it took React to render it in the first place I'm really curious what was going on in your…

I've seen it a lot, personally. I've even seen instances where the input would delay by over a second. Really wild stuff.

Can a better design help to mitigate those issues? Sure. But I don't like having to wonder whether it was my own design, or if it's something internal to the library.

Re: RFC: Intent to Ship React 18

#22

Post by linkgoron »

revskill wrote: post #12

React still rocks, as it keeps "magic" to the minimal (Hook introduces a little magic for a tradeoff). Simplicity is key here.

Hooks are not simple at all, are very error prone, and definitely do not put the user in the "pit of success". JSX is terrific, but React has only gone backwards since classes IMO.

Re: RFC: Intent to Ship React 18

#23

Post by tiborsaas »

gunshowmo wrote: post #16

The fact that it's been well over 3 years since the introduction of hooks in React and people still don't understand how to use them makes me very worried for frontend development. Really looking forward to server components.

What give you the impression that people don't get hooks? In our company I see zero questions about how hooks work on slack. 90% of the time useEffect is enough.

Re: RFC: Intent to Ship React 18

#24

Post by jaquers »

0des wrote: post #17
gunshowmo wrote: post #16

The fact that it's been well over 3 years since the introduction of hooks in React and people still don't understand how to use them makes me very worried for frontend development. Really looking forward to server components.

The JS ecosystem skews younger, not in age, but in years programming. Most people who maybe want to dabble, or fix a script or something, start with JS or Py, and as most of us do, they enjoy programming and venture out to pick up another language along side it. As is the custom, eventually if they chafe against the limitations of JS enough, they move on to something that improves on those, and their newer contributi…

I am "the react guy" -- but before that I built knockout applications with requirejs & angular applications with coffeescript and gulp, and before that with a 2000 line long script.js & jquery ;)

I don't really disagree with anything you said, except to point out that a lot of the current crop of web devs have never experienced what it is to build an app without any abstraction such as React, and quite understandably have no idea what problems it is doing for them.

I do know that since hopping onto react with all of that ~baggage~ context, I have never wanted to program UIs with a different model. It is true that hooks introduce a layer of abstraction that is sometimes difficult to reason about, but IMO they boil down the problems we faced with class components/lifecycle/server rendering gotchas, and put them front and center - forcing you to confront and fix them rather than settling for a solution that works 99% of the time.

Re: RFC: Intent to Ship React 18

#25

Post by 0des »

jaquers wrote: post #24
0des wrote: post #17

Earlier quoted context omitted.

The JS ecosystem skews younger, not in age, but in years programming. Most people who maybe want to dabble, or fix a script or something, start with JS or Py, and as most of us do, they enjoy programming and venture out to pick up another language along side it. As is the custom, eventually if they chafe against the limitations of JS enough, they move on to something that improves on those, and their newer contributi…

I am "the react guy" -- but before that I built knockout applications with requirejs & angular applications with coffeescript and gulp, and before that with a 2000 line long script.js & jquery ;) I don't really disagree with anything you said, except to point out that a lot of the current crop of web devs have never experienced what it is to build an app without any abstraction such as React, and quite understandably…

> the current crop of web devs have never experienced what it is to build an app without any abstraction such as React, and quite understandably have no idea what problems it is doing for them.

This is true. A lot of those struggles that the earlier people established, the patterns and best uses, those are lessons learned the hard way, and the impact on generation 2 is often much less because that wasn't a problem that needed to be overcome.

Re: RFC: Intent to Ship React 18

#26

Post by chrisweekly »

gunshowmo wrote: post #16

The fact that it's been well over 3 years since the introduction of hooks in React and people still don't understand how to use them makes me very worried for frontend development. Really looking forward to server components.

Server components aren't going to fix the problem you're worried about. IMHO, Remix.run is the way forward for React towards a simpler, saner future.

Re: RFC: Intent to Ship React 18

#27

Post by dmitriid »

tiborsaas wrote: post #23
gunshowmo wrote: post #16

The fact that it's been well over 3 years since the introduction of hooks in React and people still don't understand how to use them makes me very worried for frontend development. Really looking forward to server components.

What give you the impression that people don't get hooks? In our company I see zero questions about how hooks work on slack. 90% of the time useEffect is enough.

Do they understand how useEffect actually works? Or do they slap on dependency lists on it because eslint tells them to?

People understand how to use hooks, but I don't think many people understand them.

Re: RFC: Intent to Ship React 18

#28

Post by dmitriid »

nightski wrote: post #13
dham wrote: post #6

Earlier quoted context omitted.

If you think Svelte is magic, wait until you see how hooks work.

Svelte changes the semantics of your code. It's great to show off to-do apps and simple examples. But I'd be very wary of buying into a framework that relied on compiler modifications to the semantics of code to make it work. I'm also not a fan of pub-sub style change notifications. It's hard to reason about what a change in state is going to cause since you don't know what's subscribed. With hooks at least I am able…

> Svelte changes the semantics of your code.

So do hooks. Suddenly regular function calls can't be put in if statements or require "dependency lists" to make them work properly.

Re: RFC: Intent to Ship React 18

#29

Post by dmitriid »

jitl wrote: post #18
dham wrote: post #6

Earlier quoted context omitted.

If you think Svelte is magic, wait until you see how hooks work.

You can implement a hooks like interface in an afternoon. I don’t think I could do the same for Svelte’s compiler-oriented approach. Using a compiler means that Svelte is essentially a dialect of EcmaScript, which appears to be mutually intelligible but isn’t always. React used a compiler for JSX which also introduced a dialect, but JSX is optional and very straightforward sugar for a simple function call. The Svelte…

> Using a compiler means that Svelte is essentially a dialect of EcmaScript

So are hooks. The fact that you can't put regular function calls (which hooks look like) in an if statement, or have to provide custom "dependency lists" to some of them, or that data returned from them suddenly re-renders (aka calls again) the function they are in tells you that this is no longer regular Javascript.

Re: RFC: Intent to Ship React 18

#30

Post by Spivak »

dmitriid wrote: post #28
nightski wrote: post #13

Earlier quoted context omitted.

Svelte changes the semantics of your code. It's great to show off to-do apps and simple examples. But I'd be very wary of buying into a framework that relied on compiler modifications to the semantics of code to make it work. I'm also not a fan of pub-sub style change notifications. It's hard to reason about what a change in state is going to cause since you don't know what's subscribed. With hooks at least I am able…

> Svelte changes the semantics of your code. So do hooks. Suddenly regular function calls can't be put in if statements or require "dependency lists" to make them work properly.

Ehh it really doesn't change the semantics of your code, hooks are just iterables and you access them by calling next(). In an alternative world they would be a mapping that you give unique names like useState("mystate", ...) and then order and if statements would be irrelevant.

Also you're just just passing a callback function to React and then giving it some pointers to data used as part of the conditional on when it should run.

Like it's janky and reaches through layers but it's not up and rewriting your code.

Post reply on HN