I have to be honest - I find the developer tools a pain: They aren't even close to replacing Firebug, yet they're more obtrusive. So I can't stop using Firebug, and I can't remove the unwanted built-in menu options. So for me personally, what I'd really like to see is either one of: - Match Firebug feature for feature - Allow for the dev tools to be completely removed from the interface Sorry, but it really does come…
Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
71–80 of 360 posts
Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
#72Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
#73Improve "design in the browser" capabilities. i.e. pushing CSS/HTML and maybe JS changes made in Dev Tools back to the source files without manual shenanigans in the middle.
I probably waste more time copying CSS / HTML tweak diffs from the browser back into the related source files than anything else with in browser dev tools. Due to the nature of 'losing changes' if I happen to hit refresh or if the page has some automatic polling mechanism I also tend to do this very often as some sort of manual 'save' action.
There have been a couple attempts to do this (http://www.cssupdater.com/ or https://code.google.com/p/backfire/). But, I'd really like to see a standardized protocol for pushing changes to the server such that server side frameworks can implement it appropriately.
For example a server side implementation for Rails needs to understand the asset pipeline to know how the final file was created so it can work its way back to the correct file to save changes to. This also means you probably need source map style support for LESS and SASS also. Also to change HTML template files the server side needs to know how the page was constructed so it can find the correct partial / template to save changes to. Which is probably really hard depending on how much state based conditional rendering there is in your templates, maybe the server side caches the last response and associated state to work around this.
Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
#74Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
#75Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
#76Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
#77I mean there is A LOT of people who routinely use Firebug. Heck, I am actually designing sites with it. So from my perspective the best thing moving forward would've been for Mozilla to adopt Firebug as a standard DevTool. Frankly, it pains me to see two almost identical tools being developed in parallel, while it would clearly benefit everyone much more if it were a single, unified effort, with freed up dev resources spent on something else.
Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
#78When I go in a tweak the CSS of various html elements, it would be nice to have those changes available somewhere (even if I reload). Even the ability to replay those tweaks after reloading. I need this to be able to move that css back to my external files.
Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
#79Honestly, the absolute best thing you could do for any dev, is lighten the footprint FF currently has on my ram, and continue to improve the api for add-ons/plugins. The more stable, extensible and fast FireFox is, the more useful I will find it for development. But if more kludge is added to it, and it continues to get slower/bigger, the less likely I am to continue to use it, regardless of what amazing plugins are…
Your comment is somewhat self-contradicting. Baking plugins into firefox will increase Firefox's memory footprint. Plugins are plugins for a reason -- some people will want the functionality and others will not. How would you like to see the API for plugins/add-ons improved?