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

21–30 of 56 posts

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

#21

Post by bobthepanda »

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.

the web won not because it was the best technology. the web won because it's basically the one thing that has a standards body and exists on pretty much every device.

writing native apps means having to have basically 4+ development teams for Windows/Mac, Android/iOS, and 5 if you want to have Linux. And it is pretty logistically difficult to herd five separate teams using the same product roadmap because the implementation of one feature can vary so wildly. But if you don't and someone gets a feature someone else doesn't get then people get upset.

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

#22

Post by acemarke »

recursive wrote: post #5
nsonha wrote: post #3

anyone knows the status of the React Forget thingy?

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.

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

#23

Post by apsurd »

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?

I made my career on open source web technologies before both GitHub and Stackoverflow were a thing. I love the web! And I love making UIs and I can spend untold hours with CSS even! And I agree the state of frontend is completely bonkers.

React absolutely improved things from spaghetti jQuery. The zero-to-one productivity for interactive UIs goes through the roof, but growing and maintaining your project for any serious business use case is a complete nightmare.

I don't wish isometric javascript on any one. Javascript was infamously created in a week or whatever and now it's the browser standard, so be it, by why in god's name would you ever pick it for your server?

I burned myself out working on a personal project completely on my own using nextjs. I was super productive at the start, then as business logic increased... typing and flowing everything through components, state, reducers, selectors, async network calls, good God I grew to hate all of it.

I came crawling back to Rails. Everything and the kitchen sink is loaded in a controlled and blocking env. You can abuse the fuck out of it and it smiles at you. I'm sorry I left you Rails. (rails backend for all business logic: "the brain". Thin/dumb React JS client that consumes view-based APIs. React is great for interactive UIs. Not your fledgling business logic)

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

#24

Post by teaearlgraycold »

gofreddygo wrote: post #8

ya'know, everytime there's a post with react in the title, I open it with the best positive attitude I can muster, holding back my knee jerk reaction. I then read it, and come out thinking "why, why, why do people put up with this absurdity?" and always stop at the same conclusion, cz they don't know any better. I then quietly move on with my life, sometimes leaving such comments as hints to those who might catch on.

Are you an experienced UI developer that knows of something we should all use instead? Even if it's non-web I'd love to hear about it. We all would. Then we might take inspiration from it and build a new web framework.

Pretty much no one that uses React _loves_ it. But we all use it because it gets the job done.

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

#25

Post by itronitron »

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?

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 state changes.

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

#26

Post by MrJohz »

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.

> 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 said, it turns out having a rich selection of easily-debuggable, accessible components attached to a powerful layout engine is also really useful, hence why people mostly stick to the DOM unless they specifically need something that only canvas can offer.

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

#27

Post by MartijnHols »

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 is always local is a great way to make the application structure as simple as they can be. Where developers often go wrong, is trying to force patterns from other frameworks or languages into React and TS/JS.

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

#28

Post by noahtallen »

bobthepanda wrote: post #21
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.

the web won not because it was the best technology. the web won because it's basically the one thing that has a standards body and exists on pretty much every device. writing native apps means having to have basically 4+ development teams for Windows/Mac, Android/iOS, and 5 if you want to have Linux. And it is pretty logistically difficult to herd five separate teams using the same product roadmap because the impleme…

The other big piece missing is that desktop-based GUI tools have native primitives that are designed for building complex apps. The web has bits and pieces, but is still a document renderer at its core. I’ve worked in a few of the XML-based GUI tools and MVC frameworks, and none of them were great, especially for real-time information. But at least the native SDKs provide basically everything you need.

I think the reactivity model React has is very compelling, and once you start thinking in terms of “GUI as a function of state,” you start trying to do the same in PHP or Swift and it just doesn’t work out as well. (Though there’s now SwiftUI which is a more reactive way to do iOS GUIs.)

I think react struck gold conceptually, and in a world where the “native sdk” (the browser) didn’t give you much, it became very compelling for many people. I think it has struggled to create intuitive APIs, and has struggled to handle real-world performance without clunky APIs.

Not to mention, browser environments face a slew of problems desktop apps don’t. You have to ship much smaller bundle sizes, no type-safe language, immature language requiring polyfills for useful language features, and the list goes on. Each problem introduces a new tool (webpack, typescript, babel, etc.), and they don’t frequently place nicely together. If I’m writing a Rust or Go program, practically every dev tool I need is part of the language toolchain. And while there are projects that aim to do that for web, they run into the “yet another standard” problem.

Backend has complex problems to solve, but at least you fully control the stack. You can use languages with simple toolchains and good libraries for writing web servers. On the front-end, every library you use is ultimately at the whim of the browser.

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

#29

Post by continuational »

itronitron wrote: post #25
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?

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).

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

#30

Post by kaba0 »

gofreddygo wrote: post #8

ya'know, everytime there's a post with react in the title, I open it with the best positive attitude I can muster, holding back my knee jerk reaction. I then read it, and come out thinking "why, why, why do people put up with this absurdity?" and always stop at the same conclusion, cz they don't know any better. I then quietly move on with my life, sometimes leaving such comments as hints to those who might catch on.

Like, what is better? GUIs are hard, the old way was duplicating state at the ”view” and the “model” layer, resulting in millions of bugs. The core idea of react v=f(m) is sound, and is the correct approach. Also, react itself is not even that complex.
Post reply on HN