Switching to Chrom(ium)

Developer Tools

Perhaps the most common task for which I need developer tools when working on Web applications is the ability to change HTML and CSS. That is, I see a page, and I wonder what would happen if I were to modify the tag, add a new tag or even add a new style to the tag via CSS. For example, if I were working on the Linux Journal home page, I might go to the "Trending Topics" headline and want to see how I could change it in a number of ways. With Chrome, I don't need to install a plugin; I always can right-click to get a menu over some text. One of the options is "inspect element". This divides my browser window in half, letting me see the HTML source on the bottom and the original site on the top.

If I want to change the text, I can just double-click on it within the lower (inspection) window and type what I want. Obviously, the changes I make aren't saved back to the server, but that's usually not what I want. Changing things within the browser gives me a laboratory within which I can experiment without having to change or modify my server program.

That's not all, of course. I also can change the tags or any of the tags' attributes. So where "Trending Topics" has a class of "title", I was able to change it to "awesome", which, of course, immediately reverted the style to have the page defaults, because no such class previously existed. I can see that right away on the right-hand side of the inspection window, which gives me a live view of the CSS styles that have been applied to the tag in question ("matched CSS rules"). If I change the class back to "title", the matches change accordingly.

Now, the "matched CSS rules" show me all of the rules that have been applied to a particular element, and that's really useful—especially since this list shows me each rule that has been applied and the file in which it was defined. But because of the cascading nature of CSS, multiple rules can apply to an element, and it can sometimes be hard to keep track of which rule was defined where. For this reason, Chrome provides a "computed style" section in that same area of the screen, allowing you to see the final list of styles that apply to a tag and text. You even can ask to see all of the inherited styles, which can sometimes provide additional insight.

The bottom part of the screen isn't just a tag-and-style inspection screen, but the initial tab of the "Chrome developer tools". These tools are constantly under development, and it's a bit of a challenge just to know what has been updated and improved in each version. (Although to be fair, the folks at Google do provide a changelog for each version they release.)

The second tab, after the initial "elements" tab, is marked "resources", and that refers to just about everything you can imagine. Through the list in the left frame, you can get to every HTML element on the page, including images, movies and stylesheets. But if you have been following the development and release of the HTML5 standard, you know that there have been multiple proposed standards for a number of features, including client-side storage. Well, the "resources" tab gives you access to some of these under the "Web SQL" and "local storage" lists. If your application uses these features, you can poke around inside their contents using this tab.

The other tabs are quite useful as well: "network" lets you see Ajax calls, and "sources" shows you which files have been loaded by the browser.

The final tabs are where Chrome really starts to show its stuff. The "timeline" functionality isn't on by default, but rather requires you to press the round "record" button, so that Chrome will keep track of when different parts of the browser are being used, and how much time they're taking. I have often used this sort of functionality on other browsers to keep track of how long pages take to download, but to get a graph of the browser's memory consumption at each point during the rendering of a page is extremely useful. It becomes even more useful if you keep the timeline recording on and then have a browser-heavy application that uses lots of JavaScript, because it can show you when your memory consumption is rising.

The "profiles" tab does two things. It checks the efficiency and speed of your CSS selectors, and it also checks memory use. The first can be quite useful when you have an extremely complex set of stylesheets, which can take a long time to render. You can optimize your style selectors and also concentrate on creating styles only for those elements that actually need them and which appear on the page.

The "Audit" tab is similar to the famous YSlow tool for Firefox, in that it checks a number of common problems that can lead to slow loading and delivery. Your page will be ranked on a number of different criteria, getting a score, detailed results and a handy red-yellow-green indicator showing how well you're doing on each of these criteria. If you're not sure whether your site is slow, or what you can do to speed it up, this tool can provide some quick fixes or at least advise you as to where you need to concentrate your efforts.

Finally, Chrome offers a JavaScript console, much like the one I've grown to know and love in Firebug. This has become an essential tool for my work in JavaScript, letting me query and modify the page, as well as check my work and test snippets of code before committing them.

Now, none of these things are unique to Chrome. With the right combination of plugins, I can get all this, and more, with Firefox. But the level of polish, the rate at which these capabilities are expanding, and the fact that they're included by default with every copy of the browser has proven to be very useful in my day-to-day work.

But, that's not the full story. Chrome offers developers the chance to extend the browser in numerous ways, including by adding new developer tools and functionality. For example, I've been using the "Ghostery" extension to show me which external services (from advertising to auditing) are included when I load a page. This is less useful on my own pages than on others, but I actually have learned of several interesting third-party extensions in this way. The Google Chrome store, which is available to Chrome users (and less easily for Chromium users) offers a huge number of extensions—some are aimed at developers, and others are aimed more at end users.

Indeed, the true power of Chrome is in its openness to extensions, which are surprisingly easy to write and which offer a great deal of power to Web developers—either to add new developer capabilities or even to add specialized functionality for clients and users. In my next article, I'll show how to create such extensions and ways you might want to use them.

Conclusion

During the past year, I've found myself drawn more and more to Google Chrome. I finally took the plunge, making it my default browser, and I haven't been disappointed—as a developer or as a user. There are things that I miss, such as Firefox's ability to sync tabs between my Android phone and my laptop, but I can get over that. For the most part, I've found the transition to Chrome to be smooth and easy, and a very worthwhile one at that.

Resources

Information about Google Chrome is at http://google.com/chrome.The Chromium open-source project is at http://chromium.org.

Some basic information about the developer tools is at https://developers.google.com/chrome-developer-tools.