5 ms·

Some of the comments here are surreal, I tell you. Surreal. I use chrome's built-in debugger to debug compiled down typescript code. I go to the original TS f

Some of the comments here are surreal, I tell you. Surreal. I use chrome's built-in debugger to debug compiled down typescript code. I go to the original TS files, mark a line by conditional breakpoints, it works perfectly. It stops the execution of the compiled JS files, it uses the source map to find the original line (which I placed the breakpoints in) AND it has a perfectly fine, working stack trace as well at pause. I can also blackbox at will. Timetravel debugging is going to happen soon (with its proper costs), and thats about it. Variable watching is the only pain point, but that is only because TC39 axed the native observable implementations a few years ago. I would not respect anyone who calls this level of debugging support "bad". It can be improved, but it is satisfactory.

seanmcdirmid 7y ago
It is bad compared to more developed debugging experiences (Eg visual studio and C# or even eclipse and Java). It is better than nothing or GDB of course. I personally think the Chrome debugger interface is horrible, but that is easily fixed by using Visual Studio Code instead. Even then, things feel off...but more like unpolished.
- tonyarkles 7y ago
  > GDB of course Every time I end up using a GUI debugger, I end up disappointed. GDB has spoiled me. Best feature that GDB has, for me? The ability to script what happens when a breakpoint is hit. A recent example: I have a state machine on an embedded system that is somewhat timing dependent (delaying a couple milliseconds is fine, delaying >1 sec is not). I stuck a breakpoint on the entry point and told GDB to dump a state structure every time it hit and then automatically continue. I get output describing exactly which events are coming in and what the state is at each step. Magic! This is relevant in JS land when you have a bunch of callbacks/promises/whatever. HTTP requests continue executing while you’re paused on a breakpoint, so debugging things like out-of-expected-order promise results gets really hard. GDB is definitely a power tool and requires some learning to use it effectively, but don’t write it off just because of that.
  - woah 7y ago
    You could just write that code temporarily inline
    - seanmcdirmid 7y ago
      Ya, that’s what I would do. More to the point, the interface for more more advanced debugger features generally don’t make them worth it (eg intellitrace). Debugging is a heavily constrained usability experience.
    - tonyarkles 7y ago
      Sure, if I had access to some kind of console output interface! I could have set up a UART, and a bunch of complex code to walk through the whole data structure, and hoped that formatting and streaming it all out didn't blow my timing. Or I could do: break fsm_entry command p/x event p/x state c end
  - Bjartr 7y ago
    > Best feature that GDB has, for me? The ability to script what happens when a breakpoint is hit. Conditional breakpoints in chrome could do this for a while by having your conditional be a call to a logging function, and it was recently made more discoverable and user-friendly as "logpoints".
haburka 7y ago
I love typescript. I use it basically as much as I can. Some projects have builds that break breakpoint support. I’m not sure of the exact cause, but it is frustrating. I often have to disable source maps when this happens,
Jasper_ 7y ago
I have had a similar experience... perfect debugging, breakpoints working, everything fine, up until yesterday. I think something in my stack got upgraded, and ever since, exceptions have broken callstacks. Trying to click a breakpoint takes me somewhere completely else in the sources viewer, and sometimes, exceptions don't break at all. No, I don't know why. Something broke, I still need to investigate, but it's another annoyance that reminds me of how much of my time is going to debugging and fixing platform issues. I think the big issue is just how fragile and brittle source maps are. They feel like a joke, compared to DWARF and native debuginfo. But who knows, maybe they'll start working again tomorrow.
- Sawamara 7y ago
  That is frustrating, I concede on that point. (If there is one thing that is bad about the JS ecosystem, its the brittleness and complexities of setting up build tools. If you get together one that suits your need, you do not look at it again unless an update breaks it. Then the process of looking it up how exactly it works comes again, and this repeats yearly :P)

seanmcdirmid 7y ago

It is bad compared to more developed debugging experiences (Eg visual studio and C# or even eclipse and Java). It is better than nothing or GDB of course. I personally think the Chrome debugger interface is horrible, but that is easily fixed by using Visual Studio Code instead. Even then, things feel off...but more like unpolished.

tonyarkles 7y ago
> GDB of course Every time I end up using a GUI debugger, I end up disappointed. GDB has spoiled me. Best feature that GDB has, for me? The ability to script what happens when a breakpoint is hit. A recent example: I have a state machine on an embedded system that is somewhat timing dependent (delaying a couple milliseconds is fine, delaying >1 sec is not). I stuck a breakpoint on the entry point and told GDB to dump a state structure every time it hit and then automatically continue. I get output describing exactly which events are coming in and what the state is at each step. Magic! This is relevant in JS land when you have a bunch of callbacks/promises/whatever. HTTP requests continue executing while you’re paused on a breakpoint, so debugging things like out-of-expected-order promise results gets really hard. GDB is definitely a power tool and requires some learning to use it effectively, but don’t write it off just because of that.
- woah 7y ago
  You could just write that code temporarily inline
  - seanmcdirmid 7y ago
    Ya, that’s what I would do. More to the point, the interface for more more advanced debugger features generally don’t make them worth it (eg intellitrace). Debugging is a heavily constrained usability experience.
  - tonyarkles 7y ago
    Sure, if I had access to some kind of console output interface! I could have set up a UART, and a bunch of complex code to walk through the whole data structure, and hoped that formatting and streaming it all out didn't blow my timing. Or I could do: break fsm_entry command p/x event p/x state c end
- Bjartr 7y ago
  > Best feature that GDB has, for me? The ability to script what happens when a breakpoint is hit. Conditional breakpoints in chrome could do this for a while by having your conditional be a call to a logging function, and it was recently made more discoverable and user-friendly as "logpoints".

haburka 7y ago

I love typescript. I use it basically as much as I can. Some projects have builds that break breakpoint support. I’m not sure of the exact cause, but it is frustrating. I often have to disable source maps when this happens,

Jasper_ 7y ago

I have had a similar experience... perfect debugging, breakpoints working, everything fine, up until yesterday. I think something in my stack got upgraded, and ever since, exceptions have broken callstacks. Trying to click a breakpoint takes me somewhere completely else in the sources viewer, and sometimes, exceptions don't break at all. No, I don't know why. Something broke, I still need to investigate, but it's another annoyance that reminds me of how much of my time is going to debugging and fixing platform issues. I think the big issue is just how fragile and brittle source maps are. They feel like a joke, compared to DWARF and native debuginfo. But who knows, maybe they'll start working again tomorrow.

Sawamara 7y ago
That is frustrating, I concede on that point. (If there is one thing that is bad about the JS ecosystem, its the brittleness and complexities of setting up build tools. If you get together one that suits your need, you do not look at it again unless an update breaks it. Then the process of looking it up how exactly it works comes again, and this repeats yearly :P)