So i have been writing emberjs apps for almost a year now and at the same time have been writing reactjs, isomorphic apps based on flux then I moved to redux. Hopefully I can help with this discussion.
Actually, one of the major challenges of Ember Fastboot is how do you transfer the state from the server to the client, because ember does not have centralized place to do so. But we are missing the point - hot reloading has nothing to do with the state or redux or flux at all. Dan’s hot reloading magic works off of react-proxy: https://github.com/gaearon/react-proxy which binds onto components and does a proxy swap if you will when files have changed, hence why it’s build on a babel plugin he made to instrument the hot reloading, see: https://github.com/gaearon/babel-plugin-react-transform
Bringing it to ember world, hot reloading is possible and much more near than we think. The challenge is on compile time, using babel to find components, wrap them in a proxy that passes all attrs down to the component and saves those attrs internally. Then on file change, it would swap the new component with the old. Then the attrs would be applied downstream as they were before and we are in a good place. I don’t know how it will work with routes but controllers are similar to components I’d assume.
That’s why you see in the video, Redux is not maintaining state on hot reloading because Redux never gets touched at all. And if you were to change any redux related code (reducers or middleware) it’d prompt you to a page reload in the console.