Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript debuggers are broken

samdesota.com

Post reply on HN
Print view View original

31–40 of 124 posts

Re: JavaScript debuggers are broken

#31

Post by jypepin »

tokyodude wrote: post #29
jypepin wrote: post #13

Javascript is the only language I've worked with that doesn't offer a good debugger/breakpoint system, and I agree with the reasons/issues stated in this article. It makes working with JS (and Node) a real pain in the butt. IDEs such as VSCode offer integrated debuggers etc. and I wonder if anyone ever was able to use it for anything more than a few lines of vanilla JS. I can't seem to understand how those would work…

I guess I must not know what I'm missing. I've used Visual Studio for 15 years. gdb for 10. I have zero issues using the Chrome's debugger. I don't no what's different about the breakpoints in Chrome. The seem to offer the same features.

Well my main issue is that most of the time when I put a breakpoint somewhere it just doesn't work, or if it works it's pretty much impossible to move forward or backward from line to line because, as stated in OP's article, going to next line in a React app for example, you end up in the actual React implementation code instead of being able to separate framework and written code.

To me, that makes it pretty much unusable enough that I just don't try to use anymore.

Re: JavaScript debuggers are broken

#32

Post by 1337shadow »

black-alert wrote: post #18

When I first learned to code in TurboC some 30 years ago I used the IDE's step debugger for a while. Although a great tool for learning how your code executes line after line, I stopped using it after a short while because I found it to tedious and distracting to go through the code this way. Being able to set a breakpoint and see the actual value of something I can do in an instant with logging. I never use the brow…

Hopefully there are many brilliant alternatives to TypeScript, eg. Reason, PureScript, Elm.

Re: JavaScript debuggers are broken

#33

Post by quickthrower2 »

tobyhinloopen wrote: post #2

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.

Yep, unfortunately you have to consider any NPM (or whatever) libraries as your code, your responsibility & your problem. You might need to get/build source maps for those and debug them to see why it is falling over.

Re: JavaScript debuggers are broken

#34

Post by perfunctory »

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.

Re: JavaScript debuggers are broken

#35

Post by agumonkey »

perfunctory wrote: post #34

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's odd that debuggers aren't helpful.. aiding in problem space reduction should yield improvements, but maybe depth first tracing is not the right tool here

Re: JavaScript debuggers are broken

#36

Post by etatoby »

kristopolous wrote: post #24
ehnto wrote: post #14

Earlier quoted context omitted.

PHP debugging is fine. Conditional breakpoints, walking up the stack trace, interactive and in-place code execution at run-time meaning I can run code or change variables and it applies to the current execution. It's great. Javascript is a nightmare to debug, but it's probably just as much to do with architecture than debugging tools. Of course it's hard to debug a dozen tiny libraries written in ES6, transpiled down…

Python and perl are good too. I've heard marvelous things about emacs consistent uniform debugging interface that takes care of the magic behind the scenes. In so much as my friend just gets debugging as a built-in feature when he transits around languages without any knowledge of the underlying invocation and implementation nuances. He has the same keystrokes and interface in all the common languages. It sounds magn…

I found it extremely hard to learn Emacs and memorize all the keystrokes. They made no sense. After some time I gave up. Learning Vim was a breeze compared to it.

Re: JavaScript debuggers are broken

#37

Post by goto11 »

tty2300 wrote: post #22
z3t4 wrote: post #19

I remember IE5-6 ? Where it only told you there was an error, and you had to figure out where yourself via alert("this is line 500") Being used to that I think Chrome dev tools are amazing. I love that you get a call stack on every console.warn. All those console.log's can be removed in production via overloading or marking them as pure functions when minifying, as they will otherwise slow down the app. There's other…

I wonder if this is the reason that js tends to fail silently or convert types whenever possible because debugging errors was just too hard.

This was Netscapes design. I would guess it was designed like that because it was the simplest way to handle error conditions. Initially JavaScript was very simple and didn't even have exception, so there was no way to report errors.

Re: JavaScript debuggers are broken

#38

Post by etatoby »

black-alert wrote: post #18

When I first learned to code in TurboC some 30 years ago I used the IDE's step debugger for a while. Although a great tool for learning how your code executes line after line, I stopped using it after a short while because I found it to tedious and distracting to go through the code this way. Being able to set a breakpoint and see the actual value of something I can do in an instant with logging. I never use the brow…

I agree.

Some “safeguards,” eminently type systems (with algebraic types and inference if possible) I've slowly come to value a lot, especially when maintaining a codebase for an extended period of time.

But otherwise, I still prefer to reason over my code, with the aid of at most a few debug prints / logs. Breakpoints I only use very rarely. Other debugger features not at all.

But I remember it taking many years before I could build a complete working picture of the code I was writing (or reading) in my head. Before that, I was basically horsing around. Thankfully, that was around high school time. By the time I got into the industry, I already had that skill finely developed.

Nowadays, I don't think many fresh graduates have it, and yet the industry prefers hiring them, rather than more experienced (older) people. Go figure.

Re: JavaScript debuggers are broken

#39

Post by goto11 »

perfunctory wrote: post #34

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

Post reply on HN