breakpoint debugging in javascript -- state of the art

[Morgan Packard]

Hello,

Wondering what everyone's experience with breakpoint debugging is
here. I've been using firebug for a few years and, while I'm delighted
to have _some_ debugging ability, I've found it to be very fussy,
difficult to know when it's going to work or not. I'm curious how
others approach debugging, and if anyone here feels they are able to
use a breakpoint debugger reliably.

thanks,

-Morgan

 

[Laser Lips]

Hello,

Wondering what everyone's experience with breakpoint debugging is
here. I've been using firebug for a few years and, while I'm delighted
to have _some_ debugging ability, I've found it to be very fussy,
difficult to know when it's going to work or not. I'm curious how
others approach debugging, and if anyone here feels they are able to
use a breakpoint debugger reliably.

thanks,

-Morgan

If I need lots of output to debug I make a floating div on the page
and add output to it, like a terminal window.
Otherwise it's just the good old fashioned alert.
I've never used firebug in my life and don't intend to.
http://cylo.co.uk

 

[Stevo]

Hello,

Wondering what everyone's experience with breakpoint debugging is
here. I've been using firebug for a few years and, while I'm delighted
to have _some_ debugging ability, I've found it to be very fussy,
difficult to know when it's going to work or not. I'm curious how
others approach debugging, and if anyone here feels they are able to
use a breakpoint debugger reliably.
thanks,
-Morgan

I completely agree on Firebug's unreliable approach to breakpointing.
It's completely random whether it will work or not. You can't tell them
(on their google forum) about anything like that though. They get all
defensive and attack you for casting doubt on their great tool. It's at
least an improvement on the worst debugging tool ever invented - Venkman.

I find that Microsoft Visual Studio is the only reliable debugger. If
you set a breakpoint, you're 99% sure that it will stop if that line of
code is executed. The 1% doubt is for code that's conditionally loaded
into scope and VS can be unsure. It's mostly good though. I use the 2003
..NET version. It can even let you set breakpoints in code that was
brought into existence via an eval statement (which Firebug can't do).

Neither of them let's you debug code that was created dynamically in the
parent page from a createElement from inside an iframe though. If any of
that code has an error, you get things like Error on line 21489513.

Aptana is a plugin which I believe lets you debug JS in Eclipse. I tried
it once but gave up after a short time. I should have put the time in to
get it working but never did.

 

[Stevo]

I've never used firebug in my life and don't intend to.

Why? You don't like making your job easier?

 

[Gregor Kofler]

Stevo meinte:

I completely agree on Firebug's unreliable approach to breakpointing.
It's completely random whether it will work or not. You can't tell them
(on their google forum) about anything like that though. They get all
defensive and attack you for casting doubt on their great tool. It's at
least an improvement on the worst debugging tool ever invented - Venkman.

Firebug is - IMO - still the most "direct" tool for debugging. Apart
from the breakpoints you still have console.log...

I find that Microsoft Visual Studio is the only reliable debugger. If
you set a breakpoint, you're 99% sure that it will stop if that line of
code is executed. The 1% doubt is for code that's conditionally loaded
into scope and VS can be unsure. It's mostly good though. I use the 2003
.NET version. It can even let you set breakpoints in code that was
brought into existence via an eval statement (which Firebug can't do).

I found Opera's Dragonfly more reliable with breakpoints, but haven't
used it too much, yet.

Gregor

 

[Laser Lips]

Why? You don't like making your job easier?

Just never had the need to use it. I can do all my debugging without
it. Firebug has'nt always been arround, alerting was the only way to
see data at certain points in the code, AND can actually act as a
break point to a certain degree because while an alert is active,
javascript code stops.

Why do you feel the need to use it?

 

[Thomas 'PointedEars' Lahn]

Wondering what everyone's experience with breakpoint debugging is
here. I've been using firebug for a few years and, while I'm delighted
to have _some_ debugging ability, I've found it to be very fussy,
difficult to know when it's going to work or not. I'm curious how
others approach debugging, and if anyone here feels they are able to
use a breakpoint debugger reliably.

I found breakpoints for client-side scripts (along with those for the
corresponding server-side script) quite useful when debugging a virtually
undocumented XHR-based Web application a while ago. I used Firebug < 1.2 at
that time (IIRC 1.0.x), when there was no indication yet as to at which
lines execution could be suspended. Firebug 1.2.x now marks the
corresponding line numbers with green foreground color here, and I would say
debugging works reliable for me then. (Still, I had hoped that Joe
implemented my suggestion of setting the breakpoint on the next available
line instead.) If you need more than simple debuggign, you can install
Venkman, the original JavaScript debugger on which Firebug's debugger is based.

Of course, it is a PITA to debug minified code (although Venkman can
pretty-print it). Which is one of several reasons why I strongly recommend
against minifying.


HTH

PointedEars