I 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.
JavaScript debuggers are broken
51–60 of 124 posts
Re: JavaScript debuggers are broken
#52There are two types of code: Code that implements the “domain logic,” and code that implements various abstractions used by the do an logic.
I suggest that:
We need to be able to both debug the domain logic and the abstractions implementation independently of each other.
——-
In simpler days, the above was accomplished with feature like “step over,” or, “run until.” We simply skipped over the lines of code in functions that were “beneath” the level of abstraction that interested us.
Today, there are many deep layers of abstractions, and sometimes important things happen within them. Similarly, our data itself is wrapped up in bundles of abstractions, and sometimes we need a way to view that data as an abstraction, at other times we need to “drill down.”
We have sophisticated tools for building abstractions in code, and we have a way of bolting some of that onto the debugger by means of source code mapping.
But that is not enough. We need more sophisticated ways of stepping through our domain code that understands the abstractions it is hiding. We need to be able to write a framework or library, and write debugger extensions to go with it, just as we write extensions for our compiler toolchain.
That way, we can build abstractions that can be “stepped over” in the debugger as easily as we can write our code in abstractions in the editor.
——-
I think everyone realizes this and is rushing to implement point solutions here and there, like special cases for async stack traces when you use JS’ built-in async/await. And the author is hinting at an important “special case” for React.
I suspect that we need a more general facility for meta-debugging, much as macros are a more general facility for meta-programming.
Re: JavaScript debuggers are broken
#53Brian W. Kernighan and Rob Pike wrote that stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Kernighan once wrote that the most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
Or that has to pull data from a manually written csv our client uploads at 3 pm on their managed ftp and an untested REST api designed last month by a one man start up, using a legacy client lib that only god and a fired engineer knew how to get to work.
Or that has to be done with a trainee designer that knows photoshop but will "learn this css thing on the way" , a remote turkish consulting firm and your boss dog barking next to you because animals are good for moral and we are agile right ?
Those theories are good in a lab while writting carefully crafted c for the board you designed the spec for.
Re: JavaScript debuggers are broken
#54Brian W. Kernighan and Rob Pike wrote that stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Kernighan once wrote that the most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
Clearly the guy didn't have to pull out a working PoC in one week with a forced uppon JS framework that just changed its public API and not its doc and that need magic lines just for webpack to not crash. Or that has to pull data from a manually written csv our client uploads at 3 pm on their managed ftp and an untested REST api designed last month by a one man start up, using a legacy client lib that only god and a…
There is a lot of code out there that has very little logical sense per se other than elusive business requirements..
Re: JavaScript debuggers are broken
#55Brian W. Kernighan and Rob Pike wrote that stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Kernighan once wrote that the most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
It is much more efficient to place a breakpoint at the spot where you would have put the print statement and then inspect the values of interest in the debugger. It is a rather false dichotomy to assume that using better tools precludes you from "careful thought".
I find this a much more efficient workflow.
Re: JavaScript debuggers are broken
#56It's such a terrible language we spent the last 2 decades fixing its warts, adding one layer on top of the other. And now you have es7 + typescript + jsx + some magic introspection + code splitting + weird non standard imports, all that turned into regular JS and source maps, in a complex concurrent and async env that deals with graphics AND the network, 2 of the hardest things to get right. All that with zero stdlib, multiple incompatible clients, specific extensions for each store/router/event system you use and hot reload live pushing code.
And you wonder why it's hard to debug ?
I get that tooling is supposed to make our life easier, but let's be nice with the poor guys that have to work on the monster that must be usable with that stack.
Re: JavaScript debuggers are broken
#57I 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.
Re: JavaScript debuggers are broken
#58Brian W. Kernighan and Rob Pike wrote that stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Kernighan once wrote that the most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
Re: JavaScript debuggers are broken
#59But what did the author expect, when using a programming language that is not JavaScript, that the JS debugger would show code in that language instead? Maybe the framework needs to compile to JS that looks closer to the code you typed then (or else have its own debugger for its language). That's not the JS debugger's fault but the framework.
Disclaimer: I didn't read past the part where it showed React code and then showed that the debugger stops in different looking Javascript code instead
Re: JavaScript debuggers are broken
#60It's not the debugger that is broken, it's the entire JS ecosystem. It's such a terrible language we spent the last 2 decades fixing its warts, adding one layer on top of the other. And now you have es7 + typescript + jsx + some magic introspection + code splitting + weird non standard imports, all that turned into regular JS and source maps, in a complex concurrent and async env that deals with graphics AND the netw…