I like the firefox tools and use them a lot. They kept getting better and better but recently seem to have plateaued. I keep running into things on ocation that make me switch to chrome to debug. I sound a little cranky and ungrateful, but the firefox dev tools are good and I like the way they're set up, but when I can't get my breakpoint to stop javascript execution and I have to switch browsers I get a little sad.
Looking quickly the developer edition seems to fix some other little things (the return of Labeling margin, padding, border on the box model and the ability to edit the box model in place).
I'm always a little leery of special editions as it was good to develop on the browser your deploying to.
Developer Edition is a pre-beta version of Firefox (the core code goes from Nightly -> DevEdition -> Beta -> Release, much like Chrome goes from Canary -> Dev -> Beta -> Stable). DevEdition also ships with some more minor customizations to ease development: a separate default profile, buttons in the toolbar for the Developer Tools, etc.
The plateau you're referring to is probably due to the team's focus this quarter on building the all new performance tool, making sure all the tools work with process separation (e10s), and trying to squash bugs around polish and stability. The next few quarters will likely see a return to pushing on user-visible features.
We also have an opening for a full-time interaction designer on the DevTools team. If you dig this stuff, or know someone who does, please consider applying at https://careers.mozilla.org/en-US/position/oLiW0fwJ
Do you have a timeline for getting proper (source-mapped) file/line numbers in the console (and performance tools, I just checked and it's absent from there as well)? This is currently the main reason I reach for Chrome when I need to write JavaScript. I see this bug marked devedition-40:
[member on the devtools team]
A strategy and implementation for source maps across all tools is something we're actively working on. It's frustrating for us as well when working on side projects, if that is any indication of how much we'd like to get source maps everywhere
These tools look fantastic. Off topic: the first video showed the use of the new tools and the improvements of using a web worker. I was reminded of how little I like the implementation of web workers in regard to needing to call out to an external script. The implementation would have been much better if it was possible to treat scripts in the same file as threads. I have seen hacks/workarounds to toString() functions and inject them into the DOM, but it is unfortunate that this is required for inline web worker use.
Finally my test page[1] no longer crashes my browser with the dev tools open, and appears to run the same speed with and without the dev tools open. I don't know if it's related to these changes but clearly it could be.
Edit: Actually it seems to not happen if I don't go to the "inspector" tab but go straight to the performance tab. Ah well, shame there seems to be a lingering issue but I'm happy that I have a workaround now anyway. (It used to crash hard on the performance tab too.)
You are also measuring parseFloat(hdn.value) - but I haven't measured how much of impact it is.
EDIT - Turns out it takes significant amount of time compared to the rest of the frame, more on chrome, a bit less on Firefox (but the timing profiles are very different on the two browsers).
Oh I know! I realised that later on when I reviewed the code but I gave up worrying about demonstrating the speed of DOM access* when it started to crash my browser! So I've left this version here for posterity.
* I wanted to demo to some people why it's better to write javascript that avoids going back and forth to the DOM all the time.
Seems like the Performance Tools is now on par with Chrome, unless I'm missing something. These tools are sorely needed for web developers, Nik Molnar's talk[0] on web performance is a great intro on how to use these in real world scenarios.
Will this at all help to help diagnose and maybe even fix why FF eats so much memory? I keep getting out of memory errors in windows and see FF eating tons of RAM & Virtual, and have no idea which is causing the errors or how to fix it.
Will it finally enable us to find an offending tab that is consuming too much memory or CPU? Or it's just a tool that can be used to build this functionality? Something like Opera 12 has in opera:cpu.
I’d love to have some end-user control to throttle tabs’ CPU/memory. In particular, if I have a background tab open that I haven’t brought to the front in a few hours (or longer), I pretty much don’t want it to get any CPU cycles at all until I explicitly look at it again, and usually I also want to have its open TCP connections closed, etc.
Firebug still has a better UI. The dev tools seem coming straight from the 90s (Chrome's ones too) but they feel faster. Advantages and disadvantages in functionality are mixed, but I end up using Firebug almost all the time. Unfortunaly I'm on a tablet now, if I were at the computer I'd give you examples. I wish the teams merge and give us dev tools with a Firebug UI and all the functionalities of the two tools.
I use Firebug simply because it's what I'm comfortable with and "used to". The UI, keyboard shortcuts and general expected behavior are what keep me locked in.
When debugging in Chrome/IE it's always painful to use the developer tools even though they are very capable.
At the computer now. Here is a comparison of the tools. It's not in depth and limited to what I usually use.
Inspector, HTML editing, Net panel: Basically the same.
Storage: you can inspect localstorage and IndexedDB with dev tools. You need https://addons.mozilla.org/en-US/firefox/addon/firestorage-p... for inspecting localstorage with Firebug. No IndexedDB support, but I never used it (localstorage is so much simpler) so I didn't search much. Firebug can delete cookies (maybe that's another extension, can't remember), dev tools can. It could be even, depending on what you use most.
Console: dev tools autocompletes functions. Inspection of variables is abot the same but Firebug displays more information without having to browse all the values tree. Firebug's console is multiline which is handy for typing in short scripts. However that means that commands run only with CTRL-Enter. I prefer Firebug.
HTML structure: the same but the dev tools bury the DOM tab into a right click menu. I prefer Firebug's UI.
CSS editing: the same.
Script/Debugger: almost the same but I prefer Firebug because of the way it displays information about the variables (similar to my reasoning about Console).
Aesthetics: Chrome and Firefox dev tools looks more primitive than Firebug to me but this is very subjective and I have a theory about it. Web and mobile have been moving to a minimalistic and flat design for the last few years. Having used computers since the 80s that reminds me of some designs of the 80s/early 90s. The flat Windows 8 desktop mode decorations are somewhat similar to the early Windows (check http://www.webdesignerdepot.com/2009/03/operating-system-int...) with obviously everything that more pixels, colors and animations allow. Still I can't feel it a bit deja-vu like some elements of fashion that came back after forty years (example: the brown color - Europe here, USA could be different). Younger folks will say that are Firebug's 3D buttons to look dated and I understand it. But just wait some 20 years and I bet you'll start having that feeling too :-) As I said: very subjective.
Summary: that basic functionality is more or less the same and the difference is probably more a matter of UI and habits than of technical merit. There might be some use cases where you need to dig into dev tools' options and enable more functionality. Dev tools win there.
> Firebug's console is multiline which is handy for typing in short scripts. However that means that commands run only with CTRL-Enter. I prefer Firebug.
Like with most similar consoles the Firefox dev tools allow you to create newlines with Shift+Enter
Disclaimer: I'm still stuck on FF31 for dev testing purposes (internal application targeting FF31 ESR), and haven't tried newer builds.
My biggest complaint about both Firebug and the FF Dev Tools is the way they list downloaded content files. FF Dev Tools seems to only have a flat list of filenames, which is ridiculous. Firebug has a dropdown that can be filtered by name, which helps, but is slow.
I'd always been a Firebug user, but I finally gave Chrome Dev Tools a shot a few months back and was sold by a combination of its speed and general usability. In this case, stuff like having an actual tree of content files that I can expand.
Also, to echo another comment, Firebug seems to go haywire every so often while trying to set breakpoints. Either the breakpoint symbol just spins and never actually sets, or when you reload the page it acts like you set the breakpoint on the last line of a module, etc.
Haven't yet tried out Firebug 3, as it requires FF35+.
Man, that was 7 versions ago! WOuld love to get your impressions of Dev Edition 40. FYI it will create and use a separate profile from your main Firefox profile, so there is no risk in trying it out.
I have seen this question a lot when Firebug vs. Developer Tools comes up ... for like years and years, since Developer Tools first dropped even. Now you've got me curious. Please reply with points I offer below that you HAVEN'T heard before.
1. Just make Find work right. I need global find, that's all I need. On what corporate drone planet is it a smart idea to prepend an exclamation mark to search terms to request a global find? Chrome makes the same mistake - The Search Company got Find wrong... (Perhaps Chrome ain't all that and a bag of chips!?)
MAKE CTRL-F DEFAULT TO GLOBAL FIND! [Scream your favorite cuss word now if you're with me on this!] One strike and you're out when you screw up something dead simple like Find!
I don't need file-catalogged search results where I stoke my chin and ponder all the matches; just go to each match by jumping around directly in the source, let me hold down Enter while you cycle through the matches and source files, let me know when we wrap around the search result list with a little informative "search results wrapped" pop-under - how do I describe my frustration?? FIND IS VERY UNPRODUCTIVE AND OVER-ENGINEERED IN DEVELOPER TOOLS. This is somebody's baby, I'm sorry to whomever if he is reading this - I just think simple is the key and that's what Firebug has going for it. Just do me a favor and toss the whole Find as you got it into an Advanced Find dialog box and give me simple, Firebug-style, rip n' roll global find in Developer Tools, PLEASE.
2. I know Firebug is an opt-in extension, so they have the right to do this, but ... Firebug puts that handy bug icon on the location bar for popping open the firebug panel. It's nice, appeals to my lazy muscle memory! I'm sure the Firefox Developer Edition does something similar (right??), and they wouldn't force me to go rummage the hamburger menu for their link in that version of Firefox. But, I'm too unmotivated to switch to that version of Firefox. I'm far too unmotivated to customize my location bar (except to remove the new Pocket icon, gross.) The firebug icon is beautiful, I want to click its button.
3. I like the tabs in firebug better than those in developer tools. The CSS inspector is great in Firebug, always has been very productive.
4. Breakpoints are hinky in Firefox in general, both in Firebug and in Developer tools. I've seen the JIT'er optimize away my line with a breakpoint in both environments, but in Firebug my breakpoints seem to 'catch' a little better.
I'd like to see a lot more work done on breakpoints in the debugger in general and have breakpoints (potentially) survive refreshes (or Webpack autoreloads) where the sources or script filenames have have changed. I suppose the debugger could achieve this linking my breakpoints to line numbers in sourcemaps rather than to the .js files themselves. If it already works this way, then I must be doing something wrong, because I am constantly losing my breakpoints when actively developing code that I am also stepping through.
5. Could we just have the Firebug UI atop the Developer Tools? Firebug has made Firefox unstable lately leading to stalls and shutdown timeouts. I would love to see Firebug team re-skin the developer tools with their UI and throw away the firebug kernel. The native integrations in developer tools are bound to do a much better job debugging than an extension like Firebug ever could. I thought I heard that this was the plan for Firebug.next, and I am all for it.
How about...open everything in Atom instead, so you can use what you're used to (or vim / emacs / ST / whatever), and have that be able to e.g. Set break points and inspect stacks? Separate the IDE from the browser so they can each evolve faster. Give and API to interact with the browser so anything can integrate with it.
Intriguing! If I ever get into an extended debugging session, I might try it.
I try to TDD my code (or at least write lots of tests to dig myself out of the hole), so I don't find myself doing heavy breakpoint debugging as much these days.
I figured it would only be fair if I stick it to Firebug a little bit too.
1. Having a dropdown for sources in the Scripts pane is unwieldy/useless for large sites with tens of different scripts. The Developer Tools get this most right by having a docked Sources/Call Stack navigation panel to the left of the source.
2. Inspecting a JS Object's value in the Watch panel pops over to the DOM tab to view it there. I've always thought that tab was oddly named and that made the transition confusing since I'm often not looking at DOM objects there. I think that tab should be named "Object" or "Object Viewer".
Ed: you should try ( and provide feedback to ) Firebug 3, they're dong exactly what you described - implementing Firebug UX on top of Firefox Devtools:
I really dislike how laptops (MB[P] or other) override the function keys with the laptop controls. I know you can usually set it to be Fn+F<key> to do things like volume, brightness but I think the function keys should keep their original uses first.
Yep, function keys were sacrificed so that manufacturers could drop dedicated keys for functions like volume and brightness. I personally think it was a good move, but as a consequence I rarely use the Fn+F* key combos in applications and my apps don't bind to Function keys.
Triple digit version numbers are just going to sound ridiculous. I really hope someone reigns this back in at some point.
I'm keen to test some of these new features out though. The tools in Firefox have always been a bit hit and miss for me and I've actually never went out of my way to use Chrome or Firebug.
Looking quickly the developer edition seems to fix some other little things (the return of Labeling margin, padding, border on the box model and the ability to edit the box model in place).
I'm always a little leery of special editions as it was good to develop on the browser your deploying to.