The Relationship Between Firebug and Mozilla Developer Tools

kdangoor

12

As manager of Mozilla’s Developer Tools team, people keep asking me about how our work relates to the Firebug project. It has even come up in a tweet, but this is not really a 140 character kind of question.

Johnathan discussed this a year ago, and what he says there still applies today. I wanted to provide some more thoughts on this topic since we’ve been ramping up our developer tools efforts and this will be very evident in coming releases.

Firebug is an awesome project. It was groundbreaking at the time Joe Hewitt introduced it, and current leader John Barton and the project’s many contributors and extension authors have continued to push the project forward in innovative ways. It is one of the most vibrant and active open source projects built on Mozilla’s platform.

Mozilla supports Firebug’s development directly, with a full time member of my team (Jan Odvarko) devoted to working on the project. We held the release of Firefox 4 to fix platform bugs that Firebug exposed and, more recently, we landed fixes on the locked-down Aurora branch for Firefox 5 as well when they harmed Firebug functionality.

At this stage, Firefox needs to ship with a strong baseline set of tools for web developers. Firebug is a standalone project with a lot of history behind it and big plans for the future. We want to be able to build new tools that head in some new directions while allowing the Firebug project to continue to explore their ideas. Our goal is to help the whole developer tools ecosystem. We want to make it easier for people to hack on the built-in devtools, on Firebug and on entirely new experiments, too.

Firefox will ship with tools (like the Web Console in Firefox 4 and Scratchpad in Firefox Aurora). Firebug will continue to have fantastic new releases like the 1.8 release planned to coincide with the Firefox 5 release. addons.mozilla.org will continue to have new web developer add-ons and new versions of old favorites appearing all the time.

We think Firebug is awesome. That’s why we invest so heavily in it already, more so than for any other add on. We also want to explore new approaches to developer tools, and you’ll see more of these from us in the coming months. Across the board, we’re growing our investment in developer tools because there are huge opportunities to make life better for web developers.

– Kevin Dangoor

12 responses

  1. Varemenos wrote on ::

    glad to hear you guyz will support Firebug that much, though im not sure what that Scratchpad project is.

  2. devtools wrote on :

    We’ll be blogging more about Scratchpad soon. It’s a simple tool that provides a nice interface for working with JavaScript.

  3. Eran Galperin wrote on ::

    While it sounds like good news, I’m also a bit tentative to how the developer tools will perform in practice. Frankly, I use Firefox mainly because of Firebug, since other browsers’ native developer tools can’t compare, usability and functionality wise. I hope you guys take a cue from the Firebug UI and improve on it.

  4. jamEs wrote on ::

    Firebug is really the sole reason I am loyal to Firefox. It’s just bar none the best dev tool out there. I’ve tried many others out there, but they always seem to come up short when compared to Firebug.

  5. Pingback from The future of Firefox and/or Firebug (?) « I Came, I Learned, I Blogged on ::

    [...] Work seems to be undergoing as of December 2010. In the developers blog, they stated that they also support Firebug directly by assigning a full time developer to that team (I also read on John Barton’s tweeter that [...]

  6. Pingback from Firebug: Alive and Well « devtools on ::

    [...] in some people’s minds about the future of the project. Back in May, I explained the relationship between Firebug and Mozilla’s developer tools group. What I wrote there is still relevant today: Firebug remains an important and vibrant independent [...]

  7. pd wrote on :

    Quite frankly, this is disingenuous. Maintaining one developer full time on Firebug whilst other developers work on new developer tools that will exist outside of Firebug is nothing more than forking resources that could be dedicated to Firebug, or a native bundling of Firebug.

    Why don’t you stop the spin and just come out and state the bleeding obvious: you’re rightfully embarrassed that every other browser now comes with a half-arsed Firebug clone natively but you do not have the strategic aptitude to a) bundle Firebug natively with Firefox; b) dedicate all developer resources to working in a team you can’t completely control (Firebug) and c) take the massive head start that Firebug is and rapidly make it twice as good as the clones that have just, almost, caught up to it?

    Really, stop the spin and admit the reality. Your plan seems to indicate that:

    * Firefox will not have a native web developer tool the equivalent of even the crappy IE8 version in Firefox 6, 7, 8, 9 … ?

    * Development of Firebug will undoubtedly slow down with John J Barton leaving which could well create the sort of multi-year development vacuum that happened when Hewit left

    * The plethora of useful functionality currently packaged as extensions of the Firebug extension (get your head around that concept!) will be not one extension install away from native, but dozens!

    * Developers will need to use several different interfaces to do their job whereas currently this can be done with one in most use cases

    * The Tools menu is getting overloaded even with the “Web Developer” sub menu.

    What is the real truth? You don’t want to add new code to an old, non-JetPack codebase? You are not willing to take leadership of a Firebug fork, bundle it natively, and allow those Firebug developers who are willing to go along for the ride?

    At the very least, your policy is a gross admission that Firefox is years behind other browsers in web developer support and it will be years to come before you catch up. That is what your decision to operate separately of Firebug effectively says.

    Clearly Mozilla wants native developer tools; wants full control over any such initiative and is deluding itself that funding one single developer full time on the very codebase that could give you that in a heartbeat is an effective policy.

    Please re-consider!

    1. kdangoor wrote on :

      Hey pd,

      Thanks for the comments. It’s great to see this level of passion for our tools.

      First of all, Firefox is not years behind… because of Firebug! Firebug is still around and still moving forward. Additionally, Firebug is more visible in Firefox starting with Firefox 6 in which we added the “Get More Tools” menu item which leads to a collection on AMO that has Firebug at the top.

      I want to clarify that we have indeed considered the option of building Firebug into the browser and other choices along those lines. Those are not the best options.

      Firebug is written in a way that is very different from Firefox. The project is approaching a point where Firebug and Firebug Lite share the same UI code, which is great for the Firebug project. But, that’s not something we want in Firefox features, because it requires having cross-browser compatibility bits in there. Cross-browser requirements also prevent us from using advanced features that Gecko offers and that are standard practice in building Firefox features.

      Firebug and Firefox built-in devtools will likely share a considerable amount of code in the form of new APIs and the remote debugging protocol that the platform is gaining. The projects are not 100% separate, from that perspective, and all of the code involved is open source. Patches welcome all around by any contributor.

      Project control is not the issue… there are plenty of other reasons (given here and in the blog post) why we’re building what we’re building.

      Kevin

  8. trlkly wrote on :

    If you had real reason, you could say them here, instead of the spin job you gave. You didn’t explain why on anything. You just said, “We don’t want to go in that direction.” That’s not a reason. WHY do you not want to go in that direction? WHAT is it about Firebug that does not meet your goals? WHY can’t you incorporate the current Firebug into native code? Heck, WHY are you going for native code in the first place.

    Those are the questions this should have been answering. Reassurances without facts are just completely useless. And I say this as someone who only stumbled upon this press release (as that’s what it really is) accidentally.

    The comment above me is right: it looks suspicious not to give details, and instead give platitudes like “We think your project is cool. We’d never do anything to hurt you!” That’s great for the 12-year-olds who contribute. Now how about the adults?

    1. kdangoor wrote on :

      When you say “native code”, I assume you mean “code that ships with the browser”, as opposed to something like C++ code. All of the developer tools we’re talking about are written in JavaScript (plus the requisite bits of HTML/XUL and CSS).

      I’m not going for a “spin job” with this post. It sounds like you read the comments. Did you read mine from July 26th?

      We want tools that:

      1. we can guarantee work with every version of the product (including Nightly) because our automated test suite ensures that things don’t regress
      2. try out new ideas that may or may not appeal to existing Firebug users (user-level “backwards compatibility”)

      We have the infrastructure to ensure #1 for code that is written to the same standards as Firefox itself. Firebug is a separate project with its own infrastructure and coding standards that dictate that large swathes of it can run cross-browser.

      For #2, Firebug can and does evolve but, for a variety of reasons including user familiarity, it’s hard to try completely new directions.

      Kevin

  9. David Mulder wrote on :

    In regard for the arguments which you present in the comments it would seem to make more sense to fork firebug, as it would take far less time to “clean up” firebug and optimize it for Firefox only compared to remaking them from scratch.

    1. kdangoor wrote on :

      To be honest, “cleaning up Firebug” is:

      1. not that straightforward
      2. not the best way to approach trying new user experiences

      That said, I expect that some of the development in both Firefox and Firebug will be useful to the other. For example, it was decided that the best approach to getting an HTML tree view was to use Firebug’s. Also, we expect that some of the work we’re doing for multi-process Firefox will be usable by Firebug as well.

      So, our code is separate but not in isolation.