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

11–20 of 124 posts

Re: JavaScript debuggers are broken

#11

Post by kristopolous »

I made a fairly interesting JS introspection tool about 8 years ago ... I used to use it all the time: https://github.com/kristopolous/_inject

The idea is that you want to run arbitrary code at some random deep scope in the code or perhaps run some map/reduce/filter function over every time it goes in there and find the anomaly ... it was really useful in characterizing things like itemizing a frequency of failure and other things I guess I stopped dealing with.

I think it can be expanded upon but never really seemed to go anywhere. (sorry if the code walk-through article doesn't work well on mobile and is not complete - I never finished it)

Re: JavaScript debuggers are broken

#12

Post by wongarsu »

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.

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.

Re: JavaScript debuggers are broken

#13

Post by jypepin »

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 compare this to my experience with Ruby, Python, Go and Elixir, and all those languages have either a great debugger or an alternative that makes debugging much easier than going through a "guess based feedback cycles" with JS.

Re: JavaScript debuggers are broken

#14

Post by ehnto »

kristopolous wrote: post #9
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.

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 to ES5, packed into a module loader and flung around asyncronously.

JS debugging is fine in native, dependency free code I write. My sense is that debugging was something a lot of newer developers found out about later in their education and as such they never noticed debuggability and tooling wasn't up to par with older tooling.

Re: JavaScript debuggers are broken

#15

Post by z3t4 »

wongarsu wrote: post #12
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.

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.

Re: JavaScript debuggers are broken

#16

Post by z3t4 »

Normal_gaussian wrote: post #5

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

Re: JavaScript debuggers are broken

#17

Post by robin_reala »

tomsmeding wrote: post #7

Notable 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

Record and replay is coming to Mozilla’s JS debugger engine: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...

Re: JavaScript debuggers are broken

#18

Post by black-alert »

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 browsers 'debug' tool, tried it once and got bored already..

IMAO the code I'm working on should live inside my head, that's the place where I construct and debug. Even when I'm new on a +100Kloc project, I'd still prefer to read through the code and figure out what's actually going on.

I see so many developers in the JS world spending soo much time and focus on all those tools; types, eslint, debuggers, testing, etc.. it makes me really suspicious about whether they have the actual skill to write a good codebase. I can only be convinced when my code would be buggy and theirs flawless, but I never see that, it's for some reason always the other way around! Just take a look at this project (a random pick) with all those (virtual) safeguards, result: over 3600 issues!!! https://github.com/Microsoft/TypeScript

I mean 3600+ issues, WTF!! And I should be using this tool to prevent issues in my software? Sometimes it feels like this entire industry is broken.

Re: JavaScript debuggers are broken

#19

Post by z3t4 »

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 otherwise no cost to having extra info available in the dev console, besides Firefox debugger being terrible slow 100x slower then the Chrome console.

Re: JavaScript debuggers are broken

#20

Post by Jach »

saagarjha wrote: post #4

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

"Interpreted" is probably the wrong word, "interactive" would be my choice. But I think I agree with your overall point, that when you have a high level of interactivity, you don't need to rely as much on automated debuggers which is why you see them missing or barely mentioned -- at least if you are making use of such interactivity and aren't just trying to write code the same way you would older Java. I've done a lot of Python without ever feeling a need for pdb, and didn't even learn about its existence until quite a bit later in my Python studies, but doing C and C++ necessitated learning about gdb (and valgrind) very early on. For Java, it's a mixed bag for me -- I can get by fine with pure reason (and some logging and test code) and vim up until a certain project size or contributing coders size threshold is reached.

Meanwhile you have old dogs like Lisp that newer languages supposedly cribbed a lot from, yet these newer languages have all seemed to miss things like having what we think of as IDE features built into the language spec itself. The Lisp standard requires built-ins like 'COMPILE, 'DISASSEMBLE, 'BREAK, 'STEP, 'TRACE, 'INSPECT, 'INVOKE-DEBUGGER that end users can use on their own or as building blocks for more sophisticated tools (like Slime -- https://malisper.me/debugging-lisp-part-1-recompilation/) and implementation-defined extensions. I appreciate the advances browsers have made in dev tools (Firebug was a godsend) but it's still rather primitive compared to languages where debugging has long been a staple or was even defined as part of the language...

Post reply on HN