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

11–20 of 75 posts

Re: RFC: Intent to Ship React 18

#11

Post by brundolf »

judofyr wrote: post #9
picardo wrote: post #7

Earlier quoted context omitted.

What Rich Harris said sounds very nice and interesting, but I'd take issue with it being "not the best solution for a scalable UI." As long as the slowdown caused by the Virtual DOM remains below limits of human perception, it doesn't really matter whether something can do without Virtual DOM or not.

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 app

Re: RFC: Intent to Ship React 18

#13

Post by nightski »

dham wrote: post #6
tehbeard wrote: post #5

Earlier quoted context omitted.

I just don't know, svelte feels way too similar to the "magic" of knockout and angular 1.0 when looking at the output... Something I got burnt by with weird edge cases of update loops or desync. Svelte might have that all reasoned out though, in which case the harder separation of logic and view is the only stickler for me, and transpiling JSX into svelte would be interesting to see.

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 to have a mental model around what happens when I call a change function since it flows top down (instead of bottom up).

Re: RFC: Intent to Ship React 18

#14

Post by picardo »

judofyr wrote: post #9
picardo wrote: post #7

Earlier quoted context omitted.

What Rich Harris said sounds very nice and interesting, but I'd take issue with it being "not the best solution for a scalable UI." As long as the slowdown caused by the Virtual DOM remains below limits of human perception, it doesn't really matter whether something can do without Virtual DOM or not.

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.

I've worked on dozens of large React codebases, and never once came across a performance problem that was caused by VDOM overhead. Performance lag was always caused by bad application design. In most cases, the performance lag was due to over-rendering caused by a badly designed component architecture and state management system.

Re: RFC: Intent to Ship React 18

#15

Post by smt88 »

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. I have yet to find a dev who doesn't make subtle mistakes with them on a regular basis.

I think the concept of hooks is fine, but JS/TS is an insane language and requires an enormous amount of discipline to write.

Re: RFC: Intent to Ship React 18

#16

Post by gunshowmo »

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.

Re: RFC: Intent to Ship React 18

#17

Post by 0des »

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 contributions go there, whether it be typescript, rust, zig, go, and so on.

Looking back at the JS side where the types don't bite, there's a library for everything, and the logos are really good, what we end up with are a lot of first year, or first three year contributions to the ecosystem, so a lot of patterns and algorithms are wisdom lost and aren't present, a lot of libraries are good but not perfect, and there is really no incentive to really dive in and become an expert on a given framework like react, because any day the community might decide, "It's VUE time now" or some such other technology, and suddenly you're the guy using Gulp and Angular on a busted 2021 macbook at the hackathon and people are addressing you as "sir"

There is no incentive to be "the react guy" when it comes to JS ecosystem, that 15 mins is quick.

Re: RFC: Intent to Ship React 18

#18

Post by jitl »

dham wrote: post #6
tehbeard wrote: post #5

Earlier quoted context omitted.

I just don't know, svelte feels way too similar to the "magic" of knockout and angular 1.0 when looking at the output... Something I got burnt by with weird edge cases of update loops or desync. Svelte might have that all reasoned out though, in which case the harder separation of logic and view is the only stickler for me, and transpiling JSX into svelte would be interesting to see.

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 dialect is not so simple.

Re: RFC: Intent to Ship React 18

#19

Post by MuffinFlavored »

xiphias2 wrote: post #2

Rich Harriss, the author of Svelte talked about all the features that come to React to speed up virtual dom comparisions, but to me he's framework proved it that virtual dom is not necessary, and not the best solution for a scalable UI. At the same time there's a huge amount of React code at this point. It would be an interesting experiment to try to compile React code to really reactive code that doesn't need virtua…

Does anybody use https://preactjs.com/ seriously?

I thought React and React-DOM were separate?

https://www.npmjs.com/package/react

https://www.npmjs.com/package/react-dom

Post reply on HN