I have already departed from this and started only traveling and not developing. I understood one thing: when you work a lot, you lose yourself. Now I decided to enjoy my life sitting in a compartment or convertibles that I rent from van rental san diego . Only thanks to travel can I develop and enjoy life!

Once a while I use such a debugging to examine the loading steps of my first screen. I can record and replay the actions created by initialization code and network requests.

Also in my tool I got a diff tab to show the changes of the store, so I can check if that code worked correctly.

Also, histories are useful too. Like some server pushed messages, I can find them there.

Time traveling debugging may help in large apps. Small apps could be simple enough and one does not need a tool to understand it.

My tool was a bit different from Redux, you may check this: twitter.com/jiyinyiyong/status/737188000174481409

While working on complex frontends with ui interfaces built using reactive libraries like Knockout I occasionally came across situations where it would not be easy to deduce why a particular observable had a value that it had.

Declaratively defining computed observables works really well for modelling relationships, but sometimes makes reasoning through the dependency computation difficult - specially when dealing with real time data streams where entities have non-trivial relationships.

Sometimes it would be very minor errors eg. mutating an object contained in an observable which the observable could not detect because the identity of an object had not changed, or not failing to acknowledge that some computed observables were throttled while some others deduced from the same sources were not - leading to inconsistent state, that would take time in order of hours to debug.

While redux requires quite a bit of boilerplate, debugging through this kind of situations becomes a lot easier because you can log the actual sequence of actions, and know for sure that replaying the same sequence of actions will result in same (erroneous) state. Time travelling debugger just makes this debugging process a bit more easier because it lets you rewind and replay few actions and inspect store state in between.

I never used it (and I kinda hate redux), but I guess, when you have an error in production you can have some code save the steps so you can reproduce them later.

Since reproducing the error is often the biggest challenge when getting rid of a bug, this could save a lot of time.