No, if you get/set methods that doesn't imply javascript with jquery! I am using React, but not ReactRouter or Redux. I hold my application state in a tree, and the tree nodes have get/set methods. My state tree is not immutable. I think "immutable way of changing state" is an oxymoron.
It depends on the complexity of the application. If I am happy with the performance profile with mutable state then going with immutable state is obviously an overkill. These optimizations matter when React spends lot of time diffing the virtual dom of the entire app component for every state change.
I don't have an example with mutable state but for React + Redux, click on the benchmark perf test page @ https://github.com/guptag/js-frameworks. With 1500 tickers added to the page and with an price update happening every 10ms, React/Redux updates the view within 5ms (on my machine) and consistently maintains 60fps. This is when React does the virtual diffing of only one ticker component whose state is changed and skipping the rest (because of React-Redux's immutability checks). It's going to take more time if React spends diffing the entire app for every update (unfortunately, I don't have a measurement with mutable state as I built this page to compare with AngularJS).
We can easily measure and make a call whether immutability is needed for an app or not.
Breakpoints cannot replay. They can pause and continue playing.
The inability to examine a time series of data after-the-fact and resume from any point makes this approach significantly, significantly worse. Like, I've done it just as you have, and I'd under no circumstances go back. It's so bad that I've basically built action-pattern systems in other languages (before using Redux, actually).
Functional tooling and composition with managed side effects is fucking awesome and doing otherwise verges on footgunning if it doesn't camp right out there.
I guess you must be having a whole different set of problems than me. I also use Redux, have not found time travel to be a boost to my productivity. I choose Redux because of the simplicity around state management, and having it all centralised in a store is a nice pattern. (Don't really get other commenters claiming that this isn't new - I don't see the relevance).
