Web developers make the open web go.
For Mozilla, that means that if we want to see the open web succeed, we need to help web developers build it. When we talk to them about building for the web, most of what they want to talk about is web features – CSS improvements, new HTML5 goodness, content magic like geolocation and orientation events. We invest a lot in making those things awesome, but they are only part of the answer.
The other thing that web developers talk about is tools. Specifically, when we talk to them about tools they ask for two things:
- Mozilla should invest in Firebug. The Firebug and Firefox communities should be working together to fix bugs, not working around them. Firefox releases should ship with a compatible Firebug out of the gate, not weeks or months later.
- Mozilla should be leading in developer tools. Before Firebug, View Source and DOM Inspector were the state of the art. Now other browsers are copying Firebug and shipping their tools by default, and the question is where the tools are going to go next. We should be a strong voice there, and back it up with code.
For #1: got it. Loud and clear. Firefox 3.6 shipped with a compatible Firebug from day 1, due in no small part to the contributions of Mozilla employees paid to work on Firebug. Jan “Honza” Odvarko has been fixing bugs and building out features left and right, and Rob Campbell has helped drive the project, and made sure that Firefox dependencies get attention. We don’t want to try to take Firebug over; it has its own, healthy community. We are much more active participants than we used to be, though.
#2 is harder. What tools do web developers need that don’t yet exist? Which tools would be broadly useful, and which ones niche? What can Mozilla bring to the table, as the developer of a browser, to make the design & development experience better/easier/faster/funner? We’re trying to figure that out, we’re working on some early ideas that I’ll write about in subsequent posts, but I’d also like to hear what you think is missing.
Building developer tools into Firefox will mean a lot of exploration, and a lot of new code – that’s scary, but the benefits are huge. In the short term, this work will rekindle the conversation about developer tools, and get us all thinking outside of the existing boxes for a few minutes. In the long term, it should make life better for web devs and tool authors; everybody wins.
Web devs are smart, it’s no coincidence that #1 and #2 above pull in the same direction: make Firefox the best platform for web development and tool building. We all want web authors to have an awesome, empowered experience and I think working together in this way is the best play we have for continuing to build that.
meandering wildly 
Some kind of generic FirePHP style extension would be great by default, with a standard set of debugging headers Mozilla is meant to catch, like ‘X-Debug-Blah: JSONENCODEDDATA’
Awesome post 🙂 I can think of a million different tools I would love to create, but most of them are probably pretty niche.
Having experimented with The Burst Engine, (an JavaScript time-line based animation driver: http://burst.bocoup.com/), I can definitely foresee more use of web technologies to build tools that save time.
Stuff like Bespin and Processing.js are definitely a huge step in the right direction. I can’t wait to see what people come up with.
I actually got stuck debugging last night, and wished there was a feature to reload the previous state, except in “debug” mode, at the point where the browser last crashed.
Sorry to double-post… the link was http://burst.bocoup.com
A built-in “record-and-replay” tool in the style of Chickenfoot or Selenium IDE baked into the browser dev tools would be a huge win. Bonus points if you can actually run it from outside the browser, for integration into a test suite or CI infrastructure.
I don’t know if I have any great ideas for new, next-gen developer tools… but as far as the current tools are concerned, I consider the following tools absolutely critical:
Firebug
Web developer toolbar
YSlow plugin for Firebug
Firecookie plugin for Firebug
HttpFox
I would suggest working closely with those tool makers so that Firefox is designed and built in such a way that those tools can easily interface with Firefox.
For example, I’ve heard that the Firebug code is pretty nasty due to all of the hacks and workarounds they have to do to make it work. These kinds of things impede progress. It there were better APIs and hooks for the plugin developers, I think the tools would evolve faster and be more powerful.
<>
It would be nice, there is so many bugs to fix in firebug. Gathering forces together can be beneficial 🙂
Keep up the good work 😉
I’ve been doing a lot of work with Firefox as my UI platform for embedded touchscreen devices. I would really love to see the ability for Firebug to be able to connect to a remote Firefox session for live js debugging of systems like these where the browser chrome might not be visible/accessible (due to use of other extensions like r-kiosk). Think of it like a remote gdb session. Just my two cents.
Firebug is great, but maybe tighter integration with Firefox could solve the following:
Firebug adds a div at the end of the document body.
If you call console.info(), etc it will print file-name and line-number details. But if you want to wrap those calls you lose that info. eg if you call the following:
syslog.info = function(txt) { console.info(txt) }
the file-name and line-number will always be for where syslog.info is defined.
Firebug has not only led the way for web developer tools, it has also become the de-facto plugging point for 3rd party developer tools. And as you’d expect with an add-on-friendly platform underneath, there are many. The long list at http://getfirebug.com/downloads#extensions is testimony for that. So I don’t think #2 is that much of an issue right now, #1 matters much more. In the end #2 might just be a discoverability issue, and it could be solved by growing and integrating Firebug-the-platform.
That said, there’s one developer tool that’s a bit orthogonal to Firebug. Google Chrome recently grew the Timeline API which gives you profiling info about the innards of the browser (how much time is spent not only executing JavaScript, but also walking the DOM and drawing stuff, etc.). The SpeedTracer extension for Chrome can be used to analyse the data. With richer and richer apps (cf HTML5) we’re going to have end up doing the same kind of profiling for in-browser apps as we do for desktop apps. It’d be a shame if Chrome was the only browser to offer that.
One of the ongoing areas of JS optimization that’s difficult to handle outside the browser is reachability. With Google’s Closure compiler in advanced mode, you can (with copious annotations and other compiler specific tweaks) eliminate code that isn’t used in your project.
What I’d like to see from mozilla is something that would provide a list of all the functions reachable from the current page where the current page consists of inline scripts and whatever is attached to event handlers. This might not cover all possible javascript, but it’s close enough to be useful. Going from a list to actually cutting out the unused JS isn’t necessary, but the ability to get and easily export the reachability list to your minifier would be most excellent.
The ability to instrument have something like speedtracer (http://code.google.com/webtoolkit/speedtracer/) would be great. The pain in chrome is having to startup the browser in a different way. Ideally firefox would have a similar feature that would be toggled from inside the running browser session.
I’d like my changes to CSS in Firebug to get saved to my CSS files, so that I don’t have to make the same edits twice.
I would be interested in better webpage » save as functionality in firefox. It would be nice if when i found something cool and wanted to see how they did it, i could save the page including javascript, images, css, etc. and then be able to edit it on my desktop. As of now it works sometimes, but breaks very frequently. Firebug provides similar functionality, but if i get someone elses page working like I want mine to, then i still have to reproduce the results on my hard drive
What would I like to see?
An updated and modernized ‘View Source’ widget. It’s archaic. In-fact, here are 200 bugs spanning multiple years pertaining to the simple view-source component in Firefox: https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&content=view+source
Here’s my personal listing of ideas to improve View Source with 5 improvements:
Introduce proper syntax highlighting (crucially needed with the new HTML5 parser)
Links should have copy link location in the context menu
Line numbers should appear in a side column
Add view-selection-source ability
Interface should be tabbed
Just some ideas – it definitely could use a revamp
Echoing Philipp’s comments, I’m not sure if bundling everything into a single package is worthwhile when we have the powerful extension model that currently exists. There are far too many tasks and needs of your web-developer/designer/master/ninja for a single tool to provide all of the answers. Activation attempted to tackle some of these issues, but componentizing the features as extensions allow is far more compelling for the power users who wish for this level of control.
The discoverability comments are also spot on as there are two extensions Firediff (Shameless self-plug http://www.incaseofstairs.com/firediff) and Firefile (https://addons.mozilla.org/en-US/firefox/addon/52365/) that provide some or all of the features that Nicolas and Richard are discussing.
Then again I am a Firebug extension developer so I may have already bought in 😉
@nicolas: Good idea, though actually editing your remote files seems like it would be a huge (and possibly unwelcome) change in direction for Firebug.
However, if it would spit out some sort of file detailing the changes I’d made (a patch file or something more human-readable), or let me “download” the changed files (possibly with some notation of the changes), that’d be pretty sweet.
Firebug-from-AMO/Firefox compatibility rates the highest priority among Mozilla developers, but not so among general Firebug users. If you look at the adoption curve for Firefox 3.6 among Firebug developers you will see Web devs don’t jump on day one:
https://addons.mozilla.org/en-US/statistics/addon/1843/
This simply reflects the needs of developers: they need to work on the platform their users use now, not one they will use in the coming months. Professional Web development houses know they can use the pre-AMO versions of Firebug from getfirebug.com on up-coming Firefox releases.
I keep trying to explain this because the difference in priority leads to misunderstanding between the Firebug and Firefox teams.
@J.R.
“However, if it…let me “download†the changed files (possibly with some notation of the changes), that’d be pretty sweet.”
This is how the Smush.it image compressor in YSlow works. You download a zip with the new files in it, with the option to preserve directory structure. Download and merge, it’s great.
This would be highly preferable to edit > copy from FB > paste in dev file > save, for me.
1) Causal analysis of CSS properties. All too often I find myself playing the divide-and-conquer game in Firebug, selectively disabling rules to figure out why element X is red when I expected it to be blue. I’d love to be able to click on the element’s computed style “red” and see a filtered list of cascaded/inherited rules applying to just that CSS property.
2) Causal analysis of CSS selectors. When I make a mistake in a complex CSS selector, it can be hard to figure out what’s wrong with it. In Firebug, the rule simply doesn’t apply to the element, and I don’t know why. I’d love to be able to say “I expect rule/selector X to apply to element Y” and have Firebug suggest what might be wrong with my selector, e.g. “This element is not a child of LI, it’s a grand-child of LI.” “This element’s class is ‘received’ but the rule’s class is ‘recieved’.”
3) Causal analysis of CSS layout. I’d love another layout tab which gives a complete depiction of all of the parent elements that contribute to the position of a given element.
e.g. body margin 8px -> div padding 20px -> div absolute positioning 40px -> this div, margin 2px.
4) As Sean mentioned above, there’s still too many cases where Firebug will lose track of the original line numbers for logged messages and thrown errors. Many of these “bugs” can’t be fixed because the information is altogether lost. Keep that information.
5) Reliable code coverage metrics. I want to run automated & manual tests via Firebug and see what code was hit and missed, even when those tests span multiple pages.
6) Search by reference. Reliable search by reference is impossible in a dynamic language like JavaScript (“eval” alone makes the problem unsolvable) but just reliably logging the stacktrace when a given function is invoked can help.
7) Help me rename a JavaScript function. When the old function is called, modify the caller. If the old function is called in an “eval”, log it for me so I can make the change myself.
(As JR suggested, modifying files on disk may be too invasive, but generating a patch file or something would be great.)
8) Filtered DOM mutation breakpoints. Halt when a piece of code creates an element that matches a certain CSS selector or XPath.
“What tools do web developers need that don’t yet exist?”
Memory profiler. Big, glaring necessity. Being able to inspect objects and their dangling references and deduce the source of memory leaks will become vital as code complexity increase. And as more and more Real Developers ™ end up having to write js, they will really expect these sorts of tools.
I reviewing all of the aforementioned comments I have come to a few conclusions:
Having development tools/extensions integrated into a high performance browser is very much appreciated.
Not everyone agrees on which tools they wish to have access to.
I suggest that FF3.6+ ship with a “default” profile – no extensions & and customizable “development” profile – with a choice of extensions at installation time.
This would give a variety of developers many different options for creating “developement” profiles to use, all while maintaining the existing default functionality of FF.
just my 2.
Jonathan, I’ve seen the progress towards #2 and I am frankly very confused. The two things that I’ve seen you guys working on are a “console” and an “inspector” – two tools that are in Firebug today with those exact names. So I figured that they were going to replace Firebug or at least part of it but this post seems to say they are meant to compete with it. As I read the comments so far on this post from web developers, that is clearly not what they want – they talk about performance profiling, memory profiling, CSS analysis, code coverage, enhancing view source, record-amd-replay, dead code elimination, and that is a sampling from the 20 comments above. Of all the tools to work on, and all the things web developers are crying out for, why this?
You say the reason for #2 is “other browsers are copying Firebug and shipping their tools by default”. But what I think you miss is that they have no other option; none offer or will offer an extensions API powerful enough to let you build a Firebug-like tool, and so they have to integrate it. Mozilla doesn’t have to because web developers are more than savvy enough to download an extension. So I disagree that them building in tools is something Mozilla needs to respond to: it is a response to Mozilla. You get to pick what gets integrated and what doesn’t, while they don’t have that option.
So I truly don’t understand – Firebug has a stunning developer mindshare and brand name. It’s what replaced abort() debugging on the web. There is so much else to do in the developer tools space to do either as Firebug extensions or new tools outside of Firebug, and I think it’s very worrisome that the first step I’m seeing is a harmful one.
I am absolutely over the moon to read this sort of post. As a web dev Firebug has been the best piece of software I’ve ever used. No exceptions.
With the recent uptake since Mozilla started taking an interest in Joe Hewitt’s baby, the most impression aspect of Firebug has been the apparent engineering infrastructure built as the foundations that never seemed to be there initially. All those unit tests and so on seem to really have made a significant difference to quality.
The other great thing has been the level and frequency of information about the project that is being made available by the devs. The period of silence after Joe left Mozilla was ‘deafeningly’ scary. Not a release was seen for a long time until other browser’s made Mozilla look bad for not maintaining Firebug.
So it’s great to see movement, even if the release numbering is confusing as buggery 🙂
A function that could really help devs that might be built into Firebug is that of helping devs write JS code that will be run by tracemonkey or that is optimised in general. A first step here would be to get Firebug simply displaying which code is traced and with the upcoming method+tracing (mick) jaggermonkey it would also be great to know which code is being optimised through method as well.
@jjBarton
Personally I upgrade Firefox as soon as it is stable and my extensions are ready. If Firebug is not ready before a new version of Firefox, I will not upgrade.
Not too sure what you are trying to say about confusion b/w Fbug and Fx teams but I think Fbug should always be ready before new upgrades.
Re an ability to allow Firebug to save live changes to the remote files, I am absolutely desperate for this feature.
I don’t see this feature as “a huge (and possibly unwelcome) change in direction for Firebug” at all. Sure there are a lot of devs out there who use a variety of version control systems that may have trouble with it. However for all of us who FTP down files to an editor on our local computers and Ctrl + S changes straight back to the server, then have to reload the browser to test again, saving live edits would be a godsend.
Does anyone have any perspective on how much work this would take? Is it feasible to do this as a Firebug extension?
@Scot Garman: Have you tried Chromebug?
I still think a lot needs to be done with fixing the slowdowns Firebug can cause. I’ve had to move to using Minefield full time now, because on ff 3.6 its unusable at times, spiking to 1.2 gig of memory usage, etc.
Hi. Just following links from a google search and ended up at your 2006 blog on the bizarre ancient taxonomy of animals (shivering, belonging to the emperor, resembling flies, etc, etc). I just wanted to check that you knew – or at least now know – that this delightful list was created by Jorge Luis Borges, and then put into the fabulous context you quote (viz the chinese encyclopaedia etc). Borges did this a lot – pretending he had ‘discovered” things he had actually created. If you didn’t know that, then perhaps you don’t know Borges at all, in which case I envy you, because he is the most mind-stretching writer I know of, but not especially prolific, and it is all before you. All the best, Simon.