Disclaimer: I'm on the Chrome team and specifically focus on the Inspector/DevTools<p>Majd and I have talked a lot about tooling and the Chrome DevTools in particular. He ends up tweeting me a few requests or bugs a day that I'm routing to the engineering team. I love it.<p>Majd's writeup here is incredible. I hope to find a way to augment our existing documentation with this very thorough roundup. He's done a similar thing before ( <a href="http://jtaby.com/2011/05/31/google-chrome-why-i-hate-it-and-continue-to-use-it.html" rel="nofollow">http://jtaby.com/2011/05/31/google-chrome-why-i-hate-it-and-...</a> ) and the Chrome team filed and fixed 33 bugs as a result. For the new article in particular, I expect us to iterate and improve based on the excellent feedback provided here.<p>I would add that CSS Selector Profiling is mostly in the DevTools so you can see how insignificant of a cost it is (in 99% of cases). But focusing on your network waterfall will pay performance dividends a few orders of magnitude bigger than optimizing selectors. :) That said, Majd knows what he's talking about quite well.
This is a great resource and I'm glad Majd wrote it. However, this is really the kind of content that should be coming out of Google itself.<p>Google is in an interesting position. Of all of the major Silicon Valley tech companies, I think Google is the one most seen as the "web" company, and yet they've staked a lot of their future on Android. Android, instead of making the web a first-class citizen, has in fact set the mobile web back by years. While they should have worked to bring all of the strengths of the web to mobile devices, they decided to play the app game on Apple's terms and, IMO, have lost.<p>Surely someone at Google realizes that killing the open web also kills the company's cash cow--search and related advertising--but based on their behavior it doesn't seem like it.<p>My hope is that the Android wakes up and decides to make the web a priority again. In league with the Chrome team (some of the smartest people I've ever met), they could do wonders to make developing for the mobile web a joy instead of the disaster that it currently is. Google needs focus, and it needs its focus to be on the mobile web. Having great, unified documentation about building sophisticated web apps that competes with Apple's Developer Centers is a good start to doing so.
This is worth getting your head around just for the console.<p><this post is partially for those of you who are, like me, relatively new to javascript. If you're one of the demigods that works at twitter/facebook, go ahead and ignore this><p>I've been transitioning all of my projects from python cgi scripts (yuck), to shtml files, javascript clients, and APIs that run on node.js.<p>For somebody like me, that has been writing python+cgi for the last 5 years, diving into javascript was <i>daunting</i>. Terrifying even.<p>Console made this a lot, lot, lot easier. In javascript, you can call<p><pre><code> console.log("thing")
</code></pre>
and it will print it out to the console (again, this is obvious if you're done <i>any</i> JS development, I'm sure).<p>But that isn't all...<p>Suppose that I'm working with an object called map_pins. In the javascript console, I can just type:<p><pre><code> map_pins;
</code></pre>
and it will print out the object for me in a tree that I can traverse by clicking the little sideways triangles.<p>Very, very nice.<p>I can also interact with my javascript functions from the console. If I have a function called update_bounds(), I can force it to fire from the console by just typing:<p><pre><code> update_bounds()
</code></pre>
This is really, really nice. Before I discovered this, my javacsript was full of alert("I made it to this without crashing");<p>It was awful.<p>If you're learning JS and OP's article looks over your head, at least take the console away from it.
"Modern Web Development" does not mean "Works in Webkit", and it does a disservice to future/novice developers to reinforce that notion. What's dominant now was not in the not-too-distant past, and may not be in the not-too-distant future.
I'm not sure if docking to the right is really the best default; it really depends on your setup. On big, wide displays it's indeed a good way to do it. On small displays (notebooks) docking on the bottom is better. If you have multiple displays, detaching and moving the detached window to the other display works best. I think it's a good idea to assume the worst (tiny display) and dock to the bottom; the browser will remember your setting anyway so it's not like you'll need to do this all the time.
This episode of javascript jabber goes in depth about the chrome dev tools: <a href="http://javascriptjabber.com/006-jsj-chrome-dev-tools-with-paul-irish/" rel="nofollow">http://javascriptjabber.com/006-jsj-chrome-dev-tools-with-pa...</a><p>I especially like the source maps, which allow you to debug code cross-compiled from another language in that other language.
<a href="http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/" rel="nofollow">http://www.html5rocks.com/en/tutorials/developertools/source...</a>
A mild concern of mine with the "Google, if you’re listening" annotations. It's worth remembering that Chromium's an open-source project. If you really want something, send a patch.
The custom scroll bar might look sorta cool, but it's completely unusable on Chrome. The scroll tracker disappears and it's basically impossible to find. I've ended up restarting at the top of the page just to be able to scroll properly.
This is a really nice inventory of the latest Chrome Developer Tools. I also really like the recent Settings additions of "emulate touch events" and "Override device metrics" for mobile web development.
Wonderful, can't wait for part 2. One question: I don't seem to have the same file navigation for my javascript files as mentioned in this article. There is no "tabbed" browsing, nor an icon with two folders at right angles. Chrome is up to date.<p>Anyone else in this boat?
> I haven’t found a use for the Properties section yet<p>It displays DOM properties and their current state. That's pretty important to any web developer.
I was just on the Chrome Dev hangout watching some of the latest mobile devtools features demo'd. These are also really neat - ability to set resolution, simulate user agent, simulate touch events, and dock devtools to the right (so you don't have problems with it becoming too narrow when making the browser thin).
Google Chrome Canary dev tools is definitely worth it despite the bugs you see more often when using Canary. It has been vastly improved over the last years.
I remember when Firebug was the standard tool for web debugging, now, chrome (specially canary) is the de facto standard for me.
Great read, not so sure why your page was awkward to scroll though.<p>Here is more about Heap Profiling from the horses mouth <a href="https://developers.google.com/chrome-developer-tools/docs/heap-profiling" rel="nofollow">https://developers.google.com/chrome-developer-tools/docs/he...</a>
One thing that I use often: when execution hits breakpoint, you can switch to the Console tab and modify local variables, and run any code in the context of the current function.<p>Also, files in the Scripts can be edited by double clicking.
<p><pre><code> data:text/html,<b>ZOMG I AM BOLD!?!!?</b>
</code></pre>
That's one of the best tips I've learned in a while. Thanks a bunch.
One suggestion: Revise your list of browsers with inspectors to indicate what they are. The newcomer will look at that and think they need to download a tool called "Safari Stable".<p>It most likely should be something like "Safari (stable build)", and similar for the others.<p>Thanks for the write-up.