Well, Om apps work exactly like this and don't seem to have these kinds of problems. When you want to squeeze additional bits of performance, you can use Immutable or Mori which, unless I am mistaken, better utilize memory by implementing persistent data structures using structural sharing.

Finally, nothing per se prevents you from mutating your Redux state tree. It is actively discouraged, and you will lose a lot of debugging benefits if you mutate your data, but for performance critical pieces you can write impure reducers that mutate the state in place. (Only do that if you're sure that's where the lag comes from—not likely to be an issue in real apps.)

Don't forget that even with traditional Flux you're still likely to allocate objects in your store getters or in your components' setState method calls. It's not like one or two objects allocated with Redux will change much.

Thanks for your response. It could very well be a more generic react/flux question (I'm new to both). Thanks for addressing it anyway. I'm only planning on building a traditional web app for now, but who knows, might want to create a web version of After Effects one day...

This is exactly the same concern as mine. Thanks for the explanation.

@gaearon just looked into redux.js.org - 3 principles and there:

State is read-only
The only way to mutate the state is to emit an action, an object describing what happened.

like some kind of misconception --- because as far as I understand mutating state is very discouraged

PS: morover than follows the third principle that contradicts the second haha))

Changes are made with pure functions
To specify how the state tree is transformed by actions, you write pure reducers.

So second principle says that you can mutate state. And third says that actually to make mutation you can use pure functions))) haha

PPS: maybe it is better to replace all mutation words in second principle with change words?
Cause change does not mean mutation. Should I open PR for this?