Chrome Developer Tools: Back to Basics | Hacker News Reader

Chrome Developer Tools: Back to Basics

blog.chromium.org

133 pointsatularora43 comments

I welcome the changes to the CSS tools in particular! While the Inspector is full featured and offers some capabilities not found in Firebug, Firebug still feels more natural and reliable to me. The change to show unfiltered CSS rules is really helpful.

It's odd that Mozilla hasn't officially adopted Firebug as part of Firefox. While Firebug continues to improve, and the Firebug team does a great job, with Google is focusing on this area I suppose at some point I will prefer the Chrome inspector. Why is Firebug still a plugin?

On the darker side of web development, IE's development tools are typically lacking. Does anyone know whether they have been improved in IE 9?

Because less than 0.1% of Firefox's users would ever need Firebug. Unlike Chrome, which is built on top of WebKit and therefore naturally inherits its built-in Developer Tools, Firefox was designed to be lean and focused unlike its notoriously bloated lets-include-everything predecessor. Being a clean, simple browser and leveraging the extension system for customization is the biggest strength of Firefox.

Yeah, it's overlooked by many that the Chrome isn't all that extensible compared to what you can do in Firefox with addons. Chrome's developer tools are built in because they must be, whereas Firebug should be able to do anything that Firefox does natively (though I think it may be mostly Javascript now).

maybe what's he's trying to say it's it should be included with the default installation, but not activated.

There's no point in adding however many MB of download for an add-on that so few people use.

It's 1.1 mb, which works out to less than five seconds for most people. I suppose they do leave it out to keep FF more lean, but that doesn't mean it Mozilla can't have an official web development add on.

1.1mb multiplied by the number of downloads of Firefox divided by the proportion of people that will use them? I don't think that that sounds like very good value...

Not to mention that any developer worth his or her salt already knows to install Firebug, and everyone else doesn't need to.

Chrome style incremental updates would help here. Firefox makes people download the entire browser package each time there's an update, while Chrome downloads a patch - a saving of >90% size-wise.

also it must be easier to upgrade just the add-on instead of the whole browser

I've actually gotten to quite like the dev tools in Chrome/Safari. I started using them because I was using Chrome anyways.

Editing CSS in Chrome is still more cumbersome, but otherwise I think it's pretty great, especially the timeline and network views.

I can't recall the tools in releases prior to 9 as I've been using the betas and RC for some time now, but they're actually not that bad.

Firebug and the Chrome developer tools beat them easily, but they have improved.

They are adequate in IE8, but that's about all. The IE8 Dev Tools have some useful features (like easy cache clearing), but it doesn't seem like Microsoft had made much of an effort to make them user friendly or complete.

I haven't tried the IE9 tools extensively but I did notice that evaluating a JS object in the JS REPL will now let you see the structure of that object as in Chrome, not just display "{Object}" as it did in IE8. That was probably my biggest gripe with the IE8 tools.

1. If it was part of trunk, you'd have to wait longer for new updates. As it is, Firebug can push updates without waiting on Firefox updates. 2. The Firebug developers and core mozilla developers overlap a lot. There is work done in trunk that complements Firebug. So it's has plenty of official blessing. 3. There isn't any performance advantage to putting it in trunk. Extensions in mozilla are first class citizens. 4. It would probably confuse ordinary users.

I actually use Chrome Dev tools more than Firebug these days, but that's because I do work on Chrome Extensions.

They're typically Google: great on a technical level, with a somewhat sketchy UI.

One tip: to add a new item to a style click the whitespace area to the right of '{ '.

I was scratching my head trying to work this out the other day - I ended up heading back to FF and Firebug. Thankyou!

> They're typically Google: great on a technical level, with a somewhat sketchy UI.

They come mostly from the Webkit project itself actually. I'm sure Chrome contributes, but the main driver is Webkit (thus probably Apple)

Just on an appearance level, the inspector in Safari is significantly better looking than the one in Chrome (although functionally they seem pretty much equivalent)

The only significant differences I noticed are that the Safari/Webkit version has nice gradients (in Chrome, the "tools" tab bar is flat and each section gets a "depressed" gradient when selected, in WebKit the whole bar has a gradient giving it "volume", nicer to look at) and the whole bar is draggable in Safari (for resize) whereas in Chrome you have to grab the intersection between the tools and the actual page.

The former is a nice detail on Saf's part but not really important, the latter is a real pain in Chrome as I'm mostly using Safari/Webkit for my development.

I just want to note that if you look at the maintainers list for webkit, it's full of Google employees. I don't know specifically who contributes to the inspector though.

I still would prefer the resources tab to split between css/js/images instead of just one giant list of all the resources (including XHR)

The mixed tab is not "resources" anymore, it's "network" and it's filtrable by type. XHRs don't appear in the new "Resources" tab.

But the Network tab only shows you files if you had it opened from the start, which is of coures correct behavior. You don't want Chrome tracking network latencies on all sites you load. The network tab is for tracking more than looking at resources.

Yea I don't understand the resources tab. It's just a mess right now with a huge list of files. It seems like it would be a good place to list what stylesheets were loaded and such, but it seems like the network tab has taken over most of that. I say get rid of it or rename it and move it to the end of the tab list, considering how useless it is for the majority of cases.

I think they future cased it for HTML storage requirements and for people who are doing more advanced stuff rather than just basic work. Might be useful if you're using those features.

Resources is a list of all the resources linked to the current tab (page).

It starts with a nested trees of network resources (Frames > Pages > HTML, CSS, JavaScript and Images, note that in the case of e.g. CSS files if you have performed editions via the Elements tab they will be trees as well listing all previous revisions of the file), then lists the databases, local storage, session storage, cookies and application cache for the page.

Networks holds most of the old "Resources" tab, it is a detailed view of the network transactions (HTTP and WebSocket request/responses) performed on the current page since it was opened.

$0 tip is awesome and new tip to me. Watch the video for demo, but basically it's a reference for selected DOM element. It also appears (not mentioned in the video) that $1, $2, etc references are also created for each DOM element you select in DOM tree view.

Have you ever notice how '$' is sometimes overridden in the developer tools console - it does not always refer to jQuery when I'm debugging in a breakpoint (thankfully, 'jQuery' always works). This confused me for quite a while.

Is it something that the console is doing or is it some sort of feature of jQuery?

the '$' is just another character from the view of the javascript interpreter. It just so happens you can use A-Z, 0-9, underscore, and the dollar sign as variable names. Libraries like Prototype & jQuery have popularized using the dollar sign as a globally accessible namespace variable, but it's nothing more than just another character.

I think that the parent is referring to the Chrome console which has (IIRC) jQuery baked into it, even if jQuery isn't part of the actual page.

Does it? I don't see it in mine. HN doesn't use jQuery and when I fire up my console, the $ variable is not overwritten with a jQuery object, also there is no jQuery variable available.

Yes, I've noticed that. It's the same in Firebug too. It definitely bugs you in debugging :)

I'm not exactly sure what defines it, I think it's devtools (or firebug) itself, but it's a function that returns a dom element with id of first argument.

Very annoying, although truth be told, $ and _ should have never been used in js libraries: those names were reserved for internal use in javascript.

Citation needed, please. I keep reading this note that $ and _ are reserved, but I haven't really seen a reference. Besides, _ and $ are not reserved keywords (unlike, say, 'class').

Ecmascript 262, 3rd edition, section 7.6 http://www.ecma-international.org/publications/files/ECMA-ST...

"This standard specifies one departure from the grammar given in the Unicode standard: The dollar sign ($) and the underscore (_) are permitted anywhere in an identifier. The dollar sign is intended for use only in mechanically generated code."

It was removed (or I can't find it) in 5th edition. Also, I can't find a reference for underscore.

[edit: read that you said it was removed in the 5th edition. makes the rest of this comment invalid, I guess]

You delivered! Thank you for the effort.

This what that section says - "The dollar sign ($) and the underscore (_) are permitted anywhere in an identifier. The dollar sign is intended for use only in mechanically generated code."

This seems contradictory. Do they mean to say that $ (only $, not $x) is intended for use in mechanically generated code? Doesn't that make variables $0 [and so on] actually valid? And if not, then doesn't that makes $0 an invalid variable. Finally, why don't javascript interpreters throw an error when you try to name a variable $? Is there a reason they're ALL (v8, nitro, spidermonkey) lax to the ecma standard?

All a little confusing, but trivial enough to ignore, I suppose...

[Also, this somewhat validates my choice of using underscore.js + mixins for my code. sweet.]

In Chrome DevTools, during runtime $ should always be jQuery (assuming its on the page). This isn't the case in Firebug AFAIK.

I believe in both tools, at a breakpoint, $ will be the getElementById shortcut that's baked into the console API. Kind of a bummer, we're trying to work around this.

You can always do `$ = jQuery;` to redefine it and you'll be good.

Thank you for the explanation. It would be awesome if that gets "fixed". :)

FIXED! http://crbug.com/70969 :D

(it was actually fixed two weeks back. phew!)

Awesome. Thank you. :)

Awww man, I thought I reported it first :( (My report is the duplicate listed in the ticket)

Contrary to most comments here I many times prefer IE 8's developer tools over Firebug or Chrome developer tools because of a very simple reason: IE 8 allows debugging JavaScript that is minified and which has all the whitespaces removed. Firebug goes crazy there and I so much wish it highlighted right part of JavaScript code while debugging even when there were no whitespaces in the code.

Is this only in the Developer channel or also the Beta? Also updates on the network view is great, I generally fallback to Firebug for those and wish I didn't have to.

Edit I see it in beta, nice. Still would like a json viewer though.

Reply on news.ycombinator.com