Live data from Hacker News

Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

news.ycombinator.com

101–110 of 360 posts

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#101

Paul, can you comment how Firebug fits into this? I 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…

Firebug is a monster ram whore, ideally the functionality would be built into firefox so it can be maintained as a core-set functionality. Then they can assemble unit tests etc to make sure it's there for the longrun.

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#102
It would be nice if there was a way (or ways) to ease the pain of debugging minimized CSS/JS files.

We've all been there, right? Uncaught exception on Line 2, Column 49,392 of /foo/jquery.min.js, right?

1. For well-known source files (like major jQuery releases, etc) perhaps the debugger could (optionally) switch to the unminimized version. This could be done via file hash comparisons based on a table stored on Mozilla's servers (oh, I see you're using jquery.min.js which has a hash of 498DE248A4B which corresponds to the unminimized file jquery-1.9.1.js on Google's CDN) or perhaps the debugger could just optionally substitute "foo.js" for "foo.min.js" if it exists on the server.

2. For cases when #1 fails, perhaps the debugger could at least pretty-format the source code so that it's not all on a single line of code 30,000 (or whatever) characters long, so that breakpoints could be set.

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#103
Thanks for doing this post! Some things I'd like to see:

* Less UI chrome. The blue bar doesn't need to be blue and element breadcrumbs don't need to be fancy styled boxes. Large elements don't even fit in them and get chopped off.

* When I hit Ctrl-Shift-I the FDT open, but if I have the dialog detached it immediately loses focus and I have to alt-tab to see it.

* I find Chrome's Network inspector to be very useful for tracking APIs and checking headers/responses etc.

* It'd be nice if Firefox had an option to 'deminify' Javascript source in the debugger. The same for CSS.

* Built in html/css/js lint would be a nice feature

  * Right click -> Save option for CSS. The "Save" hyperlink is great but it took me too long to spot it.
That's all I can think of for now. I will continue playing and post if I have any more suggestions. :)

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#104
post #65

The two things that I'd want to see are a Network tab and a better way to edit the HTML. Adding to the HTML is a must-have in my opinion, not just editing what's already there.

Network tab is our next tool.

And a lot of people have asked for a better edition mechanism in the HTML panel. So I hope we can fix that soon.

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#105
post #73

This is a big request: Improve "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…

+1. I can't even add an element directly in the Chrome dev tools - you can only edit an existing elements HTML and append something after it.

My kingdom for a '+' button.

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#106
post #81

A clear strategy as to which dev tools will be maintained in the future. Will Firebug and Firefox Dev Tools coexist? What's the plan there? It seems like a duplication of effort from Mozilla.

My understanding is that Firebug is discontinued from Mozilla's side (which means nothing wrt any volunteer effort ongoing there, btw!), but they assist in keeping it alive on Firefox updates because the native tools don't have the same functionality yet.

Our team also work on Firebug. So no, it's not "discontinued".

We are working on sharing more code. In an ideal world, we will be able to merge these 2 tools in the future.

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#107

The console certainly needs some love. I love that it opens so fast and feels so light compared to Firebug. I don't use it because: * I can't select and copy text from the console's output (it's a listbox now) * The autocomplete is not as good as Firebug's and hitting enter does not complete it * The inspector does not remember the width of the two panels (left with DOM/right with CSS rules) You get the idea. You've…

I get the idea :) Thanks.

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#108

Earlier quoted context omitted.

Dynamically-loaded libraries (.DLL, .so, etc) have been around for decades. A feature can be "baked in" and still loaded (and unloaded) on-demand.

We do lazy load the devtools.

Mozilla rocks!

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#110
post #60

I'm glad you asked! This is a good time for me to bring up something I wrote two years ago: http://news.ycombinator.com/item?id=2024164 I really wish browser makers would do this! Mozilla can lead the way. I am going to post it here for ease of reference: 1) I propose a simple mechanism to guarantee that a resource located at a certain URL is always the same. Similar to how we have https:// blabla, and the user agent…

I really like your first proposal. The second one is good too, but less pressing to me than the first. The software I'm working on uses static JS with a high security requirement, and is meant to be deployed on any host. Integrity guarantees would be valuable for that.
Post reply on HN