Seeking Good DHTML Debuggers?

christodd queries: "After years of programming in PHP and C++, I've finally delved into the world of Javascript and DHTML. The biggest hurdle I have come up against is the various web browser DOMs. I find that I spend much time googling for variable names, and guessing which variables do what. My favorite tool is a good debugger, and this is where I'm having problems. There is a commercial product by Netscript due out this quarter for $190.00, and there is a very young open source project at BiteSizeInc, but I have yet to find anything production quality. How does everyone else debug browser DOM issues?"

Comments

Venkman

[TulioSerpio]

Mozilla and Firebird come whith a Javascript debugger, and it works.

Re:Venkman

[AKAImBatman]

Simple. Mozilla and IE are compatible. I've been doing JavaScript for both of them, and when something goes wrong in IE, there's no good way to figure it out. So I launch Mozilla, bring up Venkman, and find the error lickety-split. Way better than IE's debugger with its imaginary line numbers.

Re:Venkman

[Goyuix]

For IE, I have found the Microsoft Web Developer Accessories a great help - especially if I can't remember document.form1.....

They are said to only work with version 5, but I have had no ill effects of using them with IE6.

And lastly, I don't think there is any one single tool that will do all the DHTML goodness you need (particularly if you are trying to validate it against multiple browsers). While you can separate DHTML out into JavaScript, the DOM, etc... each one really needs a separate tool to deal with it properly. No reason there couldn't be one good tool, just I have yet to see any I like as much as the few I use regularly.

How about Mozilla DOMI

[alanjstr]

The Mozilla Document Object Model Inspector is very useful. It comes with Mozilla and Firebird.

http://www.mozilla.org/projects/inspector/

Moz has got you covered!

[seanmeister]

In addition to the Venkman JS debugger mentioned in a previous comment, Mozilla and Mozilla Firebird also include an excellent DOM inspector - very handy for page tweaking, "DHTML" or not.

You already have the tools

[polyp2000]

My advice to you, is dont use Javascript , DHTML unless it is really neccesary. Its good for image rollovers and validating forms but the moment you try and do anything fancy with it like manipulating layers you will be plagued by crossbrowser incompatibilities.Generally speaking most of the dynamic content driven things can be done with your existing PHP / backend code.

I have been developing websites for a number of years, and when I do have problems i have usually found that by typing "javascript:" into the offending browser (after an error has occurred) and / or stepping through the code and evalutating variables using the javascript command

alert(insert_problem_variable);

has been able to help me debug frustrating problems most every time. I really dont think you need to fork out hundreds of dollars for a debugger when you just need to use your nonce and a copy of the best javascript book ever written

Re:You already have the tools

[Jerk City Troll]

Its good for image rollovers and validating forms but the moment you try and do anything fancy with it like manipulating layers you will be plagued by crossbrowser incompatibilities.

No, no, NO!

First of all, do not use JavaScript for image rollovers. It's a terrible idea and the person who thought of using JavaScript for image rollovers should be shot. You never put images in webpages where the image is not the content. That's presentational HTML. Instead, follow this example which uses pure CSS. The basic idea is that you use the :hover pseudo-class to change the background property of a hyperlink. That background image can contain all states or it can be separate files. Wrap the inner text with a span tag and specify that span tags within the scope of your anchor tag get a display: none propety. Its so simple, it works without JavaScript, loads faster, cross-browser compatible, and if the user is running a non-graphical browser, it's still accessible. Here's a quick example (where somepic.png contains both roll over states, one at (0, 0) and the other at (0, 20):

a.Foo {
display: block;
width: 100;
height: 20;
background: url("somepic.png") top left no-repeat;
}

a.Foo:hover {
background-position: -20px;
}

a.Foo span {
display: none;
}

Then in your markup, you put this:

<a href="foo.html" class="Foo"><span>link to foo</span></a>

Next, you should never rely on JavaScript to do your form validation. That's the most stupid, absurd thing I've ever heard. Leaving input validation in the hands of the client is to trust the user to not attempt to screw up your input. For forms to the useful, they have to be submitted to some kind of server-side logic. That is where the form validation should take place because then the user cannot side-step your input validation.

Yikes. With people like you building websites, no wonder the Web is such a disaster today. Please change professions ASAP or read Designing With Web Standards

Re:You already have the tools

[edwdig]

First of all, do not use JavaScript for image rollovers. It's a terrible idea and the person who thought of using JavaScript for image rollovers should be shot.

JavaScript was pretty much invented for things like that. JavaScript first showed up in Netscape 2.0, but CSS didn't show up until the 4.0 browsers.

Relying on CSS isn't always the best idea - IE does a terrible job of handling it. When I do web development, most of my time gets spent trying to work around limitations of IE. Very simple CSS works in IE, but anything even somewhat complex probably won't work right in it.

Next, you should never rely on JavaScript to do your form validation.

Yes, completely relying on JavaScript for form validation is a very stupid thing to do. But that doesn't mean you can't do initial validation with it. If you click Submit on a form, and a JavaScript alert pops up to tell you that you have to enter your phone number, it's a lot nicer than if you get the error after the page submits.

Re:You already have the tools

[mr3038]

Its so simple, it works without JavaScript, loads faster, cross-browser compatible, and if the user is running a non-graphical browser, it's still accessible. Here's a quick example (where somepic.png contains both roll over states, one at (0, 0) and the other at (0, 20):

a.Foo {
display: block;
width: 100;
height: 20;
background: url("somepic.png") top left no-repeat;
}

If you start throwing out examples, it would be nice to check that those work. You've a mistake there as "width:100;" or "height:20;" mean nothing. You have to define the unit unless the value you're trying to set is zero. Yep, they work in MSIE, but when did that browser knew anything about the standards? The correct format is width: 100px and height: 20px .

After saying that, yes, for simple roll-overs and cascading menus, the CSS is much better choice than javascript. Javascript should be used when the functionality required is much more complex.

Re:You already have the tools

[lscoughlin]

This isn't a 1 vs the other value proposition.

1. The validation continues in the flow of the process.

and validation will continue in the flow of the process anyway. You use javascript to prevent a server roundtrip if possible and do the server side validation anyway.

2. It calls out specific issues explicitly, in line with the field.

Javascript can to, and server side script can fail to do this. This is a design/implementation issue.

3. The other method doesn't work with ECMAScript disabled.

Irrelevent. You're using validation on both ends. Where is this hardon against javascript you seem to have acquired come from anyway?

-T

Don't bother

[craigmarshall]

Javascript and DHTML are the worst technologies I know of.

Stick with HTML/XHTML and CSS. You have PHP, what more could you possibly want? It's better to create web content that is accessible by everyone, than to produce fancy schmancy stuff that only a few people can access, and even fewer will appreciate. I hate Javascript and all other "dynamic" happenings in my browser. Focus on your content.

Craig

Re:Don't bother

[Jerk City Troll]

I second this.

There is no better way to create a more useless website to more people. You might as well just close your site now since you're limiting it to as few people as possible.

If you're even thinking about DHTML, you probably aren't up to par with the latest web technologies that are designed to be more accessible and progressive. Please stop what you are doing and read Designing With Web Standards before you even think about building a website.

Chances are, there is no need for any JavaScript on your website. It only adds needless complexity and helps things break. Again, as the parent poster write, use XHTML and CSS.

Re:Don't bother

[elemental23]

If you're even thinking about DHTML, you probably aren't up to par with the latest web technologies that are designed to be more accessible and progressive. Please stop what you are doing and read Designing With Web Standards before you even think about building a website.

DHTML (really just the combination of HTML, CSS, ECMAScript, and DOM) is the "latest web technology". I'm not sure what you mean by "progressive" in this context, but well-written DHTML can be just as accessible as as well-written vanilla HTML. Please note my use of the words "well-written"; crappy code is crappy code, no matter what technologies you're using. The key is to make sure things degrade gracefully, so that your content or application is still usable in older or non-standard compliant browsers.

Also note that Jeffrey Zeldman, the author of the book you recommend, uses JavaScript on his own web sites, including the very page you link to.

If you are forced to use the MSIE ...

[Tux2000]

... there still is hope. Venkman won't run in IE, but you can get something like Venkman:

To debug Javascript in Internet Explorer with more than just a few alert() statements, you need to install the MS Script debugger. It has two versions, one for NT/2000/XP and one for 9x/ME. There is even a KB entry describing how to find the Debugger in the jungle of microsoft.com: KBID 268445.

Just my 2 cents.

Tux2000

Re:alert() ... it's your best friend

[seanmeister]

alert() *is* pretty handy for JS debugging, but these bookmarklets make it even more...um... handier.

Well...

[JMZero]

Since you didn't mention it, everyone should at least let you know it exists: MS Visual Interdev has a script debugger.

It isn't a magically good debugger (like some MS debuggers really are) but it works OK. It also benefits from integration with IE (ie, when Explorer encounters a script error, it can sometimes jump right to the debugger).

It also does the IntelliSense thing (to an extent) allowing you to reference styles and objects without remembering their (often silly) names.

DHTML Programming

[DamnYouIAmALion]

I've spent several years writing various bits of functionality in JavaScript for clients. It is the worst platform to code for I've seen in some time.

I've tried some of the debuggers, and found them to not be very useful at all.

Sadly, you can't beat 'doing it the old way' using either alerts (useful as they're blocking) or setting up a debug layer (div) to output your debug content to.

It sounds more like you're looking for a reference than anything else. I'd highly recommend the DHTML Definitive Reference. It covers everything, along with good structural tips, like creating a platform independent DHTML API.

For those of you that suggested just using XHTML and CSS.. that tends not to be an option in the real world. You would be amazed at how many Companies use version 4 browsers. And anything on the Mac is just a nightmare.

Hope this helps.

Re:DHTML Programming

[swdunlop]

And anything on the Mac is just a nightmare.

Nope. Firebird's a little sluggish, but quite stable. Safari, which is packaged in these days, is nimble and does well on standards compliance and compatibility with old IE goofs for bad programmers.

Biggest problem Mac users have these days are websites that try to outguess the client by header-sniffing.

Dive into Mozilla

[akweboa164]

I would recommend diving into the world of Mozilla. They offer a couple of awesome tools for Javascript and DOM debugging. Check out the following: Venkman Javascript Debugger DOM Inspector Mozilla Firebird Specifically with Firebird, after you have it installed, go check out some of the available extensions at texurizer.net/firebird/extensions and download some of the cool extensions like the 'Web Developers Toolbar'. These pieces of software have proved invaluable to my productivity! I have used them to debug javascript, XUL and everything in between. Good luck!

Re:Not true. Care to share what you're smoking?

[Jerk City Troll]

Jerk City Troll, you are so abrasive. There really are much better ways to make your point. It's so unpleasant to read anything you post.

This comes from years of pent-up frustration from working with people who don't understand why this stuff is important. What's worse is reading people making suggestions to learners that will no doubt perpetuate bad web development practices. It's often been a difficult up-hill battle where people refuse to even try the standards-compliant, structural-markup approach. Nevertheless, I've proven the virtues of standards-compliance time after time again.

Most recently, my company was slating a lot of time to make an alternate theme and printer-friendly pages for a web application. I convinced them to let me redo the site in XHTML and I was able to deliver any theme they wanted in less than half a day creating new stylesheets. With benefits like these, I just cringe at other approaches.

But yes, I need to learn to be less pissy. :) (Sorry to everyone who I've spit venom at today.)

Re: Trust the Standard.

[E_elven]

>Technologies like JavaScript + CSS (=DHTML) are STANDARDS - they are created to use in web browsers. I use them wherever I need to, and code for MSIE and NS6+ (with a focis on the latest Mozilla release).

Interesting contradiction.

I say: do not find out what browser does what; find out what the respective standards say, and code according to that. Someone's browser will display it wrong, but that's mitigated by including the following disclaimer: "Your browser does not fully support the existing website standards, and you may suffer problems on other sites as well. You may continue to viewing the site, or you can download a standard browser here."

If more webdevs understood that, we wouldn't even have to have this discussion.

.

Re:Not true. Care to share what you're smoking?

[arkanes]

The fact that you rant without listening to what other people are saying (see your previous rant against roll overs for an excellent example, because you jumped on a high horse without thinking the problem through) also rather detracts from you point.

Not to mention that XHTML isn't some magic potion that'll make your site work properly. CSS and stylesheets are great for that sort of thing, but the various cross browser issues force all sorts of hackery that reminds me a great deal of the stupid crap we did to work around bugs in table rendering in the 90s (@import to "hide" from old browsers? Bah). At the sites that oh-so-helpfully explain these tricks sound so proud, as they talk about the advantages of web standards.

Yes, I know that using tables for layout is evil. Of course, theres a variety of layouts that CSS is simply incapable of, and the cross-platfrom CSS you need to properly implement even some relatively simple layouts is far larger than the comparable table code, and it'll work (not even degrade to simple text, but actually WORK) on non-CSS compliant browsers, and it'll render faster (and often in a more user-friendly manner) than the CSS...

I use CSS alot for effects and styling. It's really handy for some layout stuff (like a static menu). It's makes a great addition to a table based layout, where you used to have to play games with single pixel cells and whatnot. But it's a nightmare for overall layout. Call me when CSS 3 is finalized and has at least 80% support in all major browsers.

Not really a debugger, but ...

[swelling]

One of the things that saved my sanity when doing a DHTML UI was creating a log window that I could write messages, the contents of JS variables, DOM objects, etc. to. It isn't as good as a real debugger, but it helped out quite a bit. I created a JS class that supported two methods:

log = new Log();
log.log("blah");
log.dump(someObject);

The first method just prints out the specified message, the second recursively prints all of the attributes an object, since in JS they are really just hashes that you can traverse automatically with a for in in x loop. At least in IE, this let me inspect form elements, etc. as if they were native JS things. The log class could technically be a singleton, but since each instance writes to the same window, it really doesn't matter. I just instantiate a new Log object at the top of each document, and can then enable/disable it at will by typing a javascript:log.enable() command in the address bar.


function Log() {
}

Log.prototype.enabled = false;

Log.prototype.enable = function() {
this.enabled = true;
this.logWindow = window.open("", "Log", "width=80,height=25,resizable,scrollbars=yes");
this.logWindow.document.open("text/plain");
this.logWindow.blur();
}

Log.prototype.disable = function() {
this.enabled = false;
this.logWindow.close();
}

Log.prototype.log = function(msg) {
if (this.enabled) {
this.logWindow.document.writeln(msg);
}
}

Log.prototype.dump = function() {
if (this.enabled) { // etc
}
}



This is detailed in the O'Reilly Rhino Javascript book, which is an excellent resource for JS programming and DHTML.

Re: Trust the Standard.

[E_elven]

The inference was that if everyone wrote standards-compliant code, then the BROWSERS WOULD HAVE TO DISPLAY IT! Better sites and less buggy browsers. Geez.