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

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.

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

[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

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