It doesn't have to be this way for most apps. One reason I've seen why people heavily rely on the lifecycle methods is that UI = f(state) isn't fast enough. But in more powerful languages like ClojureScript, you can keep track of which part of the state is accessed, and subsequently rerun only parts of the f that needs to rerun. As I understand, there is something called React compiler (https://github.com/facebook/react/tree/main/compiler) that tries to do this. But in a better language, this doesn't need to be a standalone tool, just a macro.
Comments
It doesn't have to be this way for most apps. One reason I've seen why people heavily rely on the lifecycle methods is that UI = f(state) isn't fast enough. But in more powerful languages like ClojureScript, you can keep track of which part of the state is accessed, and subsequently rerun only parts of the f that needs to rerun. As I understand, there is something called React compiler (https://github.com/facebook/react/tree/main/compiler) that tries to do this. But in a better language, this doesn't need to be a standalone tool, just a macro.
I agree, Elm also does UI=f(s) really nicely. But it's not something you can do in JavaScript while also keeping everything JavaScript.