The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

javascript rant

I've just found the answer to yet another arcane javascript error that kept me busy for about 2 days.  And this isn't the first time, nor the last.

I'm a competent developer (in java) and have recently got over the spring framework learning curve and can have applications that do something useful knocked up in a day no sweat.  But when I go to the gui layer on a web app, whether fancy display or ajax techniques, javascript cripples my productivity.

Don't get me wrong, im really interested in the Web2.0 stuff going on at the moment.  The trouble is I can't get my head over it's crazy browser error msgs.  Even in Firefox it nearly always points me in the wrong direction.

Anyone out there know of must-have javascript debug/development tools?  Sometimes I wish there was a javascript compiler/verifier out there that would run through my js files at build time and give meaningful error msgs...
entropy Send private email
Friday, October 27, 2006
First things first. JavaScript is a well founded and effective language desrving of respect from all developers. I am sure you will agree that it demands just a little time learning it's underlying power as well as it's simple syntax - if developers ignore this step and just treat the language as an unimportant element at the client end of an application then they are always going to be in trouble.

The ASP.NET/Windows folks have an advantage here in that debugging JavaScript is made a whole lot simpler by being able to step through scripts as they execute (inspecting variables as they go). Having said that I use the JSLint module as a Visual Studio "addin" to inspect my scripts before running them - this removes lots of syntactical bugs up front.

I have had recommended to me as a JavaScript IDE but I have not yet had a chance to evaluate it.
Mike Griffiths Send private email
Friday, October 27, 2006
I'll back up the previous statement about Javascript being a very good tool and a powerful language.

Wouldn't stop me being interested in something to help making debugging it easier.

Shifting from ASP to ASP,.NET i thought I'd be leaving Javasascript behind but I find that it is more important for ever.

Being able to dispence with postbacks by shifting tasks to the client males the users experience a lot less infuriating. One of my first apps had Postbacks to handle on the fly verification of a data entry form.

Sicne the site was remote it was slow as slow can be.

JAvascript on te client solved that.

Stick with it it is worth it.
Colin Send private email
Friday, October 27, 2006
Firebug is extremely useful for javascript debugging, simpler than Venkmann but does everything (I think) I need:

Secondly, spending time looking at the framework/libraries out there is probably worth while. I love Prototype.js (and scriptaculous) to bits, but Dojo, JQuery and YUI are all worth investigating to see how they can make things easier for you.
G Jones
Friday, October 27, 2006
I am looking at Prototype at the moment - I like the fact that you can use selected subsets of this library. Looks worth it just for the $() function.
Mike Griffiths Send private email
Friday, October 27, 2006
Thanks Mike et all, as I said I totally acknowledge js's usefullness.  It's just my productivity when working on the client side is woeful when compared with getting supposedly complex 'enterprise' elements in place on the server.  Infuriating!  Especially when it's tough to explain this stuff to management "yeah i've got transaction management, failover, business logic working..." but as soon as I attempt an explanation of javascript strife, everyone switches off...
entropy Send private email
Friday, October 27, 2006
For the record i've been using taconite and now mochikit.  Pretty certain im going to dump taconite (probably through no fault of itself, but I can't iron out my jscript errors when working with it), jump on several of mochikit's components and twist them into what I want.

One of the big worries I have about using libraries such as Prototype is interfering/vice versa with my own jscript code.
entropy Send private email
Friday, October 27, 2006
entropy, I''m almost afraid to admit this, but when I'm debugging javascript I use alert() extensively to display variable values. I can usually squash whatever bug's ailing the system. As another poster mentioned, ASP.NET has made it easy to step through client-side javascript, so should be a help.

If I can offer a website for you to look at, it's A (very) bright developer put together some tutorials on the ins and outs of javascript, particularly the Document Object Model and Event Model, both of which are very important in javascript. The nice things about his site are (1) his writing is clear, (2) it's concise, (3) he has working examples, and (4) he shows all of his code. It might be helpful.

Javascript is a powerful, full-fledged language in its own right. Trouble is, its one of the most poorly documented ones. For a more advanced look at the language, there are some very good articles at

Hope this helps.
Friday, October 27, 2006
I hate working with JavaScript too, but I attribute many of my fustrations to its... "at arm's length" nature. A good analogy is writing code for cell phones that can only be tested on a cell phone; there are a lot of fustrating hoops to jump through. Not to mention browser incompatibilities.

I agree that JavaScript is a solid, powerful language but I don't think it is a good solution for web development. There are just too many "accidental difficulties" (Joel's phrase) that require libraries and browser plug-ins to deal with.

For me, it feels like writing a Java program knowing that there's four or five different JREs out there, each with its own little incompatible quirks.
Friday, October 27, 2006
Have you considered GWT?
DEBEDb Send private email
Monday, October 30, 2006
The Google Web Toolkit is arguably overkill for a lot of tasks. I think form validation is the most common usage of JavaScript and JavaScript is just fine for that.

Another concern is that if Google changes the API, you will need to revisit your code. Granted, the odds are about the same as IE and Firefox changing how JavaScript works, but you don't really get that "they're out to spite you" mentality when you have multiple browsers available.
Monday, October 30, 2006
>> Firebug is extremely useful for javascript debugging, simpler than Venkmann but does everything (I think) I need:

Well, Firebug looked incredibly useful but unfortunately it's a total mess for me.  I can get it to break while the page loads but then the stepping is random through the source.  Then it refuses to break for any other events.  Oh well.
SomeBody Send private email
Monday, October 30, 2006
I've used firebug extensively for debugging some ajax web apps.  I've noticed that sometimes it won't break on the debugger; statement, but usually you can clear that up by making sure it's not the first executable statement in its function.  Breakpoints seem unreliable.  I like it best for its locals list.  The "inspector" functionality is great also.
chloraphil Send private email
Thursday, November 02, 2006
For debugging Javascript in the Internet Explorer (useful because it behaves different to Firefox's model) you can use the MS Script Editor. I am not sure where it comes, but it is there when I have VS installed.

Just enable the "show script errors" and press debug when ever you stumble over something.
Husker Send private email
Friday, November 10, 2006
I'm surprised to hear even a few people have had so much trouble with Firebug. I've found it incredibly accurate and useful.

One suggestion I'll make to aspirinng Javascript programmers:  produce clean and valid HTML. Learn about contemporary HTML standards and practices, and work hard to make your generated HTML lean and clean. Stop using nested tables where you can, and use CSS for every pixel of presentational stuff possible. Don't even think of letting some WYSIWYG tool generate your HTML.

All of this will make it far simpler for you to find DOM elements and to build HTML structures on the fly.

And to this sentiment expressed above: "Infuriating!  Especially when it's tough to explain this stuff to management..." Welcome to web development! We've had it much MUCH tougher these last ten years...I'd say in the last couple of years things have gotten so much more pleasant. Browser incompatibilities are frankly trivial now compared to the misery of the Netscape 4 days. Kids today got it easy...
Friday, November 10, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz