We released the first prototype of the Open Web Tools Directory just over a week ago. The goal is to allow the community to track the landscape of tools. The landscape is large, and you have already stepped up to help flush it out. Within a couple of days we received about 200 additions to the tools database, and it continues to grow. In the current design, you can slice and dice the data based on the high level workflow elements of code, design, debug, test, and deploy as well as searching the data. Each item has tags associated with it which enable pivots in many directions.

We have released a new version of the tools directory and in this post we discuss the new version, as well as thoughts for an Open Web Dev Center.

We are using the tools directory as a way to observe what is out there, and thus what is needed. One of the gaps that we have found is getting detailed memory and performance data from the browsers. As we create richer and richer true applications on the Web we need visibility into the runtime. To get that data you often have to probe deep into the browser. To experiment in this area we created an add-on that does just that to track the JavaScript heap. This was just announced as the browser memory tool prototype.

We talk about the high level vision for the tool:

And then we also showcase the tool itself:

Atul Varma has written, in some detail, how he uses the various JS APIs to access detailed information from SpiderMonkey.

There is a lot of detail in those two posts, and there will be more to come. We are releasing these tools as early as we can to get your feedback, and hope to create new ways to work together to make the Web better through tooling and beyond.

– Dion Almaer and Ben Galbraith on behalf of the Developer Tools Lab.