
Ask HN: Why doesn't a time travel debugger exist yet for JavaScript? - mavsman
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&#x27;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&#x27;ll happen when it happens? It seems like you could make a pretty good integration with a browser that would make this valuable.
======
sanxiyn
Mozilla is working on WebReplay: [https://developer.mozilla.org/en-
US/docs/Mozilla/Projects/We...](https://developer.mozilla.org/en-
US/docs/Mozilla/Projects/WebReplay)

~~~
jasonlaster11
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...](https://developer.mozilla.org/en-
US/docs/Mozilla/Projects/WebReplayRoadmap)

This video highlights some of the existing functionality:

[https://www.youtube.com/watch?v=yS5ai04TP5Y&t=4s](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!

~~~
mavsman
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?

~~~
jasonlaster11
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

------
imhoguy
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.

------
auslegung
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](https://elm-lang.org).

~~~
nilkn
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](https://github.com/elm/compiler/commits/master)

~~~
jlengrand
The best way to stay in touch is the slack, where most of the activity can be
seen [https://elmlang.slack.com/](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.

------
philips
Not general purpose but Redux has forward/reverse time debug tools
[https://github.com/zalmoxisus/redux-devtools-
extension#redux...](https://github.com/zalmoxisus/redux-devtools-
extension#redux-devtools-extension)

~~~
geddy
As does Vuex!

------
mlazos
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.

~~~
jasonlaster11
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...](https://developer.mozilla.org/en-
US/docs/Mozilla/Projects/WebReplay)

~~~
mlazos
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.

------
nerdy
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...](https://infiniteundo.com/post/25326999628/falsehoods-programmers-
believe-about-time)

2\. [https://blog.cleancoder.com/uncle-
bob/2014/06/20/MyLawn.html](https://blog.cleancoder.com/uncle-
bob/2014/06/20/MyLawn.html)

~~~
Gibbon1
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.

------
beart
The Vue browser extension has some time travel features.

------
Gaelan
[https://twitter.com/bterlson/status/1070754781822574592](https://twitter.com/bterlson/status/1070754781822574592)
suggests that chakra is not going the way of the dodo.

------
gefh
It's a poor man's version but chrome Dev tools let you restart a stack frame,
which is super useful.

------
inglor
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.

------
kbumsik
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.

------
taejavu
It already exists:
[https://www.youtube.com/watch?v=rDq1AN1kSn4](https://www.youtube.com/watch?v=rDq1AN1kSn4)

~~~
jasonlaster11
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!

~~~
mavsman
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](https://github.com/firefox-
devtools/debugger)

------
zubairq
Yazz has a very crude one in our profiler (yazz.com)

------
segmondy
... because you haven't built one.

------
elamje
I'm not a javascript user myself, but I was wondering if FullStory.com is
similar to this?

~~~
pkage
No, fullstory is an analytics platform that lets you replay a users actions,
rather than a time-travel debugger for general Javascript code.

------
olliej
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).

