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

A mostly complete guide to React rendering behavior (2020)

blog.isquaredsoftware.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: A mostly complete guide to React rendering behavior (2020)

#41

Post by mst »

nsonha wrote: post #3

anyone knows the status of the React Forget thingy?

Tangentially, Solid is fascinating - especially the dom-expressions backend meaning you can basically bolt compilation behaviour into anything that supports that.

I have https://github.com/ryansolid/mobx-jsx/?tab=readme-ov-file#mo... on my list to try since I -really- like mobx for stage management (especially mobx-keystone) and am fascinated by how clean the results can be.

Though for 'real' code I still tend to default to react + mobx-keystone because for all my gripes with react it's a pretty solid Schelling Point.

Re: A mostly complete guide to React rendering behavior (2020)

#42

Post by mst »

acemarke wrote: post #22
recursive wrote: post #5

Earlier quoted context omitted.

The flagship feature of React 19 is a "compiler", but doesn't seem to have the main features of Forget. (inferred effect dependencies) I'm guessing it's not coming any time soon.

React 19, a library release, is completely separate from the eventual release of the React Compiler build tool (which is currently implemented as a Babel plugin wrapper around a full compiler implementation core). That said, React Compiler will _depend_ on React 19, because it needs a new memo/caching hook that will be included in 19.

I wonder how it compares to https://github.com/ryansolid/dom-expressions/tree/main/packa...

Re: A mostly complete guide to React rendering behavior (2020)

#43

Post by gr4vityWall »

Spivak wrote: post #16
klysm wrote: post #14

Earlier quoted context omitted.

Easy to call it absurd without proposing an alternative. In the real world react solves a ton of problems and lets developers write apps.

I think most people would consider almost any other stack based UI framework that has no fear of stateful components, layout engines with constant solvers, and lets you control when and how to draw frames to be an improvement. Imagine a world where you just had drawing and input handling primitives on the web. You wouldn't invent the DOM and then something like React to wrangle it that's for damn sure.

>You wouldn't invent the DOM and then something like React to wrangle it

Then you'll also have to reimplement accessibility features yourself. For a lot of use cases, that isn't worth the trade-off, imo.

Re: A mostly complete guide to React rendering behavior (2020)

#44

Post by SPascareli13 »

continuational wrote: post #29
itronitron wrote: post #25

Earlier quoted context omitted.

It isn't needed. Teams could develop complex web applications before React existed and they can still do so. If the developers have experience with other languages and native UI frameworks then they probably won't want to use any of the Javascript frameworks when developing a web application as they already have a mental model for how to setup the structure of function callbacks for handling user interactions and sta…

The problem with using the DOM or similar UI frameworks is that you have to code the delta from any state to any state by hand. This is exceedingly complex, error prone (because you might miss parts of the state that should change) and often slow (because you tend to overcorrect).

The problem seems to be that the fundamental abstractions in web (HTML and the DOM) are not suited to modern web apps. This much complexity around state management shouldn't be needed.

Re: A mostly complete guide to React rendering behavior (2020)

#45

Post by SPascareli13 »

MartijnHols wrote: post #27
SPascareli13 wrote: post #6

Not a critic to the article itself, in fact I know nothing about React and learned a lot from the it, but...do we REALLY need all of this to render web pages? Even if it is a web application and not just a page, doesn't this ecosystem seem too complicated for the problem it solves?

You don’t really need to know the majority of what’s in this article to make good apps with React. It goes in-depth into how the framework works. Any framework will look complicated when you look under its hood; it’s meant to make everything possible after all. Actual React apps are as simple and elegant as a complex (web) application ever could be. Separating your app into functional components where most complexity…

The thing about looking under the hood into the complexity of the tool you're using is that is can make you consider my initial question in this thread: Do I REALLY need all of this for my use case?

I think if more people would do this exercise they would find that they don't need it, or at least that they might need some form of state reconciliation, but not enough to really warrant all the complexity the tool introduces. Some will find that they don't need it but will still use it for other reasons, like familiarity or because that's what their team uses.

Re: A mostly complete guide to React rendering behavior (2020)

#46

Post by Spivak »

MrJohz wrote: post #26
Spivak wrote: post #16

Earlier quoted context omitted.

I think most people would consider almost any other stack based UI framework that has no fear of stateful components, layout engines with constant solvers, and lets you control when and how to draw frames to be an improvement. Imagine a world where you just had drawing and input handling primitives on the web. You wouldn't invent the DOM and then something like React to wrangle it that's for damn sure.

> Imagine a world where you just had drawing and input handling primitives on the web. Good news! We do have those primitives! The canvas element can - and is - used for drawing, and input events are fairly easy to manage. Larger projects like Google Docs or Figma often go in this direction, because for very complicated applications, it's useful to be able to handle every part of the rendering process yourself. That…

This misses the point entirely, what I mean is that if we didn't already have DOM we wouldn't invent it again — we would invent something like UIKit that has all your premade debuggable accessible components but without the kludge of the DOM.

I think this gets to the core of web devs seemingly not knowing anything else. Not knowing that, from a technology standpoint, how much better you could have it.

Re: A mostly complete guide to React rendering behavior (2020)

#47

Post by blackhaj7 »

cynicalsecurity wrote: post #35
blackhaj7 wrote: post #9

Earlier quoted context omitted.

What’s absurd about it? What’s a better option in your opinion? Asking as someone who mostly knows the React approach

Just generate a web page on the backend. Sprinkle it a bit with some simple JavaScript/jQuery code for animations, forms checking etc, if you want. That's it. That's how it was supposed to work and that's how it works best. JavaScript was made to make the monkey dance. The end result, either made with overcomplicates frameworks like React/Angular or with simply generating the web page on the backend, is irrelevant to…

Agreed with “just generate a web page on the backend”. But if the webapp is sufficiently complex (all websites I have been paid to work on have been), you need a component based framework like React to make the creation of the page manageable

Re: A mostly complete guide to React rendering behavior (2020)

#48

Post by acemarke »

matharmin wrote: post #38
phendrenad2 wrote: post #37

This is already mostly out-of-date, right?

Updated in 2022, but I don't see anything on for example. That doesn't necessarily mean the info is now wrong, but it's definitely not complete anymore.

I did title it "_Mostly_ Complete Guide" for a reason :)

Everything in that post should still be 100% accurate and relevant.

I specifically did _not_ try to go into further details on Suspense or some of the intricacies of Concurrent Rendering (beyond "React can cancel or reset those render passes"). My overall goal was to explain the core mental model of how React's basic rendering works on the client side.

As far as Suspense goes, that can be summarized as "throw a promise while rendering, `` acts like a `try/catch` at the component level, React will re-render this component when the promise resolves and from its perspective that function call _always_ returned the data synchronously".

Concurrent Rendering is really complicated internally, but loosely: React has an internal notion of priorities for queued renders. `startTransition`, `useDeferredValue`, and Suspense all mark renders as low priority, so those render passes can be "rebased", interrupted, or canceled as needed based on updates that come in later.

Re: A mostly complete guide to React rendering behavior (2020)

#49

Post by klysm »

vcarl wrote: post #33
klysm wrote: post #13

Earlier quoted context omitted.

Nope we don’t, but it solves a lot of the problems people frequently encounter while building web pages without too much of a downside. It’s a big trade off space and react sits in a very nice spot in that space.

Phenomenal answer. No, you don't need it, but if you build something long enough you'll avoid a couple categories of common problems by starting with it (and choose a different set of common problems)

I like to think about framework choices as choosing which kind of problems you are okay with experiencing. This choice can be made from a product perspective much easier

Re: A mostly complete guide to React rendering behavior (2020)

#50

Post by ironmagma »

kaba0 wrote: post #32
ironmagma wrote: post #17

Earlier quoted context omitted.

It's the same thing with every technology for me. C++ is pretty absurd, same with Java/Spring framework, ditto for Linux and the whole TTY system/file descriptor hell. Anywhere where someone spends their whole life is probably going to be a big mess.

With all due respect, I believe there is a certain demographic in IT that just has a way too trivial working model of how stuff they don’t work on directly operates. Like, they know how to do a simple HTTP query in C/go whatever, and then don’t understand why would you need the whole complexity of spring. It just turns out that the real world is more complex than what they assume - and they are often more than aware…

Yes, and to me the logical conclusion of that is to not worry about how complex React is. I'm sure someone somewhere needed the complexity of each feature somewhere along the line. Is it more than I need? Yes, but maybe someday the complexity will be something I appreciate. And in the meantime, you can just ignore it since it's not directly in your path.
Post reply on HN