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

81–90 of 124 posts

Re: JavaScript debuggers are broken

#81

Post by Normal_gaussian »

plausibilities wrote: post #71
Normal_gaussian wrote: post #25

Earlier quoted context omitted.

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

if(x) { debugger }

Play with conditional watchpoints in gdb to understand why this does not make sense as a reply to the comment explaining why this is not a substitute.

Re: JavaScript debuggers are broken

#82

Post by ihuman »

sametmax wrote: post #77
z3t4 wrote: post #76

Earlier quoted context omitted.

Meanwhile vanilla JS is a pleasure to work with. Sure, you can't make a monkey write good JavaScript but you cant do that in any other language either.

Sure, the language without built in namespace, standardized imports, any stdlib but 4 ways to declare an untyped variable is a pleasure to use. I wish I could remove JS from the browsers and watch all the fanboys trying to pretend they still like it now that it doesn't have an accidental monopoly on the most popular platform in the world.

There's no need to be snarky towards the person you are replying to. Just because you don't like using plain Javascript, that doesn't mean others aren't allowed to, or that their feelings are worth less than yours.

Re: JavaScript debuggers are broken

#83

Post by ihuman »

tablethnuser wrote: post #78

I don't think the author knows the full set of features available in DevTools. Sourcemaps make the code look familiar. Blackboxing hides the framework stack. DevTools supports conditional breakpoints so in the article's example you could put a breakpoint in the onAddWidget line looking for widget.position.x < 0 or whatever. Voila. Reproduce the bug and you have a stack of your own code that you can inspect and find t…

The author is aware of source maps, and has had issues with them

> To add to our list of feedback for Javascript debuggers here’s a couple more frustrations you may be familiar with:

> Buggy source maps resulting from bundling and transpilation tools like Webpack and Babel that cause placing break points to be unreliable, and defined names declared undefined

Re: JavaScript debuggers are broken

#84

Post by seanmcdirmid »

Sawamara wrote: post #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 pa…

It is bad compared to more developed debugging experiences (Eg visual studio and C# or even eclipse and Java). It is better than nothing or GDB of course.

I personally think the Chrome debugger interface is horrible, but that is easily fixed by using Visual Studio Code instead. Even then, things feel off...but more like unpolished.

Re: JavaScript debuggers are broken

#85

Post by moogly »

I don't have huge problems stepping through code in browsers (source maps, async/await, blackboxing helps a lot), and when I do, I just resort to console.debug logging, but what I would like to know is why Firefox' source map support (at least when using Webpack) still is so terrible? And why is it OK in the Developer Edition of the browser? Why have two different implementations? Is Mozilla intentionally hobbling the regular edition of the browser to justify the existence of the Developer version (because other than the source map support, I don't see the point of the Developer version)?

And then people complain about developers only testing in Chrome, well...

Re: JavaScript debuggers are broken

#86

Post by sametmax »

ihuman wrote: post #82
sametmax wrote: post #77

Earlier quoted context omitted.

Sure, the language without built in namespace, standardized imports, any stdlib but 4 ways to declare an untyped variable is a pleasure to use. I wish I could remove JS from the browsers and watch all the fanboys trying to pretend they still like it now that it doesn't have an accidental monopoly on the most popular platform in the world.

There's no need to be snarky towards the person you are replying to. Just because you don't like using plain Javascript, that doesn't mean others aren't allowed to, or that their feelings are worth less than yours.

If somebody comes to a DIY expert forum and says it's a joy to use a rusty screw driver to hit a nail just because that's the only thing in his toolbox, that person is bound to get a few snarky comments.

Re: JavaScript debuggers are broken

#87

Post by ihuman »

sametmax wrote: post #86
ihuman wrote: post #82

Earlier quoted context omitted.

There's no need to be snarky towards the person you are replying to. Just because you don't like using plain Javascript, that doesn't mean others aren't allowed to, or that their feelings are worth less than yours.

If somebody comes to a DIY expert forum and says it's a joy to use a rusty screw driver to hit a nail just because that's the only thing in his toolbox, that person is bound to get a few snarky comments.

This isn’t that hypothetical forum. Here, just because someone has a controversial option, that doesn’t mean your allowed to be snarky towards them.

https://news.ycombinator.com/newsguidelines.html

> Be civil. Don't say things you wouldn't say face-to-face. Don't be snarky.

Re: JavaScript debuggers are broken

#88

Post by tonyarkles »

seanmcdirmid wrote: post #84
Sawamara wrote: post #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 pa…

It is bad compared to more developed debugging experiences (Eg visual studio and C# or even eclipse and Java). It is better than nothing or GDB of course. I personally think the Chrome debugger interface is horrible, but that is easily fixed by using Visual Studio Code instead. Even then, things feel off...but more like unpolished.

> GDB of course

Every time I end up using a GUI debugger, I end up disappointed. GDB has spoiled me. Best feature that GDB has, for me? The ability to script what happens when a breakpoint is hit. A recent example: I have a state machine on an embedded system that is somewhat timing dependent (delaying a couple milliseconds is fine, delaying >1 sec is not). I stuck a breakpoint on the entry point and told GDB to dump a state structure every time it hit and then automatically continue. I get output describing exactly which events are coming in and what the state is at each step. Magic!

This is relevant in JS land when you have a bunch of callbacks/promises/whatever. HTTP requests continue executing while you’re paused on a breakpoint, so debugging things like out-of-expected-order promise results gets really hard.

GDB is definitely a power tool and requires some learning to use it effectively, but don’t write it off just because of that.

Re: JavaScript debuggers are broken

#89

Post by woah »

tonyarkles wrote: post #88
seanmcdirmid wrote: post #84

Earlier quoted context omitted.

It is bad compared to more developed debugging experiences (Eg visual studio and C# or even eclipse and Java). It is better than nothing or GDB of course. I personally think the Chrome debugger interface is horrible, but that is easily fixed by using Visual Studio Code instead. Even then, things feel off...but more like unpolished.

> GDB of course Every time I end up using a GUI debugger, I end up disappointed. GDB has spoiled me. Best feature that GDB has, for me? The ability to script what happens when a breakpoint is hit. A recent example: I have a state machine on an embedded system that is somewhat timing dependent (delaying a couple milliseconds is fine, delaying >1 sec is not). I stuck a breakpoint on the entry point and told GDB to dump…

You could just write that code temporarily inline

Re: JavaScript debuggers are broken

#90

Post by yebyen »

localhostdotdev wrote: post #47

s/Javascript/React (e.g. debugging works fine with stimulus/coffeescript for instance)

You're not wrong, as far as I can tell.

I'm a rails dev who has some godawful vanilla JS and JQuery in my legacy apps, that I maintain to some extent. We've largely avoided the quagmire of component-ized frameworks like React, Vue, keeping our JS footprint as minimal as possible while other teams in our area have moved ahead timidly, doing Vue without TypeScript or any build tools.

The one place where I have started moving my ball ahead is by adding Stimulus. It coaxes me toward Object-oriented (or at least Controller-oriented) JavaScript with ES6 classes. It has been a major success story for our small dev group which doesn't have the capacity to go crazy with a new language or framework, after deciding on Ruby+Rails some time ago. We can use it without major upheaval, it works with our legacy apps too without build tools, without much icky feeling, and without even webpack, just plain asset pipeline, while our internal-only application customer base is able to guarantee we are serving pages to a baseline of "current supported version of Chrome" that has given us the guarantee of needed support for ES6 and no concern about legacy browser support.

And one problem I also don't have, is any issue with the JS debugging support that is provided natively in Chrome, plain and simply put. I just write a "debugger" statement where it is needed in the code, ensure I have the JS console open when it reaches that line of code, and my debugging environment is roughly as powerful as pry-rails, no problem.

Post reply on HN