Ask HN: Why doesn't a time travel debugger exist yet for JavaScript?
I know Microsoft had a project going for this that is almost certainly scrapped now because Chakra went the way of the dodo but between Facebook, Google, Microsoft, and Mozilla there is some pretty good backing behind JavaScript projects. I've never used TTD before personally but it seems like a game changer. Is this just a really hard feature to make or is it incredibly resource intensive? Is it actually not that helpful for developers? Am I missing something or is this just something that'll happen when it happens? It seems like you could make a pretty good integration with a browser that would make this valuable.
36 comments
Mozilla is working on WebReplay: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...
We're making progress on an experimental version in Firefox DevTools. It's not on the roadmap, but it is easy to try and we'd love feedback.
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...
This video highlights some of the existing functionality:
https://www.youtube.com/watch?v=yS5ai04TP5Y&t=4s
1. a realtime recording button 2. a timeline view of events on the top 3. the ability to scan back to a console message 4. the ability to rewind to a breakpoint 5. the ability to add a logPoint in the debugger and see the messages in the console quickly
I'll second other comments on the complexity side. Our architecture works on the Operating System level, which makes it fast and non-invasive, but the difficulty level in terms of pulling something like this off is very high as you have to understand the browser architecture from the system calls it makes, to way processes behave, to graphics, the JS engine, and DevTools architecture.
I think we're in a good place in terms of getting feedback and iterating on the product. There's lot's to do and it is very exciting!
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...
This video highlights some of the existing functionality:
https://www.youtube.com/watch?v=yS5ai04TP5Y&t=4s
1. a realtime recording button 2. a timeline view of events on the top 3. the ability to scan back to a console message 4. the ability to rewind to a breakpoint 5. the ability to add a logPoint in the debugger and see the messages in the console quickly
I'll second other comments on the complexity side. Our architecture works on the Operating System level, which makes it fast and non-invasive, but the difficulty level in terms of pulling something like this off is very high as you have to understand the browser architecture from the system calls it makes, to way processes behave, to graphics, the JS engine, and DevTools architecture.
I think we're in a good place in terms of getting feedback and iterating on the product. There's lot's to do and it is very exciting!
Wow this looks amazing already. I think something as simple as recording the input and output of a single function would be my most common use case and would make a world of difference for me but this goes way above and beyond.
Would it reduce the graphics, OS, etc complexity to just have the basic single function IO recording?
Would it reduce the graphics, OS, etc complexity to just have the basic single function IO recording?
The problems I see with limiting the scope to single function IO are
1. JS is dynamic and a single function can do a lot, even if you try to stub out the world.
2. from a product perspective it would be hard to communicate what is going on.
3. Perhaps console logs could cover a lot of these cases.
Does that make sense? What are you thinking of?
---
We definitely want to make it easy to visualize function calls (inputs/outputs). For instance,
- see outlier function arguments (the time the first param was null) or the function returned early...
- see outlier call sites (the time when the function was called from a different call site)
- see outlier timings (the time when the function called when some other state was null or a promise was pending) i.e. race detection
On the other side, we would love to help users see the impact of a function call. For instance,
- program slicing: the other code that was run because this function was invoked
- data tainting: the data that was either read or written to because this function was invoked
1. JS is dynamic and a single function can do a lot, even if you try to stub out the world.
2. from a product perspective it would be hard to communicate what is going on.
3. Perhaps console logs could cover a lot of these cases.
Does that make sense? What are you thinking of?
---
We definitely want to make it easy to visualize function calls (inputs/outputs). For instance,
- see outlier function arguments (the time the first param was null) or the function returned early...
- see outlier call sites (the time when the function was called from a different call site)
- see outlier timings (the time when the function called when some other state was null or a promise was pending) i.e. race detection
On the other side, we would love to help users see the impact of a function call. For instance,
- program slicing: the other code that was run because this function was invoked
- data tainting: the data that was either read or written to because this function was invoked
> I'll second other comments on the complexity side.
Ditto for Chrome DevTools. If I recall correctly, it’s feasible but would be a huge undertaking. Demand for the feature would have to be very large to justify the work involved.
Ditto for Chrome DevTools. If I recall correctly, it’s feasible but would be a huge undertaking. Demand for the feature would have to be very large to justify the work involved.
Very exciting project and thrilled to see something of this complexity come out of the JS world! Great work guys
Any plans bringing this to Windows? It appears this is currently only available on macOS.
We'd love to.
We have a WIP patch. At the moment, we're prioritizing MVP functionality, performance, and stability.
We have a WIP patch. At the moment, we're prioritizing MVP functionality, performance, and stability.
It is matter of runtime and not a particular language.
Foremost mutable nature of JavaScript makes it usually heavly optimized for performance with low level in-place memory changes. These are hard to track and aggregate without some OS/HW level snapshoting support.
Next challenge is recording state of external dependencies: DOM, WebGL, events and other APIs - each would need some change tracking/snapshoting/resuming capabilities.
Recording complete low level app state changes with fine granularity would need lot of fast memory. A dedicated diffing algorithm could make it even usable on developer machine. However I think the current focus of runtime implementors is end-user performance.
Some sort of parial-TTD tradeoff is implemented in JavaScript famework/libraries level: Redux, Vuex, Elm etc. They efficently track high-level application state changes but on very small scale. The allowed changes are explicitly defined by developer and they are usually grouped into transactions/actions/scopes. Such update granularity together with reactive stateless code allows simple and cheap tracking of changes under framework control. Naturally that falls short when outside effects are involved.
Foremost mutable nature of JavaScript makes it usually heavly optimized for performance with low level in-place memory changes. These are hard to track and aggregate without some OS/HW level snapshoting support.
Next challenge is recording state of external dependencies: DOM, WebGL, events and other APIs - each would need some change tracking/snapshoting/resuming capabilities.
Recording complete low level app state changes with fine granularity would need lot of fast memory. A dedicated diffing algorithm could make it even usable on developer machine. However I think the current focus of runtime implementors is end-user performance.
Some sort of parial-TTD tradeoff is implemented in JavaScript famework/libraries level: Redux, Vuex, Elm etc. They efficently track high-level application state changes but on very small scale. The allowed changes are explicitly defined by developer and they are usually grouped into transactions/actions/scopes. Such update granularity together with reactive stateless code allows simple and cheap tracking of changes under framework control. Naturally that falls short when outside effects are involved.
The previous version of Elm, 0.18, had a time travel debugger and it was wonderful. Version 0.19 broke something and it no longer works unfortunately. https://elm-lang.org.
Elm 0.19 actually also has a time travel debugger. Alas there is an issue with external packages.
There is a PR for that already, but it has not yet been merged: https://github.com/elm/compiler/pull/1850
At CurrySoftware we run a fork of the Elm compiler which merges this PR and has a feature to use ports and the debugger with `elm reactor`: https://github.com/CurrySoftware/compiler
And an example how to use it here: https://github.com/CurrySoftware/elm-reactor-example
There is a PR for that already, but it has not yet been merged: https://github.com/elm/compiler/pull/1850
At CurrySoftware we run a fork of the Elm compiler which merges this PR and has a feature to use ports and the debugger with `elm reactor`: https://github.com/CurrySoftware/compiler
And an example how to use it here: https://github.com/CurrySoftware/elm-reactor-example
Is there any work being done to get it working again? More broadly, is there any way to know what is actually being worked on with Elm? The language is amazing but it feels left for dead sometimes. Yet there seems to be a decent amount of activity on GitHub, so it clearly hasn't been: https://github.com/elm/compiler/commits/master
The best way to stay in touch is the slack, where most of the activity can be seen https://elmlang.slack.com/
The elm-dev channel contains most of the info coming from Evan :). I had the same feeling as you until I discover this.
The elm-dev channel contains most of the info coming from Evan :). I had the same feeling as you until I discover this.
It seems like the fix is in the making, and could be out in a few weeks.
Meanwhile, there is a forked version of the compiler with a hotfix for the debugger that works for most applications, even medium and large ones: https://github.com/elm/compiler/pull/1850
Meanwhile, there is a forked version of the compiler with a hotfix for the debugger that works for most applications, even medium and large ones: https://github.com/elm/compiler/pull/1850
I use in Elm 0.19 and it works just fine. Maybe it’s some JavaScript port?
Not general purpose but Redux has forward/reverse time debug tools https://github.com/zalmoxisus/redux-devtools-extension#redux...
As does Vuex!
I think the reason that none exist is that they are incredibly difficult to implement. My armchair observation is that tracing the entire history of the virtual machine is probably slow/memory intense/complex when the model of computation is not simpler (like in an elm-like functional language) if you limit the number of ways the state of the VM can change I think this becomes an exponentially simpler problem. I’ve been debugging/simulating a hardware project at work, and even small bits of hardware can take a really long time to simulate. I’m using that as comparison because it does give a nice timeline of the entire state of the system which you can explore through the whole execution timeline.
That's a great point. Tracing quickly becomes slow and memory intensive.
I think you would enjoy this write-up. WebReplay is explicitly not tracing for that reason.
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...
I think you would enjoy this write-up. WebReplay is explicitly not tracing for that reason.
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...
Thanks for the post, I didn't even realize how large the design space for something like this is. I enjoyed the level of detail and the explanations of the design tradeoffs.
Probably a combination of lack of everyday demand and the complexity of the task.
Time is notoriously difficult for many reasons which have been discussed at length [1].
The trend now is that the number of programmers doubles every 5 years [2]. This rapidly expanding group of potential users and creators means features just on the fringe today might become available at any time.
1. https://infiniteundo.com/post/25326999628/falsehoods-program...
2. https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html
Time is notoriously difficult for many reasons which have been discussed at length [1].
The trend now is that the number of programmers doubles every 5 years [2]. This rapidly expanding group of potential users and creators means features just on the fringe today might become available at any time.
1. https://infiniteundo.com/post/25326999628/falsehoods-program...
2. https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html
I think the issue is to make TTD work it needs to be designed in from the beginning as a hard feature. AKA if random new feature breaks TTD then random new features designers get told pound sand until they fix their code. The reverse means anyone trying to implement TDD keeps getting it broken with every release until they give up.
Also designed isn't the word I'd use for Javascript.
Also designed isn't the word I'd use for Javascript.
The Vue browser extension has some time travel features.
https://twitter.com/bterlson/status/1070754781822574592 suggests that chakra is not going the way of the dodo.
It already exists: https://www.youtube.com/watch?v=rDq1AN1kSn4
Thanks for sharing the link. I'd like to emphasize that webreplay is still R&D :)
It is neat to see how far we've come in a year though!
It is neat to see how far we've come in a year though!
That demo is incredible. After watching it, I'm inspired to look at how I can help out. For anyone else that feels the same way, here's the repo: https://github.com/firefox-devtools/debugger
It's a poor man's version but chrome Dev tools let you restart a stack frame, which is super useful.
We have time travel (sort of) at Testim.io that records and replays apps.
Literally years of development, edge cases and heuristics in order to be usable in face of changes that are meaningful in the page (since while replay is static the page itself changes).
Chrome used to have recording mode which was very decent.
Literally years of development, edge cases and heuristics in order to be usable in face of changes that are meaningful in the page (since while replay is static the page itself changes).
Chrome used to have recording mode which was very decent.
Maybe you should look for time travel debuggers existing for other languages in general before asking one for JS. There are really few TDDs exists in the world other than Microsoft's tools. Is is not hard to figure out why then: it is simply very hard.
Yazz has a very crude one in our profiler (yazz.com)
... because you haven't built one.
The TLDR Is that it is a super challenging and expensive (time and resources) task, for very little /end user/ win. That’s time that would be better spent improving user experience, and useful features, etc (eg opportunity cost)
It’s a huge amount of engineering work to implement a TTD, in a relatively simple (eg whole process) environment. But JS doesn’t do that, things like networking and page layout are very common so you get additional problems - at the semantically challenging end: what happens as deferred js scripts are loaded and subsequently rolled back; what happens to other resources that have load/unload handlers, etc.
There’s also another massive complexity challenge: by necessity you’d need the full DOM to support rollbacks as well. External TTDs work around this by the monumentally expensive task of essentially virtual using and tracing the entire process, but here you’re wanting to trace only a subset of the process (it needs to be a subset because you don’t want to be debugging machine instruction level, and you aren’t wanting to debug things like the GC).
It’s a huge amount of engineering work to implement a TTD, in a relatively simple (eg whole process) environment. But JS doesn’t do that, things like networking and page layout are very common so you get additional problems - at the semantically challenging end: what happens as deferred js scripts are loaded and subsequently rolled back; what happens to other resources that have load/unload handlers, etc.
There’s also another massive complexity challenge: by necessity you’d need the full DOM to support rollbacks as well. External TTDs work around this by the monumentally expensive task of essentially virtual using and tracing the entire process, but here you’re wanting to trace only a subset of the process (it needs to be a subset because you don’t want to be debugging machine instruction level, and you aren’t wanting to debug things like the GC).