8 ms·

Ask HN: Why doesn't a time travel debugger exist yet for JavaScript?

• sanxiyn 8y ago
  Mozilla is working on WebReplay: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/WebReplay https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...
  • jasonlaster11 8y ago
    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/WebReplayRoadmap 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 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!
    • algodaily 8y ago
      Very exciting project and thrilled to see something of this complexity come out of the JS world! Great work guys
    • kaycebasques 8y ago
      > 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.
    • sebazzz 8y ago
      Any plans bringing this to Windows? It appears this is currently only available on macOS.
      • jasonlaster11 8y ago
        We'd love to. We have a WIP patch. At the moment, we're prioritizing MVP functionality, performance, and stability.
    • mavsman 8y ago
      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 8y ago
        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
• auslegung 8y ago
  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 8y ago
    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 8y ago
      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.
  • lisardo 8y ago
    I use in Elm 0.19 and it works just fine. Maybe it’s some JavaScript port?
  • neslinesli93 8y ago
    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 https://github.com/elm/compiler/pull/1850
  • jdemler 8y ago
    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 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 https://github.com/CurrySoftware/compiler And an example how to use it here: https://github.com/CurrySoftware/elm-reactor-example https://github.com/CurrySoftware/elm-reactor-example
• beart 8y ago
  The Vue browser extension has some time travel features.
• mlazos 8y ago
  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 8y ago
    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/WebReplay https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...
    • mlazos 8y ago
      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 8y ago
  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-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program... 2. https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html
  • Gibbon1 8y ago
    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.
• philips 8y ago
  Not general purpose but Redux has forward/reverse time debug tools https://github.com/zalmoxisus/redux-devtools-extension#redux-devtools-extension https://github.com/zalmoxisus/redux-devtools-extension#redux...
  • geddy 8y ago
    As does Vuex!
• gefh 8y ago
  It's a poor man's version but chrome Dev tools let you restart a stack frame, which is super useful.
• taejavu 8y ago
  It already exists: https://www.youtube.com/watch?v=rDq1AN1kSn4 https://www.youtube.com/watch?v=rDq1AN1kSn4
  • jasonlaster11 8y ago
    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 8y ago
      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
• Gaelan 8y ago
  https://twitter.com/bterlson/status/1070754781822574592 https://twitter.com/bterlson/status/1070754781822574592 suggests that chakra is not going the way of the dodo.
• zubairq 8y ago
  Yazz has a very crude one in our profiler (yazz.com)
• inglor 8y ago
  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 8y ago
  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.
• elamje 8y ago
  I'm not a javascript user myself, but I was wondering if FullStory.com is similar to this?
  • pkage 8y ago
    No, fullstory is an analytics platform that lets you replay a users actions, rather than a time-travel debugger for general Javascript code.
• segmondy 8y ago
  ... because you haven't built one.
• TagAsDelusion 8y ago
  ad, unsubscribe
• olliej 8y ago
  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).
• imhoguy 8y ago
  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.