Live data from Hacker News

JavaScript debuggers are broken

samdesota.com

21–30 of 124 posts

Re: JavaScript debuggers are broken

#21
post #15

Earlier quoted context omitted.

Stack traces for async code are always borderline useless in Javascript. Instead of telling me who called the offending code it just informs me that the code is executed by an scheduler in the event loop.

You create the error before doing the async operation, then throw/callback that error with additional info from the async error.

That sounds tedious in a web server where like half the functions are async. Also why is that my responsibility? A stack trace is supposed to show the call chain, not language implementation details. At a minimum `async x()` should just be equivalent to `try { async x() } catch(err) { throw new Error(err) }` (with the logger printing all nested exceptions)

Re: JavaScript debuggers are broken

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

Re: JavaScript debuggers are broken

#23
post #15

Earlier quoted context omitted.

You create the error before doing the async operation, then throw/callback that error with additional info from the async error.

That sounds tedious in a web server where like half the functions are async. Also why is that my responsibility? A stack trace is supposed to show the call chain, not language implementation details. At a minimum `async x()` should just be equivalent to `try { async x() } catch(err) { throw new Error(err) }` (with the logger printing all nested exceptions)

Most of the time you will get the correct call chain, so you only have to do this rarely.

Re: JavaScript debuggers are broken

#24
post #14

Earlier quoted context omitted.

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.

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 magnificent. One day I hope to actually take the time to learn it.

Re: JavaScript debuggers are broken

#25
post #16

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

if(x) throw x

The reason this doesn't work in the same way is because it requires you to know where the error occurs.

You tend to operate on a data structure and know that at some point x becomes y. By placing a watch on x you find out where that point is.

Editing the code does not get you this (bar modern proxies in js).

Re: JavaScript debuggers are broken

#26
post #22
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.

I think Microsoft just didnt want you to develop in JS, but they where forced to support it.

Re: JavaScript debuggers are broken

#27
Money shot: "In my next post I want to take a step back and imagine programming nirvana… what if we could design a better debugger? I’ll be talking about the work me and my team at Raft have been doing to build a new type of debugger and experimental programming experience for building reactive GUI applications, without the mess."

Re: JavaScript debuggers are broken

#29
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.
Post reply on HN