Hacker News Reader

Comment by nine_k | Hacker News Reader

I don't think a typical React rendering call is even 100 calls deep. React itself adds maybe a dozen frames. Your components could be complicated, but likely they don't add more than another dozen or two. React is pretty efficient if you hold it right, and use for its intended purpose, that is, large and complex interactive UIs.

View on HN

The event handling alone is almost a hundred calls deep. Because a lot of the work is happening asynchronously, you won't see most of it when stepping through the debugger starting from a click handler for example, but try adding a breakpoint to the compiled JSX.

With fibers (React >16) and a couple commonly used hooks you'll easily hit a thousand high call stack.

Most JSX expands to a single expression, but I guess you mean a single component? I'm not sure what controversial here. I've attached debuggers to React component many times

Do you mean that the async chains of something().then(somethingElse()).then(...), into which async/await code desugars, grow 1000 levels deep? I never encountered it, but, OTOH, I did not research this in particular. V8 very definitely does not produce a call stack out of it, but schedules every new Promise as a separate task. (A bit like a Lisp threading macro.)

So, what forms 1000 levels of nested calls? Is that anything specific to React? I'm very curious now!

I meant the actual React code: handling the click event, running the component code, resolving dependencies and running hooks, building the virtual dom then handing off to react-dom for reconciliation, scheduling updates, and finally modifying the DOM. Not your application code.

The async comment was to point out that if you attach a breakpoint to your `onclick` handler, you will reach 'the end' of execution after less than a hundred function calls. But the actual work (see above) inside react and react-dom hasn't even started, as it's pushed to a queue. This may give the impression that far less code is running than actually is.

This is still in context of "you can read through the library's codebase and understand what it's doing fairly easily"; so yes, it's specific to React being very complex vs something like htmx, which most devs could understand in its entirety in one afternoon.

You also have to take into account the browser and OS call stack.

This does not change if you write pure Javascript that directly mutates DOM without calling any intermediate functions.

Given the speed of rendering that browsers achieve, I would say that their call stack during this is highly optimized. I don't see OS doing much at all besides sending the drawing buffers to the GPU.

And also, that with React you are not only buying into React, but also a JavaScript dependency manager/package manager. Be it NPM, or any other. Installing JS package itself already comes with its own problems. And then probably people buy into more stuff to install through that package manager. Some component library and a "router" here, some material style and a little library to wrap the root node with some styling provider or what it is called there, ... before you know it, a typical FE dev will have turned your stack into 80% React and related dependencies and the maintenance on that will continue to grow, as new features "can be solved sooo easily, by just adding another dependency" from the NPM/React world.

Reply on news.ycombinator.com