JavaScript debuggers are broken
samdesota.com
JavaScript debuggers are broken
1–10 of 124 posts
Re: JavaScript debuggers are broken
#2I have an error reporter in my app and it is completely useless. Stacktraces are usually just starting within some library and never touch app code. I rarely know where the error started, I just have to guess. It sucks.
Re: JavaScript debuggers are broken
#3It's great to know that you're working on this. The tools are definitely lacking on that regard.
Re: JavaScript debuggers are broken
#4An interesting trend I've seen is that interpreted languages often lack a debugger, as most "prototyping" ends up happening in a REPL, which act as sort of an interactive debugger with each prompt serving as a sort of "barrier" where each value is guaranteed to be reified and execution is not in some awkward place. Whereas with compiled languages you have debuggers that "work" because there's a consistent model of how execution proceeds and getting things like a stack trace is easy, allowing for things like placing breakpoints on lines of code or "executing" arbitrary code in essentially any context. Starting out with compiled languages myself, I find it really interesting to watch how other programmers structure their code in Python or JavaScript code to make it introspectable in the face of arbitrary reflection, asynchronous callbacks, etc.
Re: JavaScript debuggers are broken
#5Its interesting to see developers talking about and building debuggers whilst only apparently having experience of one.
EDIT: apparently the following is no longer true
From gdb, going to Chrome dev tools was super painful. I had been used to writing high quality watch statements. watch x, and break if it is is a very powerful debugging mechanism.
Chrome has "pin this variable and tell me its value every time I pause". This is overly manual. Its bad enough trying to get the erronous middle value when looping over a 10k array, never mind a more complex data structure where the error condition will depend on a parent/less obvious value.
Im not familiar with many debuggers, and I know I'm not a true expert in any. Id be keen to know what people think are awesome debugger features.
Re: JavaScript debuggers are broken
#6Its interesting to see developers talking about and building debuggers whilst only apparently having experience of one. EDIT: apparently the following is no longer true From gdb, going to Chrome dev tools was super painful. I had been used to writing high quality watch statements. watch x, and break if it is is a very powerful debugging mechanism. Chrome has "pin this variable and tell me its value every time I pause…
That’s actually not true anymore, Chrome supports conditional breaks and expressions.
Re: JavaScript debuggers are broken
#7Notable is that such a debugger, that records the entire exrcution and allows you to go back in time, already exists for compiled languages in the form of a gdb plugin: https://github.com/mozilla/rr
Re: JavaScript debuggers are broken
#8Its interesting to see developers talking about and building debuggers whilst only apparently having experience of one. EDIT: apparently the following is no longer true From gdb, going to Chrome dev tools was super painful. I had been used to writing high quality watch statements. watch x, and break if it is is a very powerful debugging mechanism. Chrome has "pin this variable and tell me its value every time I pause…
Edit and continue/resume
Re: JavaScript debuggers are broken
#9I have an error reporter in my app and it is completely useless. Stacktraces are usually just starting within some library and never touch app code. I rarely know where the error started, I just have to guess. It sucks.
This is excessively common. Somehow modern debugging is essentially as nuanced as "shit broke". Debugging was far better 20+ years ago under C++ in win32 then it is today - there was working code navigation as well.
I don't know how we have fallen so far back in the tooling.
Re: JavaScript debuggers are broken
#10An interesting trend I've seen is that interpreted languages often lack a debugger, as most "prototyping" ends up happening in a REPL, which act as sort of an interactive debugger with each prompt serving as a sort of "barrier" where each value is guaranteed to be reified and execution is not in some awkward place. Whereas with compiled languages you have debuggers that "work" because there's a consistent model of ho…
Compiled functional langs tend to have a repl and not a debugger.