Personally I browse in Chrome, but the second I start debugging JS/AJAX i'll open Firefox and use that. It's 10x slower, it has Memory leaks up the wazoo, but firebug blows chrome's debugger out of the water.
> but firebug blows chrome's debugger out of the water.
Could you please describes the ways in which it "blows chrome's debugger" [actually the Webkit Development Tools, it's been much more than a debugger for quite a long time) "out of the water" in your opinion?
When editing a CSS property, pressing UP and DOWN will iterate through all of the possible values of that property. For example, editing "display: none", you can quickly find out what values "display: " can take.
True, the webkit DOM inspector can only increase or decrease numerical value, it doesn't work for arbitrary values (I actually find worse that it does not autocomplete property values)
Yeah, I'd also like to see an analysis of this. I used to be an automatic 'switch to Firefox for debugging' user, but I find that the Chrome developer tools are now pretty sufficient.
a small example, not really analysis, but it does count. one of the reasons I still use ff instead of chrome for debugging is that on post requests viewing the raw source of a page requires chrome to repost to the server. ff just shows me the page/data as it came back without the repost, which can be critical in debugging stateful posts where a double post effects state.
Here's one example: I've found that in certain cases Chrome's debugger sometimes can't link back to the line number where an error is caused when that line is inside an anonymous function, whereas Firebug often can.
That said, I do most of my debugging in Chrome, only switching to Firefox/Firebug when they fail me, which isn't too often.
One thing that I always go back to Firebug is for the 'Persist' mode on the Network tab. In case your server side code is redirecting to some other page or site (payments etc) you need to see what was passed to the server and what redirection loops is it going through etc.
Another thing that I haven't found Chrome to be able to do is show me events in the DOM tree (I admit I need FireQuery to do that). That really helps you figure out what events are associated with a particular DOM element.
> Another thing that I haven't found Chrome to be able to do is show me events in the DOM tree (I admit I need FireQuery to do that). That really helps you figure out what events are associated with a particular DOM element.
Safari's version has that, not sure about Chrome.
In the DOM inspector, right pane (the one starting with the Styles group), scroll to the bottom and you might find a group called "Event Listener".
You can even switch between viewing only the events bound specifically on the currently-selected node, or those bound on all its ancestors as well (to visualize the bubbling sequence).
There is no equivalent to the Firefox JavaScript console, especially when you add the jQuery plugin to it. Chrome console sucks. Their DOM explorer is superior in some ways, though.
The moment you enable the javascript features of firebug, the browser disables its jit tracing leading to a slower experience. You are a victim of your own usecase.
FF must be optimized for Linux or something, b/c on my Ubuntu 10.04 workstation it runs roughly the same as Chrome and Chromium do, in fact it's even more stable for me with tons of tabs open (though I haven't used Chrome in several months so maybe that's changed?).
The rate of improvement in Chrome, particularly in snappiness, is very high. I'd recommend you try it at least every 6 months. It is noticeably snappier on Ubuntu than Firefox for me, especially when switching tabs.
I did, I used Chrome and Chromium since it came out, until I discovered Vimperator a few months ago. Something about that plugin made FF a brand new browser that's just a joy to use, snappy enough that I don't notice the difference b/t it and Chrome/ium anymore, even tab switching, and even more stable with lots of tabs open (like ~45).
