9 ms·

Chrome Developer Tools: Back to Basics

133 points by atularora 16y ago

code_duck 16y ago
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?
- eddieplan9 16y ago
  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.
  - ehsanul 16y ago
    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).
  - riledhel 16y ago
    maybe what's he's trying to say it's it should be included with the default installation, but not activated.
    - SpikeGronim 16y ago
      There's no point in adding however many MB of download for an add-on that so few people use.
      - code_duck 16y ago
        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.
        estel 16y ago
        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...
        RyanMcGreal 16y ago
        Not to mention that any developer worth his or her salt already knows to install Firebug, and everyone else doesn't need to.
        code_duck 16y ago
        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.
  - thousande 16y ago
    also it must be easier to upgrade just the add-on instead of the whole browser
- netghost 16y ago
  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.
- purephase 16y ago
  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.
  - code_duck 16y ago
    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.
- contextfree 16y ago
  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.
- celticjames 16y ago
  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.
selectnull 16y ago
$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.
- mckoss 16y ago
  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?
  - catch23 16y ago
    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.
    - pyre 16y ago
      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.
      - catch23 16y ago
        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.
  - selectnull 16y ago
    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.
btipling 16y ago
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.
nailer 16y ago
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 '{ '.
- te_chris 16y ago
  I was scratching my head trying to work this out the other day - I ended up heading back to FF and Firebug. Thankyou!
- masklinn 16y ago
  > 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)
  - rahoulb 16y ago
    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)
    - masklinn 16y ago
      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.
  - wahnfrieden 16y ago
    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.
HaloZero 16y ago
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)
- masklinn 16y ago
  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.
  - HaloZero 16y ago
    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.
- yesimahuman 16y ago
  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.
  - HaloZero 16y ago
    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.
  - masklinn 16y ago
    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.
paraschopra 16y ago
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.

133 points by atularora 16y ago

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?

eddieplan9 16y ago
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.
- ehsanul 16y ago
  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).
- riledhel 16y ago
  maybe what's he's trying to say it's it should be included with the default installation, but not activated.
  - SpikeGronim 16y ago
    There's no point in adding however many MB of download for an add-on that so few people use.
    - code_duck 16y ago
      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.
      - estel 16y ago
        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...
        RyanMcGreal 16y ago
        Not to mention that any developer worth his or her salt already knows to install Firebug, and everyone else doesn't need to.
        code_duck 16y ago
        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.
- thousande 16y ago
  also it must be easier to upgrade just the add-on instead of the whole browser
netghost 16y ago
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.
purephase 16y ago
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.
- code_duck 16y ago
  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.
contextfree 16y ago
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.
celticjames 16y ago
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.

selectnull 16y ago

$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.

mckoss 16y ago
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?
- catch23 16y ago
  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.
  - pyre 16y ago
    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.
    - catch23 16y ago
      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.
- selectnull 16y ago
  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.

btipling 16y ago

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.

nailer 16y ago

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 '{ '.

te_chris 16y ago
I was scratching my head trying to work this out the other day - I ended up heading back to FF and Firebug. Thankyou!
masklinn 16y ago
> 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)
- rahoulb 16y ago
  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)
  - masklinn 16y ago
    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.
- wahnfrieden 16y ago
  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.

HaloZero 16y ago

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)

masklinn 16y ago
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.
- HaloZero 16y ago
  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.
yesimahuman 16y ago
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.
- HaloZero 16y ago
  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.
- masklinn 16y ago
  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.

paraschopra 16y ago

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.