Good news for all the Google Chrome users, IBM’s John J. Barton, the core developer of Firebug, will be joining Google’s Chrome team to work on its next generation Web dev tools.

What made him to take such decision? According to John, working on the next gen Firebug is not practical as browsers change too fast for the size of its team to keep up and shift from desktop to mobile requires additional development time. Furthermore, he could not obtain another year of support from IBM to continue the contributions.

Here’s what he had to say:

Now all of the browsers have (or will soon have) their own debuggers. Basing next gen work on Firebug is not practical. The pace of change in browsers is too fast for our team size. Firebug hasn’t really been able to keep up with Firefox, let alone compete with other tools. Moreover, the shift from desktop to mobile and from one high-tech browser (Firefox) to three or more requires additional development effort. I think our current drive to re-architect Firebug is on the right track, but I could not obtain another year of support from IBM to contribute to that work.

In moving to Google my first priority will be to complete the investigation of QueryPoint debugging with Salman Mirghasemi while he is still in his PhD. Other work will depend upon what I learn at Google, but I hope to be able to help if someone from Firebug wants to port to the Chrome remote debug protocol. While the Chrome team is naturally focused on tools for their browser, Google as a whole benefits from dev-tools improvements on all platforms. Thus I will also be looking for other opportunities to work with you.

[Thanks, nobody!]

About

Those are default installed web browsers/extensions with no settings changed. This is a mini comparison which focuses on elements inspection, source modification and overall usage rather than advanced tools. If you find yourself using features such as script debugging, elements loading speed, etc. this review might not be very helpful.

Speaking of inspecting certain things, same site element was used in all the tools.

Internet Explorer Developer Tools

As you can see from the picture, inspecting and seeking for certain elements is quite easy and fast, thanks to checkboxes near each of them. Instead of disabling elements one by one, you just click on the whole tree and that’s it.

When it comes to inspecting, there are few annoying things: if elements are near each other, it can be hassle to pick the one you want due to high sensitivity.

Another issue: blue border. You assume that once you click on the certain site part, it will disappear but that’s not the case. Actually, you have to click on the arrow to remove the border. Of course, it doesn’t sound too bad, however when you are trying to modify lots of borders (and blue one is on top of them), it can be annoying and time consuming.

Firefox Firebug

Even if you not a web developer, Firebug is probably already wired into your brain and you’re going to download it once you start developing.

Interface is light and well made. Picking certain elements is also much easier than in Internet Explorer developer tools.

Disabling certain classes can be done fast too. However, it does not have IE like checkboxes which might take some time if you want to turn all of them off.

One thing which I’ve found annoying was the way it accepts code. When you’re working with CSS arguments, line ends with semicolon (;), right? Well, not in Firefox. Firebug will automatically add it which just messes with your mind. Add ; when coding in text editor, don’t add when coding in Firebug.

Safari Web Inspector

Just like IE, this was my first time trying Safari Web Inspector.

The interface is pretty much Mac alike aka lots of gray. Although it’s a matter of taste, I’ve found it to be worse than over developer tools.

As you can see from the screenshot below, Web Inspector has checkboxes similar to IE’s. Even though you can’t disable the whole ID, it can be done a little bit faster than in Firebug.

One of the things I didn’t like in Safari developer tools was the way it displays color code. Instead of the usual #00000 it will show something similar to this:

Opera Dragonfly

Last but not least is Opera Dragonfly (still in alpha). As it is being served from Opera server, this tool will always be up to date which is quite nice.

Interface looks light and simple, although I’ve found it to be slower than its competitors. The very first issue which you can instantly notice is elements edit. To quickly disable certain attribute, you will have to delete the line itself.

Certain elements cannot be modified as well, even though they are listed in the right column.

As this tool is not even in Beta stage yet, there is not much left to say. I am sure things will improve.

Conclusion

As you can see from the very first picture of each developer tool, all of them were picking code differently.

For the very basic needs and quick developing (find, edit, fix), I would go with Internet Explorer Developer Tools choosing Firebug as a great alternative. Even though Safari’s Web Inspector interface was not very impressive I’d still chose it over Opera Dragonfly which so far lacks some basic features.

[digg-reddit-me]

Now this is something useful. If you were ever confused/overwhelmed with all the modifications made using Firebug then worry no more.

A new extension called Firediff (requires Firebug 1.4) tracks all the changes made by firebug and the application itself to CSS and DOM.

Download
The latest Firediff release can be downloaded here.

[digg-reddit-me]

This version includes fixes for the Firebug’s activation, several fixes for the command line, as well as file locking and net panel fixes.

Download Firebug 1.3.2

The following version won’t work with Firefox 3.1. However, the upcoming Firebug 1.4 alpha release will fix that.

For the changelog, please check release notes here.

[digg-reddit-me]

What was changed?

== Enablement UI ==
* Disable always: when the Firebug UI is not active on any page, the debugger is disabled (minimal overhead)
* Instant on: when the Firebug UI is active, HTML, CSS, DOM views activate (minimal overhead)
* Script panel user-activation: initially disabled or enabled always
* Net panel user-activiation: initially disabled or enabled always
* Console panel user-activation: initially disabled or enabled always. Controls ShowXMLHTTPRequest, consoleListener
* Bug Icon gray unless some page has Script or Net panel activation
* Multipanel enablement.
* No Allowed-sites/Disable for Site: no longer needed.
* Suspend/Resume Firebug in status bar context menu
* List pages that enable Firebug on the Context menu tooltip.
The UI for this feature is being refined; overhead tests have not been completed.
We are interested in feedback on this UI change.

== Javascript Debugging ==
* Written/cleaned up eval support
* Performance on eval better, easier to support.
This feature is complete; Bug reports on javascript debugger welcome.

== Net Panel ==
* Net timing more accurate
* Only real network requests displayed.
* Limit for number of requests (configurable in preferences).
* Additional columns for: request method, status response + text
* Cache tab has expiration time in Net panel
* The Response tab has a hack to prevent extra requests to the server. Users must click on a button to force the request.
The hack will not be needed in the next release of Firebug.

== Console ==
* Redesigned to use events/attribute passing.
tests/console/joes-original/test.html mostly passes

== Command Line ==
* Redesigned to avoid using evalInSandbox.
tests/console/commandLineObjects.html mostly passes
commandLineAPI functions, ok.

== DOM Panel ==
Works for FF3pre after about 2008041406 (https://bugzilla.mozilla.org/show_bug.cgi?id=425139)

== Misc ==
Secure updates via signed update.rdf with xpi updateHash values.

== Localization ==
* Hu-hu by Zoltan Papp (issue 749)

And tons of the bug fixes.

Mozilla Firebug or Opera Dragonfly, what’s your choise?

[digg-reddit-me]