Seeking Good DHTML Debuggers? 103
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?"
Venkman (Score:5, Informative)
Re:Venkman (Score:2)
Re:Venkman (Score:1, Interesting)
Re:Venkman (Score:4, Insightful)
Re:Venkman (Score:2)
There is a free MS debugger, you'll have to search around for it though. I've had limited success with it, but at least it gives you a better idea of what the problem is than the standard IE errors.
Re:Venkman (Score:3, Informative)
For IE, I have found the Microsoft Web Developer Accessories [microsoft.com] 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 dea
How about Mozilla DOMI (Score:3, Informative)
http://www.mozilla.org/projects/inspector/ [mozilla.org]
Moz has got you covered! (Score:4, Informative)
You already have the tools (Score:2, Offtopic)
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
Re: Trust the Standard. (Score:3, Insightful)
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 websit
Re: Trust the Standard. (Score:2)
Web developers can't just close their eyes and say "I will only follow standards!" To think so is naiv
Re: Trust the Standard. (Score:3, Insightful)
Re: Trust the Standard. (Score:1)
The key is that a standard is only as good as the implementations of it.
Re: Trust the Standard. (Score:2)
Don't get me wrong, I understand the socio-economical factors here; I'm just saying that long-term, this would be a better choice.
Re:You already have the tools (Score:5, Informative)
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 [www.pixy.cz] 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):
Then in your markup, you put this:
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 [zeldman.com]
Re:You already have the tools (Score:5, Insightful)
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 (Score:2)
I always find a server-side solution more graceful for the following reasons:
Re:You already have the tools (Score:5, Insightful)
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:You already have the tools (Score:2)
Re:You already have the tools (Score:2)
The fact that the average web developer doesn't know how to write reliable, portable code is hardly an argument against the language that they don't know how to use.
We've used JS client-side validation to replace apps used by data-entry operators that have very demanding speed requirements. Without client-side va
Re:You already have the tools (Score:1, Redundant)
Maybe they actually stopped to think for a nanosecond and realised that some image rollovers and other animations may involve some logic depending on the state
of the page or one of its components. The last time I looked CSS wasn't much good on complex boolean logic. Unless you know better of course...
Re:You already have the tools (Score:2)
Right and wrong. You can/should use JS to provide feedback to the client if they entered something blaringly incorrect (ie, left the last name field blank, formatted a date wrong, etc). You should, however, *always* assume the input coming to your back end is fiddled with and trying to break your system, so still have all input checking on the backend as well. Client side input validation is good because it gives immediate response to
Re:You already have the tools (Score:2)
Re:You already have the tools (Score:2)
Please explain this. It's just stated, but i can't see it being a true statement. Please humor me provide some reasoning behind such a statement.
Removing ECMAScript-based validation would lighten the page for the same users.
By an amount that is idiotically negligable, especially in comparison to a server round trip.
It would be less likely to break for all users as well.
Superficially true. Well wri
Re:You already have the tools (Score:2)
A site with 10k of excess html (font tags and the like) and 5-15k of extra ECMA code tends to slow down lower end modems. So lightening the page by removing the above is step one.
If you can't rely on the javascript working 100% of the time, then why write it? The graceful degradation is then replaced with outright elimination, and you don't get caught with your pants down when some new (broken) browser hits the block and mucks up your code yet again.
Perhaps there is a misunderstanding about what I conside
Re:You already have the tools (Score:1)
why not just write plain text ascii pages, that way nothing can break?
almost every comment here specifically supports server side validation, yet you're saying "you suck, you're using ECMA in one form or another"... and you can write a reasonably complex validation script in less than 5k that can help people keep from being irritated because they EXPECT the form to have some kind of validation before it gets submitted..
Re:You already have the tools (Score:1)
It's bad to rely on JavaScript for form validation but it can be a good ide
Re:You already have the tools (Score:1)
The key word here is 'rely'. It's perfectly reasonable to allow the page to do simple first-pass checking of the content to avoid simple errors, like blank or incorrectly formatted data. You just need to ensure that (1) you re-validate at the server, (2) the form still submits if you don't have JS enabled (ie put validation code in the onSubmit event).
Re:You already have the tools (Score:2)
Re:You already have the tools (Score:5, Informative)
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 [meyerweb.com] and cascading menus [meyerweb.com], the CSS is much better choice than javascript. Javascript should be used when the functionality required is much more complex [michaelbystrom.com].
Re:You already have the tools (Score:1)
Written in haste. (Score:1)
Yes, you are correct that I fucked that up. I was in a rush. Awesome site btw, I love the design and the code. Little by little, well-built as well as well-designed sites are popping up. A couple years ago, you saw none of that.
You need to qualify that... (Score:2)
You should never rely on it, but you should always have it (if supported by the browser). Web pages that use only round trips for validation are horrible and often incomprehensible. It's just plain bad interface, and the alternative is simple, easy, and produces a far better result.
User clicks submit. You alert "You need to enter the donation amount" and set the focus to the appropriate field.
If you think it would be better to let th
Re:You already have the tools (Score:2)
It's convenient for the user (quicker response), keeps the load off the server (which will probably only receive the final valid data, still checks it though) and even saves a little bandwidth. Everyone wins!
Re:You already have the tools (Score:2)
As for the CSS example you are suggesting. I have one thing to say .
Re:You already have the tools (Score:2)
Interresting read, but is he color blind?
Don't bother (Score:4, Insightful)
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 (Score:5, Insightful)
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 [zeldman.com] 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.
Really? Try doing this in in XHTML & CSS. (Score:2)
Re:Really? Try doing this in in XHTML & CSS. (Score:1)
Re:Don't bother (Score:5, Insightful)
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:Don't bother (Score:1)
I try to use as much CSS and as little JavaScript in my sites as possible. However, chances are you will NEED to use Javascript on your site if you are doing anything more than basic CSS, if only to work around the abysmal CSS support in IE.
Re:Don't bother (Score:2)
I agree that using JavaScript to make a site more "fancy" is a waste of time and can lead to serious problems, but if you are writing a complex web application, JavaScrip
Re:Don't bother (Score:1)
So far as the variuos problems with the web app paradigm, that's another topic entirely...
Re:Don't bother (Score:1)
I once believed that Javascript was a toy language that was not worth the time. And once upon a time that was true. But times have changed. Today, Javascript is a suprisingly useful language.
My area of expertise is telework, or remotely hosted applications. I've been writing PHP/SQL databases for years, and the end result always feels like a web page, not a program. In order to make an web based application "feel" like an application, Javascript is the thing.
Take, for instance, Game Lib [javascript-games.org], a ja
If you are forced to use the MSIE ... (Score:5, Informative)
... 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 [microsoft.com].
Just my 2 cents.
Tux2000
Re:If you are forced to use the MSIE ... (Score:1, Informative)
Re:If you are forced to use the MSIE ... (Score:1)
Re:If you are forced to use the MSIE ... (Score:2)
alert() ... it's your best friend (Score:1)
the best way i found is to use the alert() javascript function for variable inspection.
on t
Re:alert() ... it's your best friend (Score:3, Interesting)
This is just bizarre... (Score:2)
Visual Studio came with Visual InterDev, which does a passable job with debugging. Even with its flaws, it has saved me a lot of time over the years.
Nobody needs a true debugger. Heck, nobody needs CVS. Nobody really needs profiling. Nobody needs a relational database.
I think, though, that the best programmers will take the time to "sharpen the saw" and become profi
Re:alert() ... it's your best friend (Score:1)
the line numbers in my editor don't match up with what's rendered in the browser
you can setup a good editor to help you to track all those errors. For instance (my setup):
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Default HTML Editor\shell\edit\command]@="D:\\wbin\\vim\\vim62\\gvim.exe %1"
The answer appears to be no (Score:1)
Web programming lacks decent debugging tools.
In my experience, we had browser hosted software, but it was targetted toward an intranet so we could specify the software that needed to be installed on both the clients and the servers. As the product became more complex and more developers were brought on, debugging became a nightmare.
Although less technical min
Re:The answer appears to be no (Score:1)
Re:The answer appears to be YES (Score:2)
I can write forms in
Re:The answer appears to be YES (Score:2)
Well... (Score:5, Informative)
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.
Critical problem (Score:2)
When you open the debugger, you're in trouble. The second you close it, all other IE windows close. _Very_ annoying and means it gets turned off on all developer boxes here.
(Hmm, must play more with Venkman and the DOM inspector to get more ammo for Moz with colleagues
Indeed... (Score:2)
It's got some other wierd things going on and has some trouble debugging some stuff, but it's still useful enough that I keep it around.
I suppose its usefulness would correlate pretty well with the size of the largest script you run. For most people creating public-oriented web pages, the largest script they write is going to be pretty small - and a
Re:Indeed... (Score:1)
I must be magic.
Re:Indeed... (Score:1)
Re:Critical problem (Score:2)
'detach for process' is supported in the VS.NET (7 & 2003) debuggers.
No problem (Score:2)
That's easily avoided. Before you close the debugger, go to the Debug menu and select "Detach All".
Detaching the debugger from a process leaves the process running. Stopping the debugger generally stops the process it's attached to. That's why when you close the debugger window, it asks if you want to stop debugging. Why it doesn't give you the option right there to detach all and then close is a mystery to me, since that's almost always what I want.
Re:Critical problem (Score:2)
Incidently, it's not ALL IE windows, just the ones that share the same root process (created via the "New Window..." menu or by opening links in a new menu).
Re:Critical problem (Score:2)
Re:Well... (Score:2)
But pretty good, nonetheless. Can attach to any IE process (think: Outlook)
DHTML Programming (Score:2, Informative)
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 Ref [oreilly.com]
Re:DHTML Programming (Score:3, Informative)
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.
Not true. Care to share what you're smoking? (Score:2)
Yes, I would be surprised. Do you have any statistics to back this up? And as for bad browsers on the Mac, what the fuck are you talking about? IE5, Safari, OmniWeb, and Mozilla (and derivatives) are all on the Mac and are all very standards compliant. OS X supports more browsers than a
Re:Not true. Care to share what you're smoking? (Score:3, Insightful)
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.
Re:Not true. Care to share what you're smoking? (Score:3, Interesting)
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
Re:Not true. Care to share what you're smoking? (Score:1)
Re:Not true. Care to share what you're smoking? (Score:1)
Any more, the schools that can afford the macs are doing so because they have a sys admin that wants macs around, and usually they're
Re:DHTML Programming (Score:1)
8th millionth post!!
Have a nice day!
MOD PARENT UP (Score:2)
Dive into Mozilla (Score:2, Informative)
I use Firebird, Venkman debugger and the (Score:2)
Safari (Score:2)
I assume other browsers have equivalents.
most people seem to lean towards.. (Score:2)
Here is what I have had problems with.
DIV -> they lay them out close but when you get into needing pixel precision, I have had problems. Try laying out 2 div's next to each other and adding borders 1px wide and use absolute layout. Set widths and heights and then view in both. arg!
IE has a bug when opening new windows. Session is gone, and so are your cookies. You ha
RDBMS style (Score:1)
Not really a debugger, but ... (Score:4, Informative)
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) {
}
}
This is detailed in the O'Reilly Rhino Javascript book, which is an excellent resource for JS programming and DHTML.
Simple, write your own .... err well for me anyway (Score:1)
It enumerates all the javascript objects it can find by using a call like "for i in x". I eventually got it opening in the search pane with a treeview that allows you to examine every value of every field you can find starting with window.opener.
Not sure if it will work in Mozilla, and it does need to be loaded from the same site.
Code available on request.
A handy thing for IE (Score:2)