It was news to me, because I was looking for some kind of documentation for quite some time now. The best I found so far was webkit blog at http://webkit.org/blog/
In a nutshell, it's not about the tools, it's about the missing docs and I hope google invests more resources into teaching the developer how to use these tools more efectively.
Dev tools is an excellent tool for web developers, and as far as I know, no one is using it because of Firefox and Firebug. I'm not saying they aren't good tools: they are. It's just that I personally prefer Chrome over Firefox as a browser, and I'm really glad I found this documentation resource.
The only thing that these can't do which Firebug Lite can is render the HTML for XHR responses inline in the console. In Chrome, unless I'm using the Firebug lite bookmarklet (which isn't perfect), I have to copy and save the response to a file before being able to view it. This is a big time waster for debugging web apps that send error messages in HTML, like with Django.
You totally can view the response, just go to the 'Resources' tab, choose 'XHR' from the top bar (or not, but it's easier). Now cause a request. You'll see it pop up in the list on the left and you can click it to see headers/params and the response.
I had to reread the reply, but it sounds like they're speaking strictly about rendered HTML- not just the response text.
For instance, when an XHR response is returned as "Content-Type:text/html; charset=UTF-8", I still see raw HTML in the content pane: http://grab.by/7SXg
Wow. This isn't adding value to the conversation but I had never noticed that while using or in the documentation. You saved more than 1 person a lot of pain. Thank you.
No problem, took me a while to find it too. I would still prefer to be able to expand it in the console a-la Firebug -- however the more I use Chrome as my primary browser the less I find myself using the console in general and thus I mostly stay on 'resources' except in the early stages of coding (when there's a lot of logging going on :)).
Thanks, but this doesn't render the HTML, it just shows the plaintext. The HTML generated by Django for error messages is not very readable, which is why I have to copy what Chrome gives me in that XHR tab into a new file to view as rendered HTML.
I just end up using Firebug Lite instead when I need to do this, but it's really clunky.
Ah I see you want to see it rendered. Well, considering how Web Inspector is implemented that shouldn't be especially difficult to do. Maybe make a bug report[1]?
Firebug was the only thing keeping me in Firefox for a while. The initial dev tools that Webkit came with were ok, but nothing on Firebug.
Chrome dev tools have come a long way though. I use Chrome as my main browser now for both surfing and dev, and although I miss the snappiness of Firebug, Chrome's dev tools are just as good, if not better.
Until yesterday I've favored Firebug over Chrome Dev Tools; the only real reason being that I haven't been familiar with the Chrome tools at all. Yesterday I fell in love with Chrome Dev Tools... The reason is that I was playing around with developing a Chrome extension (in particular one for HN which I'll have finished soon).
Not only is extension development much more fun (you can load unbundled extensions directly from the source directory, reload it to load the updates source code with one click, and there is no need to restart the browser at all). But one of the best features is that when you get some element from the DOM of the current page, and log it or any of the children elements to the developer console and hover over it, Chrome highlights that particular part on the website itself. This is just so helpful!
One thing Firebug does that I can't find in WebKit's developer tools: in Firebug, when you select an element and switch to the "Layout" tab, mousing over the various measurements will draw on-screen rulers and guides that show how the element lines up with other items on the page.
Something that constantly annoys me at work is not being able to debug dynamically loaded Javascript code (i.e. JS code returned by an ajax query, then evaluated with eval()). I know this probably reflects bad design, but unfortunately it's not up to me.
I think it would be nice to have debugging support for JS code in those cases when it's evaluated from a string instead of loaded using a <script> tag.