Our team has basically abandoned Firefox in favor of Chrome. Our team consists of front-end, HTML/JS/CSS types as well as server-side devs. I'm surprised, but every member of the team independently has punted on Firefox. For some, it was the extensions. For others, it was the RAM consumption.
With the new release schedule, it seems every time I would open FF with a new version to pull, some extension no longer works. It's purely anecdotal, but it was enough to annoy the bejeezus out of us that we simply switched over to Chrome.
I abandoned Firefox for Chrome simply because it drove me nuts with software updates. It seems like every time I'd open up Firefox, there was an add-on update process and sometimes Firefox updates to install.
Chrome just stays out of the way and provides updates with all the crazy pop-ups.
The "default" today should be to install updates silently; not pester users with messages about why they should upgrade (I'm also looking at you Apple).
Firefox was becoming slow for me and a real pain to use, until I lowered the browser.history_expire_sites in "about:config" from 40k down to 10k. I'll probably lower it even more. http://kb.mozillazine.org/Browser.history_expire_sites
I have found the Chrome dev tools to be much better usability-wise than anything Firebug had to offer. I also find it suspicious that Firebug is so heavy in terms of performance & memory, compared to the always-enabled chrome dev tools.
Anyway it's good to see Mozilla is investing in this area by integrating tools right in the browser. Keep it up!
Interesting. I have found Chrome dev tools to be much harder to use with all the icons colorless and looking the same I always have to hover to find out what are they doing. The watch window for script debugging is also done better in firebug.
However, Chrome's developer tools do work better - Firebug sometimes closes spontaneously.
I actually thought the same before I took a long, hard look at Chrome's dev tools one day. If you're used to Firebug, everything should be nearly identical, however, the snappiness of Chrome is significantly different (at least as of 1.8.3 and 1.8.4). I remember, however, the UI feeling quite different a versions ago, but I don't use Firebug as regularly as the Chrome developer tools.
Also, this especially goes for frontend and javascript devs, having the Javascript console mapped to ESC on Chrome on every tool tab is a huge feature.
Aside from that, though, I feel that for most developers the differences are nearly negligible (though I obviously cannot really speak for "most developers"). I'm curious to see if I'm completely wrong on this.
I generally agree. The primary thing I find myself going back to Firebug for is debugging ajax calls, since I get the fully expandable request / response info inline along with console output. Chromium can show that an ajax call was made inline, but the link goes to the Network tab, and unfortunately doesn't auto-select the referenced call.
I upvoted you because I agreed; AJAX was what I went back to Firefox for.
However, a different comment in this thread mentioned the Chrome Developer Tools preferences (a little gears icon in the bottom right corner), which I'd never noticed before.
Sure enough, clicking it revealed the options 1) Log XMLHttpRequests and 2)Preserve log upon navigation. Checking those (which were unchecked by default) gave a HUGE amount of info on the AJAX calls that I just tested.
Maybe it's not what you're talking about, but it was a big find for me.
You can set it to add a line to the log when ajax calls are made, and fortunately a trace for where they are made from, but you have to go to the Network tab and click on the actual request to see the details. Clicking the link within the console output provides will take you to the tab, but not the request.
It's close - but not quite there. I prefer having it all in one place, but just having the link lead to the actual Request on the Network tab would be great.
I often have the network panel split with console, which gives access to everything. You can limit the network calls to XHR as well if that's all you're looking for.
What I miss most about Firefox isn't Firebug but Web Developer Toolbar. Chrome inspector is very comparable to Firebug but the Chrome version of Web Dev Toolbar is buggy and limited.
There are so many useful tools built in (e.g. ruler, view ancestors/descendants, live edit CSS) that I can't bring myself to fully switch to Chrome.
Interesting/worrying comment at the end about the future of Firebug alleging there is only one developer working on it and Mozilla have all but abandoned it. Anyone able to confirm/deny/comment on the matter?
Firebug isn't 'owned' by Mozilla, and hasn't ever been, however Mozilla has contributed financially to it's development for some years, and still is.
In addition to supporting Firebug, we're also experimenting with alternative developer tools.
It's my belief that most developer tools just present the user with the information that was given to the browser in the first place, and that we can do a lot to explain how the browser actually understands all that stuff. The native developer tools are a step in that direction.
> Firebug isn't 'owned' by Mozilla, and hasn't ever been, however Mozilla has contributed financially to it's development for some years, and still is.
Sure, Mozilla supports the development of Firebug, but as far as I know it does not make Firebug classified as "a Mozilla project", it's a (very popular) third-party project with support from the Mozilla foundation is it not?
Just to clarify, while I am the only one full time developer, there is bunch of other contributors that are doing great work on Firebug!
I am also a member of the Mozilla dev-tools team and one of the Firebug's goals in the future is to reuse Firefox built-in tools and components. This way, we can reduce amount of work on Firebug side and also make sure that APIs of these built-in tools are well designed.
So, Firebug would still be a Firefox extension, but built on top of much better APIs, adding advanced features (e.g. those that are not suitable to be natively in Firefox).
It's also an advantage for other dev-tools that can appear (as Firefox extensions) - especially for those that integrate with Firebug.
That comment taken out of context can be quite alarming, indeed. Firebug, until recently, had two developers who were paid to work full time on it (jjb from IBM and Honza from Mozilla) and a number of people who contributed in their spare time. Now it's down to one full-time developer paid to work on it (Honza) and a number of people who still contribute in their own time.
It's a shame there's no good in-browser HTML validator (for any browser, so far as I can tell). HTML Validator used to be perfect, but Firefox started changing too rapidly for it to work consistently, and the current version only works on Windows (!).
Does anyone know of a browser/plugin combination that validates pages automatically (preferably configurable to run only on localhost)? The original HTML Validator was perfect, with a small icon in the bottom right of the screen indicating valid or invalid. Total Validator is OK, but it's not in-page, so that (for example) it's very difficult to validate pages behind a login wall.
I'm in the same boat as you. My computer at work is a Mac, and I was unable to use the HTML Validator plugin. The solution is to go to the plugin's forums - http://www.htmlpedia.org/phpBB/viewforum.php?f=11&sid=e9.... One of the guys there has been really good in taking the origin plugin and compiling it for other operating systems.
Just to be clear, Firefox doesn't have a validator built-in. It's just syntax highlighting, and it has recently been enhanced to use the same HTML5 parser as the rest of the browser. So yeah you can see some of the errors you might make in your markup but it's very far from what an actual HTML5 validator should do. It doesn't even report all parse errors (and isn't meant to).
I'm pointing this out because of a recent blog post by Mozilla dev Henri Sivonen which says: "Please do not advertise the new View Source implementation by saying that Firefox now has a validator in the View Source window."
Unfortunately, I am totally unfamiliar with any of the alternatives to Dragonfly. And the selling points would read like the feature list of any debugger. All I can really say is that with Dragonfly, I don't mind working with JavaScript anymore -- it is tightly integrated with the browser and does its job well.
I've been using LiveReload+Guard for this on Rails projects. It'll reload CSS as soon as the file changes on disk without any keypress required. If necessary it'll reload the whole page. It's very handy.
There's a 2.x version that's a standalone OS X app and handles compiling a bunch of things like LESS, Sass, etc. but I haven't used it.
It's not Firefox-specific, but if inspecting and modifying HTTP requests/responses is what you want to do you should try Charles ( http://www.charlesproxy.com/ ).
I'm not sure that anyone has a definative answer to that question right now. The new tools are interesting because they do things in a different way, but there is a lot they don't do, so we're supporting both.
It's possible that one day Firebug will be totally superceeded. It's possible that both tools will have separate audiences for some time. It's possible that the new native tools will be a total flop (although I have a vested interest in making sure that doesn't happen!)
Bringing the new functionality into Firefox, where it can be more exhaustively slimmed down and the primary team is responsible for it makes sense to me.
Heck, if the basic functionality is there then Firebug can be written to take advantage of those APIs, which would be a win all round.
I am hard working to fix all Firebug memory leaks (and did fix some of them recently). What I really need is a simple scenario showing that Firebug leaks. That helps me a lot!
How am I to tell whether leaks are from Firefox or Firebug? What I know is that after a full day developing Firefox will use 800MB of RAM, and the only way to get rid of that is to close the entire process. I use Firebug heavily and I know that _something_ is leaking somewhere.
That's nice to hear! I'll take a look on how to help.
As mkopinsky points out it's sometimes hard to tell what really leaks memory.
I can tell the same thing as he, but I think it has been improved a lot lately. Sometimes I had after some time working around 1.5GB Memory usage, but this is better now.
The only thing I open Firefox for anymore is SQLite Manager. What really made me fall in love with Chrome developer tools is using them to write Chrome extensions.
I made a clean Firefox profile and installed and enabled everything in the selection except the Firebug addons and the HTML validator, which does not support Linux. That is, 47 extensions in total. The machine is an old box from 2004 with an AMD64 3000+ processor and 2 gigabytes of RAM, running Debian Sid 64bit. In this old box, with all 47 extensions enabled, Firefox starts in less than 5 seconds and takes about 175 MB of memory.
But even if installing 47 extensions brought Firefox to a halt, why would you need to install all of them? This is simply a collection of recommended extensions, not a set that no developer can do without.
With the new release schedule, it seems every time I would open FF with a new version to pull, some extension no longer works. It's purely anecdotal, but it was enough to annoy the bejeezus out of us that we simply switched over to Chrome.