Live data from Hacker News

JavaScript debuggers are broken

samdesota.com

51–60 of 124 posts

Re: JavaScript debuggers are broken

#52
Given that:

There 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

#53

Brian 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 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

#54

Brian 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…

True, I am big fan of them but there are some legitimate cases where a debugger is so practical.

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

#55
post #39

Brian 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".

Now that you brought it up this way, I realized that I rarely step through the code. Instead I use break points + inspect like I would a print statement.

I find this a much more efficient workflow.

Re: JavaScript debuggers are broken

#56
It'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 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

#57
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.

Re: JavaScript debuggers are broken

#58

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

I agree. And isn't programming about automation and repeatability? A debugger session is manual and one-off. Early in my career I spend a lot more time in debuggers. Now I go months without using a debugger.

Re: JavaScript debuggers are broken

#59
I think JavaScript debuggers in browsers are AMAZING, it is fantastic to have such powerful programming tools on almost every computer! Just like BASIC in DOS computers and similar computers from that era, this is a programming language available by default almost everywhere. And the debugger tools are powerful too with inspecting and changing variables, ...

But 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

#60

It'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…

The problems you describe are in most languages. Networking and graphics are quite easy in JavaScript. Nothing fancy or complex about that. Debuggers are super light weight. Build into most browsers. Async programming is just another way. Again nothing fancy and complex about it. You just need to understand it.
Post reply on HN