Live data from Hacker News

A mostly complete guide to React rendering behavior (2020)

blog.isquaredsoftware.com

51–56 of 56 posts

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

#51
post #16
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. You wouldn't invent the DOM and then something like React to wrangle it that's for damn sure.

I think this is a really good thought experiment and that you are right - we wouldn't end up with the DOM if we started from scratch. It's a pretty bad local optima resulting from decades of legacy cruft. However, I do think react is closer to that ideal than the DOM.

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

#52
post #46
post #26

Earlier quoted context omitted.

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

No one uses the DOM because they think it’s the best possible GUI technology. They build software for browsers because browsers are the lowest common denominator for distribution, which is far, far more important than technical considerations most of the time. And because of that, there’s also a large ecosystem of well understood, well documented, widely used, beginner-friendly tools for it, ranging from jQuery to React to Tailwind to WordPress.

We can talk all day about how there are better ways to do it, but until you solve the distribution problem, the technology doesn’t matter. Mobile apps sort of solved it, but even then, the bar for installing an app is higher than the bar for clicking on a link. Plus there are cross-platform tech and policy differences to deal with, you can’t guarantee your users are running the same version of the app, etc.

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

#53

Earlier quoted context omitted.

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 re…

at the end of the day it is really about which poison you would pick; one team dealing with one complicated toolchain or five teams with their own bespoke OS-specific toolchains that can barely coordinate. They're both not good choices; and in an era that until recently was an era of dev scarcity, a lot of companies picked the former choice.

people also really hate feature gaps between platforms. so option one makes your customers less angry at you.

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

#54
post #46

Earlier quoted context omitted.

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.

No one uses the DOM because they think it’s the best possible GUI technology. They build software for browsers because browsers are the lowest common denominator for distribution, which is far, far more important than technical considerations most of the time. And because of that, there’s also a large ecosystem of well understood, well documented, widely used, beginner-friendly tools for it, ranging from jQuery to Re…

I'm not really disagreeing with you so much as wishing that webdevs had access to a better UI toolkit because the current state of things makes life harder unnecessarily.

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

#55

Earlier quoted context omitted.

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.

[dead]

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

#56

Earlier quoted context omitted.

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

[dead]
Post reply on HN