I find that I am rarely using full IDEs to write code (e.g. Eclipse, Komodo, NetBeans, Zend Studio). They tend to be a bit sluggish when working with larger projects, so I favor simplistic editors like Coda or the always-faithful vim. One thing I miss about using full-featured IDEs is their debugging capabilities. They usually have convenient debugger interfaces that allow stepping through runtime code to investigate bugs.

About a year ago I started a project called ti-debug with the goal of being able to debug my server-side code (like PHP) through WebKit's developer tools interface. After getting a functional prototype of it working, I got distracted with other projects and it dropped lower in the list of my repository activities. That is, until a few weeks ago when David from CityIndex expressed interest in the project. I've been able to spend some sponsored time in order to finish some of the features, update dependencies, and create a more stable project.

Functionality

If you're familiar with the WebKit developer tools (also found in Google Chrome), the interface should look extremely familiar. The core of ti-debug is written in node.js and when started up, it creates a simple web server for you to open a browser tab and connect to. While you develop in other tabs, it will wait until there is an incoming debug session at which point it loads up the debug environment and waits for you to step through code.

The full stack trace is available along with all the local and global variables. In addition to the basic step over/into/out, breakpoints can be set throughout the code. When paused, variables can be inspected and explored. In addition to simple types like strings and booleans, complex objects and arrays can be expanded and further explored.

Not only can variables be read, they can also be updated inline by double clicking and entering new values. Or, for more advanced commands, the console can be used to evaluate application code, possibly updating the runtime.

Like most other IDE debuggers, the frontend supports jumping through the various levels in the stack to inspect the runtime and run arbitrary commands. One other minor feature is watch expressions which are evaulated during every pause.

Once a debug session has completed, the debug tab gets redirected back to the waiting page. Or, if the debug tab gets closed in the middle of the debug session, the debugger will detach from the program and let it run to completion.

PHP isn't the only supported language. By using the debugging modules from Komodo, other languages using the DBGp communication can also use ti-debug. For example, Python scripts can currently be debugged, too...

Workflow

One of the ways that ti-debug can be run is locally for a single developer, but in the case of DBGp, ti-debug can also act as a proxy to support multiple developers, or a combination of developers wanting to use both the browser-based debugger along with their own local IDEs. This way, ti-debug could be running on a central development server to allow all developers access.