For a very long time I used Firefox as my primary development browser because of the excellent add-on, Firebug. There is no denying that Firebug has long been an essential component in a web developer’s toolkit. It’s kind of like a mobile phone – once you’ve used it for a while, it becomes hard to envisage how you managed before it.
More recently though, I have started to instead use the Developer Tools built into Chrome (they are very largely derived from WebKit’s, and as such most of them are also available in Chromium and Safari). I like Firefox and Mozilla’s open-source philosophy but I have to admit that I think Chrome now beats it hands-down in regard to developer tools as well as load speed, memory footprint and overall aesthetics.
Here are some things about Chrome Developer Tools that I like:
Save edited stylesheet
This is a feature that is genius in its simplicity, it’s also become my favourite feature. Once you have finished making tweaks to your styles in the DOM inspector, you can click the modified stylesheet’s name to open it in the resources panel. From there you can right click in the source code and choose the option to save the CSS file to wherever it resides locally without having to go back into your IDE and replicate the modifications you made.
Parts of the stylesheet that you didn’t modify will be left untouched, and whichever indentation method you use will be respected when adding additional declarations. I generally prefer to verify this using diff via Subversion or Git, but I’ve never seen it make any mistakes.
Note: Saving the stylesheet directly from the browser means that your IDE will probably drop and reload the file into memory, any undo history will be lost. If you rely heavily on your undo button, you might want to exercise extra caution in using this feature.
I might be missing something in Firebug, because it seems like such an obviously useful thing to have would be the ability to inspect an element and view any event listeners attached to it. I cannot find a way to do this in Firebug, and there’s a really straightforward tab in the far right panel of Chrome Developer Tools which lists any event listeners attached to the selected element (or any of its ancestors). If you’re using a library such as jQuery or Prototype, chances are the code that will be identified as being responsible for the listener will be somewhere in the library file; worse – on line 1 if you’re using the minified version. However, you at least get the feedback to let you know that a particular listener is attached, which can save a lot of time when debugging problems where events don’t seem to be firing.
The resources panel is great for examining components of the page which failed to download for some reason. Hovering over a resource will show you the full path that was used to request the file, which allows for quick identification of typos and errors in your source code. You can also select the component in the resources panel and immediately see the contents of the file in the adjacent window, where you can check that the file downloaded is actually the file you were expecting.
Essentially, whichever development tool you use is a matter of personal choice. It’s only quite recently that I’ve stopped using Firebug and I do tend to go through phases. I might very well decide to go back to using Firebug at some point, and it’s still pretty much essential when it comes to testing pages in Firefox. Or maybe I will eventually start to appreciate the developer tools in Internet Explorer and start using Windows for development… well to be honest, that’s not very likely.Tags: