Like every web developer I’ve spent a lot of time using the Firebug extension to Firefox in my day-to-day development. I’ve found it interesting to see how my development methodologies have changed with access to that tool.
Unsurprisingly, my personal development style mirrors much of the general web dev public. But what I find most interesting is to try and track trends in web development that Firebug has single-handedly revolutionized.
Firebug Advances
Performance Profiling
Prior to Firebug there was only rudimentary analysis of JavaScript performance (using tricks like injecting timers and computing the difference). Firebug brought us the ability to analyze all function calls during a period of execution, see how they each affected each other and, probably most important, see the difference in the sub-millisecond range.
Previously none of these techniques were possible with pure-JavaScript techniques – having the ability to tap into the JavaScript engine (which Firebug does) is fundamentally important to getting good analysis.
You can see an immediate interest, by JavaScript library authors, in the performance of their code bases around the time of Firebug’s introduction of profiling.
Console logging with object introspection
Logging statements has always been possible with JavaScript (and, most infamously, with the alert() function) however Firebug gave us something significant: The ability to click and introspect into logged objects. This includes the ability to click DOM nodes (and see their properties and methods) and even normal objects (like Arrays or Object literals).
Firebug has to maintain a lot references to point to where these objects exist – and it wouldn’t be possible in pure-JavaScript without introducing an excessive number of memory leaks.
Current Styles / CSS Rules
There had existed some tools for examining the current CSS style values of a DOM element (such as its dimensions and positioning) but Firebug brought a whole new level of inspection: The ability to see which stylesheet rules were introducing specific styling on an element. Not to mention the ability to edit the rules in-line (along with disabling them outright).
This level of inspection completely overhauled Web Design – and has been able to detach many web designers from their IDE-of-choice into a more agnostic view of CSS design. Absolutely the biggest short-coming of this feature is its inability to work cross-browser (although, that argument can certainly be used for most Firebug features).
Network Performance
Firebug’s network tab gave developers the ability to see – in very real terms – two things: 1) How long a resource was taking to load and 2) How the loading of that resource was blocking the loading of other resources. #2 is especially important, seeing that the execution of JavaScript blocks other actions from occurring can be an eye-opening experience to most developers. Or even seeing how a slow-loading stat tracking script can prevent the further display of the page.
XMLHttpRequest Inspection
While XMLHttpRequest use existed prior to the existence of Firebug it was horribly hard to debug – it was rarely obvious where errors were occurring – on the client-side? on the server-side? in the transmission? The ability to see how the requests occurred – and very importantly – how long they took (and even how frequently they occurred!) has done much to improve the overall quality of Ajax use on web pages.
JavaScript Debugging
I would’ve said that JavaScript Debugging was a piece of that equation, as well, however Venkman definitely lead the way, in that respect (and has been a de-facto debugger for quite some time).
I’d argue that these trends wouldn’t be where they are right now if it weren’t for Firebug – and that tools are the primary reason for a development strategy’s success. As a corollary look at the relative success of web standards – I’d argue that adherence to HTML or CSS wouldn’t be where it is today without the tools to verify a page’s compliance.
How to Improve
The question now becomes: What are the next set of tools that Firebug can introduce that will revolutionize its respective areas of development?
I’d like to propose a couple, possible, areas of interest:
JavaScript Library Analysis
As it stands Firebug’s JavaScript function analysis is, perhaps, too finely-grained to provide help in many instances – especially when the use of JavaScript libraries is at play. For example, when using jQuery, you’re generally more concerned with finding out how fast, or slow, a particular method is – or a selector – not the performance of all the individual internal methods of jQuery.
I began some of this analysis with my Deep Profiling jQuery Apps experiment but that’s really only a test. Smart integration of JavaScript library knowledge into Firebug can provide significant details about how your code should be performing.
Visual Performance Profiling
Application performance profiling is rather clumsy right now, we have a number of disparate resources (network performance, rendering performance, script performance) that we need to mentally merge to create a full picture of what’s happening. To counter this I’d like to propose a way of visually viewing how components of a site affect its overall performance. Perhaps a way to break things down like this:
- Header: 300ms: 20ms Transmission + 20ms Parsing + 60ms CSS + 200ms JavaScript
- Google Ad: [BLOCKING RENDERING] 600ms: 20ms Transmission + 20ms Parsing + 20ms CSS + 240ms JavaScript + 300ms Frame Loading
- Sidebar: 400ms: 40ms Transmission + 40ms Parsing + 80ms CSS + 240ms JavaScript
The YSlow Firebug plugin already provides some level of analysis on your site – but it’s much more holistic (giving you generic tips for files and pieces of code). Whereas a more specific approach would be greatly appreciated.
Ajax Improvements
We currently have the ability to view XMLHttpRequests as they occur, which is great, but some additions could be made that would serve to be quite helpful, such as:
- The ability to manipulate a request and re-submit it. If you’re attempting to see how different inputs will affect your site, this would be a great way to play back requests or see how they can be best improved.
- Right now Firebug only lets you know the basic textual output that’s coming from the server-side. Having it be able to tell you if incoming XML, JSON, or even HTML is syntactically correct (and even being able to navigate the resulting structures – as the browser would see them) would be a huge boon. As it stands it can be quite frustrating to receive a slightly-malformed response from a server and be stuck trying to figure out what’s going wrong.
- Better JSON/JSONP integration is essential. There are a large number of Ajax requests being done through dynamic script tag injection – and those are completely unmonitored by Firebug’s XMLHttpRequest tracking. Being able to see what requests and responses look like – and where errors may be occurring – would be immensely useful.
Rendering Performance Analysis
While we have fantastic tools for digging in to the performance of JavaScript – CSS is a complete unknown. How much overhead do our stylesheets provide? How many elements does this CSS rule affect? Does this rule cause a costly reflow to occur? and how many times? How long does it take to render a particular portion of a page? Would changing the structure of my page help to improved perceived rendering speed?
Virtually all of these questions are un-answered and we need a tool to help provide a solid response.
Security Analysis
Security is one area that has seen virtually no attention in the respect of user tools. Most developers have no idea how secure their web site is or how vulnerable it may be to attacks. There needs to be easily-accessible tools for testing:
- SQL Injection attacks
- XSS Injection
- Susceptibility to Spoofing (Data Encryption)
At the very least. The problem here is that while these tools will be incredibly useful for developers to improve their web sites – it’ll also encourage malicious behavior. Although, arguably, those that wish to be malicious already have the tools to do so.
Standards Integration
Inline support for analyzing the standards-compliance of a page. Being able to see notes next to specific elements, attributes, CSS rules, etc. that show information on how they don’t comply with particular standards – or even how they could be improved to match standards.
This includes inline strictness warnings for JavaScript (produced by the JavaScript engine).
I think that compliance should go a step further, as well, and look to provide information on Microformat and RDFa compliance – pointing out specific errors and helping sites to become better formatted.
Finally – RSS and Atom standards compliance. Notifying a developer that their site’s RSS/Atom feed is malformed would allow them to immediately make a more compliant feed (a common area of mistakes).
Internet Explorer Support
The final, and perhaps most difficult, item that should occur would be a port of Firebug over to Internet Explorer. Both Safari and Opera have web developer tools integrated into their browsers – however Internet Explorer still consumes a majority market share and there’s no good tools in sight. (I, personally, use CompanionJS but it’s still a far cry from the full suite of utilities that Firebug provides – especially in the realm of DOM/CSS.)
This could probably be remedied if there was a really good pure-JavaScript Firebug (although the overhead associated with many of Firebug’s features would lead to an astronomically-sized implementation). The current “Firebug Lite” is something of a joke – only vaguely functioning in modern browsers.
Not only do I want to see Firebug improve – it’s imperative that Firebug continue to improve, for the sake of web developers everywhere. If it simply stalls and works into a stasis of bug fixes then web developers will be stuck with the current set of tools for quite some time. While other browsers are improving at a rapid pace, it’ll still be quite some time before they are able to match the current feature-set of Firebug.
Since so much of web development ecosystem is currently linked to the health of a single tool advances have to be made now and they have to be made quickly in order for the web to flourish and survive as a development medium.
Bramus! (July 1, 2008 at 11:07 am)
A killer feature is Color Syntax Highlighting of the JS code; Already made possible by rainbow4firebug Firebug Plugin ;)
Tane Piper (July 1, 2008 at 11:07 am)
What a great list of suggestions John!
Visual Performance Profiling sounds like a great idea, and since Firebug is a JavaScript application, could this not use something like jQuery flot or even processing.js to provide the visual element of this?
Also, I would love to see the Deep Profiling stuff you provided integrated too.
Tane Piper (July 1, 2008 at 11:08 am)
@bramus! Yes, I just discovered this plugin too!! It should definitely go into the core, makes things so much easier.
Robert Accettura (July 1, 2008 at 11:11 am)
Not a bad list. Personally I think Security Analysis would be best suited with the also awesome Web Developer toolbar under the forms menu. It already has some useful tools including converting POST to GET etc. etc. XSS checks would be a nice addition.
Just my $0.02.
Sam (July 1, 2008 at 11:16 am)
For IE try http://www.ieinspector.com/dominspector/index.html
Sam (July 1, 2008 at 11:16 am)
As for rainbow4firebug it totally ruins debugging.
Douglas (July 1, 2008 at 11:24 am)
The Developer Tools that are being released with IE8 certainly seem to me to be a (Firebug-like) step in the right direction, even if they’re two or three steps behind.
Jeff L (July 1, 2008 at 11:52 am)
I agree that I’d love to see some new features moving forward.
However, I think it’s fantastic that people are now developing extensions for the Firebug extension. Things like YSlow, Firecookie (which I love), Rainbow4Firebug (which I just learned of, thanks) add great functionality but only for the folks who want or need it. I’d suggest we keep the Firebug core smaller and add some of the new functionality through more addons. This keeps the interface uncluttered as well.
Already, Firebug can be a bit daunting for a newbie to start using.
Nosredna (July 1, 2008 at 12:01 pm)
Jeff L,
Is Firecookie different from the cookie stuff that’s already in the latest Firebug?
I haven’t done any cookie stuff in a couple weeks, and Web Developer had all I needed.
Patrick Haney (July 1, 2008 at 12:15 pm)
It’s funny how most of the things you talk about here have nothing to do with what I use Firebug for, but I guess that makes sense considering that you’re a JavaScript guy and I’m a CSS guy.
My real problem with Firebug is that it slows down Firefox considerably, to the point that I’ve now made Camino my everyday browser and only launch Firefox when I need to do design/development work.
However, I still think it’s an invaluable tool for figuring out what’s wrong with a website, even for designers. The simple ability to right-click and select “Inspect element” to show me what CSS rules are being applied and inherited is key. But I’d love to see more features for CSS, including what you mention above with rendering performance analysis. It’d be nice to see how different CSS rules or nested HTML elements are effecting the browser’s rendering of the page.
Anyway, great write-up on Firebug and definitely a good list of enhancements that could be made to make our lives easier.
Bruce (July 1, 2008 at 12:17 pm)
IE8 has some nice built-in (or shipping-with) dev tools. Firebug has certainly opened some eyes on the IE team.
John Resig (July 1, 2008 at 12:18 pm)
@Tane Piper: It could absolutely use something like Flot, Plotkit, or Processing.js
@Robert Accettura: That’d certainly be a good place for it, as well. Although, at this point, I think it’s safe to say that the market penetration for Firebug has far exceeded the web developer toolbar. Not to mention the fact that Firebug can provide much-better output (such as being able to show you were validation errors occur, in the source, without taking you to a new page).
@Sam: I had tried that IE plugin however I wasn’t terribly impressed – it still has a long ways to go.
@Douglas: Yep – I definitely agree. It’s a step in the right direction – but really just the first step up a long flight of stairs.
@Jeff L: The point is not that these features exist (having them would certainly be useful) but that they must be included in an attempt to reach a wider audience. The only way we can achieve great advances in web application performance, or web security, etc. is to disseminate tools to the general web development public that’ll make that possible.
@Patrick: You should examine Firebug 1.2.0b4 in Firefox 3 – all of the features of the extension are disabled by default and you have to selectively enable them on an each site – which means that the overhead of using the plugin is virtually none (as opposed to the old Firebug 1.0 in Firefox 2 – which was quite harrowing).
Bertrand Le Roy (July 1, 2008 at 12:26 pm)
As some have pointed out, IE8 includes a Firebug-like set of tools out of the box. It’s still lacking the network analysis, but it’s getting there. The debugging support in Visual Web Developer (which is a free download) is also a great help on IE.
One tool you might want to take a look at is Fiddler (which afaik works with all browsers as it works as a proxy server).
Rob Hudson (July 1, 2008 at 12:49 pm)
One wish I’ve always had is to be able to inspect a DOM element and know which Javascript events are attached to them, similar to inspecting a DOM element and seeing what CSS styles are applied.
John Resig (July 1, 2008 at 12:52 pm)
@Douglas, Bruce, and Bertrand: While having the new developer abilities in Internet Explorer 8 will certainly be a welcome respite we still need a lot of help for IE6 and 7 (which, collectively, have the dominate market share of all browsers). Considering that it’ll still be a few years before that occurs we’ll need some help in the meantime.
@Rob: I definitely agree with you on that – I completely forgot to write that up.
Renaud (July 1, 2008 at 1:20 pm)
One of the things I would really appreciate with Firebug would be the ability to see the requests that are happening inside iframes, however I’m not even sure this is feasible.
The only way I have right now is using a local HTTP proxy to dump the req/res cycles, but this is far from convenient, or maybe I missed something and there are already easier ways to do that? :)
Ralph (July 1, 2008 at 1:22 pm)
I agree porting it to other browsers would be awesome. IE has the web developer toolbar but it doesn’t even come close to the ease of inspecting a page like Firebug does.
I am with Patrick on this one, I use Firebug as more of a designer with the HTML inspection. I love to use the console to help me figure out my jQuery selectors.
Color the javascript code would be good too.
And the ability to see what events are attached to DOM elements. Would that include jQuery code as well? For instance: $(“a”).attr(“href”,”http://www.damnralph.com”); do you envision that showing up as an attachment to a DOM element? I am not sure if you can consider that an event.
John Resig (July 1, 2008 at 1:29 pm)
@Renaud: That’s a good point about iframes – it can be quite tricky to figure out what exactly is happening with a request (I’d lump that in with XMLHttpRequest and JSONP improvements).
@Ralph: The event binding has more to do with event listeners, bound like so: $(“a”).bind(“click”, function(){}); If you’re not using a framework there is no way to determine what functions are attached to an element – which can be quite frustrating.
Kevin H (July 1, 2008 at 1:53 pm)
I’d prefer a more integrated solution like Firebug, but Fiddler + Visual Studio 2008 meets a decent percentage of my day-to-day needs for working with IE6 and IE7.
(Microsoft Script Editor 7, which ships with Office, is also a usable substitute for VS.2008)
Wade Harrell (July 1, 2008 at 2:09 pm)
It is unfortunate that FF3 is proving to be such a huge step backward for JavaScript development. Just days after installing FF3 I find myself primarily working in IE7 when developing. Why?
What happened to “open script in new tab” in firebug?!? Why does FF3 insist on downloading js files instead of viewing them in the browser? Why is FF3 so aggressive about caching js files, particularly if frames are involved?
Mozz has made it impossible for me to test my code while I am working on it with FF3; and after spending a day looking for even a mention of this somewhere online I find nothing. Firebug is only valuable if its container works.
Jan Odvarko (July 1, 2008 at 2:17 pm)
@Renaud: Firebug’s Net panel should already display requests that are made from within an iframe, see this test-case:
http://www.janodvarko.cz/firebug/tests/iframerequest/page.htm
I would be interested to know more about what exactly do you mean, if this isn’t the case.
Honza
John Resig (July 1, 2008 at 2:22 pm)
@Wade: “What happened to ‘open script in new tab’ in firebug?!?”
I’m not familiar with that feature – perhaps there was a conflict and the developers removed it?
“Why does FF3 insist on downloading js files instead of viewing them in the browser?”
That’s definitely not the case for me – it ultimately depends on the file type that’s specified by the server. Do you have an example of a file type that changed in Firefox 3?
“Why is FF3 so aggressive about caching js files, particularly if frames are involved?”
Do you have an example of this? I don’t think there’s been any change to how aggressive the caching is in Firefox 3, explicitly.
@Jan: He’s talking about showing it like a normal XMLHttpRequest – so that you can track which headers are sent and what the full response is from the page.
Nosredna (July 1, 2008 at 2:30 pm)
>>Mozz has made it impossible for me to test my code while I am working on it with FF3; and after spending a day looking for even a mention of this somewhere online I find nothing.
Interesting. You must work in a different waay that I work. For me, debugging under Firebug in FF3 is no worse than under FF2.
With one exception… I think there’s a bug in Firebug or FF3 that causes my (rather large) app to sometimes grind to a halt for minutes at a time. This does not happen in other browsers, or in FF2 with Firebug.
I haven’t been able to pin down the cause yet, but it sucks.
FF3 does seem to have some serious bugs. I assume these will get fixed quickly because when FF3 dies, I always get an error reporting window that sends the troublesome URL to Mozilla.
If there are any Mozillaheads here, that’s me who keeps dying on the Nikhil Kothari’s Script# pages when running on XP.
Robert Wetzlmayr (July 1, 2008 at 2:44 pm)
For IE 6, 7, and 8 as well, Microsoft’s Developer Toolbar provides DOM/CSS inspectors which in my book don’T leave a lot to be desired.
Wade Harrell (July 1, 2008 at 3:46 pm)
ok, a few more specifics:
For work I run WebLogic and XAMPP on my desktop machine to code for the various projects I am involved in.
The XAMPP sites are working as they did in FF2 so that
http://localhost:8780/jslib/jquery/jquery-1.2.3.min.js
still opens in the browser window.
Unfortunately the WebLogic sites are not. (they worked in FF2)
http://localhost.mycorp.com:7001/jslib/jQuery/jquery-1.2.min.js
gives me a file save dialog “Opening jquery-1.2.min.js”
“You have chosen to open
jquery-1.2.min.js
which is a: JavaScript Source Code
from: http://localhost.mycorp.com:7001/”
This is the same dialog I get if I attempt to open a local file
file:///C:/Projects/localsite/src/jslib/jquery/jquery-1.2.3.min.js
Obviously WebLogic is doing something different than XAMPP, it is unfortunate that FF3 is dealing with this differently than FF2 did.
BTW http://www.bea.com/content/scripts/hp_data_tl.js also breaks so I do not think it is just my personal instance of WebLogic.
The WebLogic projects are also where I am having the caching issue. No matter how many times I shift+reload my changes to the js do not show up. IE7 gets them right away.
p.s. in FF2+Firebug if you right click the name of a script there was an option to open it in a new tab.
Jonathan Snook (July 1, 2008 at 8:17 pm)
Two of your requests I currently handle with other tools.
> “The ability to manipulate a request and re-submit it.”
For this, I use Live HTTP Headers. You can trace GET/POST calls and re-submit them.
> “Right now Firebug only lets you know the basic textual output that’s coming from the server-side.”
Somebody else mentioned Fiddler but I love my Charles. It can inspect XML, JSON and even AMF traffic and break down the object structures for you.
James Dempster (July 2, 2008 at 4:10 am)
@Nosredna
Even though your running FF3 are you running the updated Firebug addon for FF3 (@see https://addons.mozilla.org/en-US/firefox/addon/1843) this addon for me doesn’t slow FF down at all. Where as Firebug 1.0 for FF2 caused some real slow downs. So I’d have it disabled for all domains, and just enabled it for domains I where debugging.
James Dempster (July 2, 2008 at 4:13 am)
For altering data and resubmitting it there’s always Tamper Data (@see https://addons.mozilla.org/en-US/firefox/addon/966) it would be pretty cool to see that in Firebug.
Nosredna (July 2, 2008 at 1:06 pm)
Yes, I am using the latest Firebug.
The add-on has updated twice since I started running it. It’s possible the most recent update has fixed the problem–I have not checked. The first one didn’t.
Wade Harrell (July 2, 2008 at 1:24 pm)
FYI:issue resolved @ forums.mozillazine.org
http://forums.mozillazine.org/viewtopic.php?f=25&t=715045&p=3699825
Requires a bit of customization in the WebLogic configuration. Less than ideal, but apparently FF3 is more strict with content-types
Rik (July 2, 2008 at 5:59 pm)
For the performance part, you should take a look at the Profiler in WebKit nightlies. It displays the calls in a tree so you only see the big calls (the one in your application) but you can go deeper by expanding the tree.
The Network panel is also interesting since it also displays the time between the request and the start of the response. And the sorting options are nice too.
I also like the f
Of course, this is still under development but it’s already quite useful.
Rik (July 2, 2008 at 6:00 pm)
Submitted too early…
I also like the console who is always displayed. In every tab, you can hack some javascript.
dolphinling (July 3, 2008 at 12:43 pm)
Just a note: “…Firebug brought a whole new level of inspection: The ability to see which stylesheet rules were introducing specific styling on an element.” isn’t quite true: the DOM Inspector had that feature first. And if that isn’t the most useful web development feature ever, I don’t know what is.
Paulo Neves (July 3, 2008 at 11:03 pm)
Nice tips. It’s nice to read about other developers like in Firebug. I always feel overwhelmed by the number of features in Firebug. Maybe you should dedicate more space to firebug in your new book
Ilmari (July 9, 2008 at 6:06 am)
One simple addition that’d help catching one nasty category of bugs would be monitoring globals. I’m currently doing the following in my test runner:
CurrentGlobals = []
for (var i in window) CurrentGlobals.push(i)
setInterval(function(){
var newGlobals = []
for (var i in window) newGlobals.push(i)
var added = newGlobals.diff(CurrentGlobals)
var deleted = CurrentGlobals.diff(newGlobals)
if (!added.isEmpty())
console.log("New globals: "+added.join(", "))
if (!deleted.isEmpty())
console.log("Deleted globals: "+deleted.join(", "))
CurrentGlobals = newGlobals
}, 1000)
So if I do the following:
(function(a){
for(i=0; i<a.length; i++) a[i]++
})([1,2,3,4,5])
I get “New globals: i” in the console.
Don (July 19, 2008 at 1:44 am)
For IE (including 6) users you should give http://www.debugbar.com/ a chance. It’s really better than nothing. And at least it helps to see which css gets overridden, used and so forth. No dynamic css stuff. But better than nothing and 100 times better than the developer toolbar for ie.
C4 (July 20, 2008 at 11:01 am)
I would love if Firebug let me edit some of the javascript, then reload with the edit’s being run.
BTW I’ll vouch for Charles as well, I’ve been using it for 7 years and it is a great tool.
an0n1 m0us (July 20, 2008 at 11:15 am)
There’s a few of the basics that could be improved.
For example being able to view untouched except syntax-highlighted source in the Firebug UI at 100% width would stop me having to constantly still open the view-source window. This would especially be the case if standards inline were used. At the moment the only reason I view source is because HTML Validator lists the validation details in view source and also I still don’t trust anything as much as view-source, especially when firebug performance lags because it doesn’t handle converting large pages into a DOM tree without a performance hit.
Generally the command line (console) could be improved as well. The remembered commands are fun but only work in single line mode. When the console is expanded, this feature is lost. Also in a crazy world, Firebug could auto-detect-and-complete function and variable names from the page’s DOM node nomenclature.
the find / search box could be more consistent with the current Firefox theme and functionality. I don’t understand why there’s not a little red X icon for easily clearing the current search term.
an0n1 m0us (July 21, 2008 at 6:42 am)
For anyone mystified by the reference to “Charles”, I found this:
http://www.charlesproxy.com/
Jean-Philippe Martin (July 31, 2008 at 7:56 am)
Since page reflow is so consuming in resource, i would be great that Firebug gives a reflow profiler or something like this :
http://video.google.com/videoplay?docid=-5863446593724321515
Lalit Patel (August 16, 2008 at 6:01 am)
I completely agree with you in this one. I strongly believe that the recent advancements in web and web2.0 can be to some extent attributed to Firebug.
I use the YSlow and the CookieBug and I like them. I have decided to spend some of my time in firebug extn. development.
*Good to hear that Mozilla is adopting Firebug.