The premise of Tufte's work make sense until you try to apply it to functional and usable user interfaces.
He has strong opinions strongly held but as someone who's designed industrial strength UIs for over 20 years (networking CLIs & UIs, CAD modeling/simulation, Devops dashboards, cybersecurity tooling) I've read all his books, attended his lectures... he's a king with no clothes
Unfortunately, the site was butchered a year or two ago with a redesign to make it look like a garden-variety Wordpress blog. A ton of content disappeared. The front page is reasonably dense, although one might also just call it cluttered, but the subpages are worse - sometimes a single paragraph lost in a sea of wrappers.
I also miss the web. When HTTP form posts were a thing. React and friends are desktop apps, delivered over HTTP, where the browser is the runtime. You know why we got so obsessed with JavaScript? Cause screen refreshes look janky. "Just use XMLHttpRequest to send the data ONLY over the wire! And get data ONLY as a response!" That's how we got into this mess. I'm not saying you don't need JavaScript, or there aren't reasons to use React. I'm saying there are easier solutions to jank. If good engineering is the ability to design the least complicated solution to a problem, we are far from good engineering.
It's weird to see React frequently treated in these kinds of discussions as the opposite of the good-old ways of doing things because React has great support for server-side rendering and form posts. Its server support was one of its major features that initially distinguished it from other front-end frameworks of the time and helped lead to its popularity.
I recently visited Tulum and experienced their architecture firsthand. It is breathtaking in both form and function. Beautiful in every way.
Their philosophy got me thinking -- are there lessons to be learned in software? Do we use the same workflow for everything, when perhaps a bespoke workflow could be more appropriate for some projects? Do you already do this?