Debugging JavaScript rocks - make it rock harder!*

*Free after bug 127582, comment 0


Contents

Synopsis

Name: Gijs Kruitbosch
Proposed mentors: Robert Ginda and Mike Shaver

The aim of this project is to provide a simple, localizable and to-the-point interface for webdevelopers to inspect, debug and profile their code. By which means is not yet clear: extending or slimming down Venkman and/or other tools, or creating a new one are roads that could be taken to solve this problem, depending on user feedback.

Justification

Web developers use JavaScript quite often, especially now that AJAX has become the new fad. As with any code, at times JS needs to be debugged, profiled, or otherwise inspected from a meta-level while it's running. The current solutions to this problem are limited, scattered, and in some cases hard to use or inefficient.

Mozilla itself has the JavaScript Debugger Venkman. While this does what it says, people often complain about it being slow and not always as intuitive or easy to use as they would like. This article hits the nail on the head when the author writes:

The complexity and overhead of using a debugger isn’t unique to Venkman; nearly every IDE includes some sort of debugger, but these are often ignored by developers due to the amount of effort that must be expended to actually use the debugger and step through their code.

Moreover, webdevelopers often need the help of other tools, such as the DOM Inspector, Firebug, or a logging framework to actually figure out what's going on (assuming, of course, they don't use alert() anymore). These tools are not well-integrated, nor complete, nor are they particularly focused on the problems people in the real world face - they're focused on separate issues that may eventually lead people to solve their problem, but don't always address the actual problem(s) directly.

Plan and Rough Timeline

Two personal things have been taken into account when writing the plan below:

  1. My university semester does not end until July 2nd.
  2. I am on vacation from July 9th until July 16th
These things are no disaster - I've found I don't really need to be attending classes a lot in order to pass courses, with pretty decent marks even. I am confident I will still have plenty of time to do actual work.

Stage 1: Define usecases

In the first two weeks, through consultation with key Mozilla- and web-developers, select a small number of high-value usecases for a JavaScript debugger. Dividing the possible users of such a debugger into groups based on their goals when using the debugger would be one way of doing that. Now is also a good time to try to get more familiar with the js and jsd implementations in the Mozilla codebase. Profiling to get actual statistical data to compare to complaints à la "it's so slow" should also be done at that time.

Stage 2: Define concrete requirements to address the usecases

At this point it is possible to see what the debugger should be able to do, what it doesn't need to be able to do, and what the UI requirements for it would be. This is also when it would become apparent if going from Venkman (or even Firebug) is a good idea, or if something should be built from scratch. Regardless of what is decided, it would probably depend on the jsd libaries, and it could of course always borrow existing Venkman, DOM inspector or other code that is deemed useful. Since the debugger would need jsd, it is also quite possible that work on jsd would need to be done to provide a more stable or functional experience. Examples of such work are the problems defined in bug 228205 and bug 229824. The concrete requirements should all be done after 3 weeks, so before June 12th.

Stage 3: Implement the requirements

This is it, really. The exact requirements have been formulated by now, and this is where all of it should be implemented. The goal is to get these into the Mozilla codebase, either as code for Venkman or as an alternative debugger. For this, review by the mentors shall be necessary, so last-minute work will be hard, if not impossible.

Deliverables

A Firefox extension that:

If at all possible after completion of the project, it should be strived for that it also becomes useful to Mozilla application or extension developers (if it isn't already).

Short Bio and Motivation

I am a first-year student at the University of Amsterdam, where I am pursuing a BS in Artificial Intelligence. I've been a Mozilla user since early 2004, and a contributor since late that year. I have mainly been working on ChatZilla, though I've done occasional other patches or pieces of code. Mainly due to the work on ChatZilla, I was granted CVS commit access in early January. My primary focus has been in writing JavaScript, XUL and CSS code, for which I have used most of the aforementioned debugging tools, experiencing some of the problems first-hand.

I do not have much experience with C/C++ code in the Mozilla codebase or in general. I am, however, very motivated to learn how the underlying framework for the technology I use works. Additionally I simply want a better experience for Mozilla- and web-developers who want to debug their code. These are my main reasons for applying to work on this specific proposal.