[MrJohz]

I don't quite understand the point about rendering, unless you mean it in the Angular sense (i.e. on every state update, the whole app gets rendered, and elements are updated to the new state during that render).

But I can imagine that the API can be easier. I think React handles state fairly well, but as soon as that state needs to interact with things outside the React world (http requests, continuously updating data, etc) then the current abstractions don't quite feel right.

[fngjdflmdflg]

>i.e. on every state update, the whole app gets rendered

Yes, that's basically correct:

>Calling setState notifies the framework that the internal state of this object has changed in a way that might impact the user interface in this subtree, which causes the framework to schedule a build for this State object.[0]

The `build` method rebuilds the entire widget tree. So "the whole app" does not necessarily get re-rendered, only whatever is in the same widget as the changed state or below it, although potentially that can be the whole screen. Flutter also uses an algorithm to detect unchanged widgets and reuse them,[1] but conceptually the whole thing is re-rendered on state change.

[0] https://api.flutter.dev/flutter/widgets/State/setState.html

[1] https://docs.flutter.dev/resources/inside-flutter#linear-rec...

[elbear]

React doesn't work in the same way? I don't know much about it, but I assumed it does.

[fngjdflmdflg]

I'm not sure. Hopefully someone here can let us know. I didn't mean to imply that react doesn't work that way.

[satvikpendem]

It does work that way. However, Flutter and now React (via their new compiler) are becoming smarter at rerendering, where they will only rerender what has truly changed, not just rerender the entire tree below the changed component.

[beanjuiceII]

react and flutter are pretty much the same thing, i do both for a living i am not sure what this person is going on about