Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

171–180 of 360 posts

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

#171

Post by lifeisstillgood »

A RESTful stub,

so I can run my ajaxy goodness without needing a web server up. More importantly, have it run from standard definitions like jsonschema and URL mappings. Make the static version easy peasy config, and then let me extend the stub with JavaScript as it gets more complex.

Front end dev is splitting from backend dev - and there is a world of people who would kill for an industry wide means to define easily the expected behaviour of rest API / media types and so be confident that when the outsourced devs returned their work integration would not be a bightmare - expect your stub to be part of many SLAs

There are frameworks out there that do this (Jasmine) but if I wanted something, that's it

Edit: was even less clear than it is now

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

#173

Post by timdorr »

pixelcort wrote: post #142
mbell wrote: 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…

If a browser supported PUTting the modified resource back up to the server, we'd be off to a good start. Server-side frameworks could then add functionality to split the modified resource back into the files that created it.

What about pre-processors (SASS, Less) or templating engines (ERB, Haml, Slim)? That would seem to be a huge task to "un-pre-process" an asset. Going backwards is immensely difficult. These are not easily reversible processes.

Instead, why not make something like IntelliJ/RubyMine/WebStorm/etc.'s Live Edit plugin a native part of the browser. Allow the asset pipeline to tell the browser it has changes available, rather than try to have it regurgitate all the processed assets. That would be relatively easy to add and very straightforward to implement.

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

#174

Post by darkstalker »

baby wrote: post #19
JoeCortopassi wrote: post #3

Honestly, 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…

This and tabs on the left. It feels like using Tree Style Tab is not really fully optimized. I don't think you need to add a more things for developers. The tools already present are good enough, I saw someone suggesting a built-in sFTP. That's just too much.

Tree Style Tabs should be a core feature IMHO. It's the single most important feature for me.

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

#175

Post by tholex »

krob wrote: post #97
krob wrote: post #95

I think something that would be useful as a dev tool in FF, which only chrome right now has a decent tool for is restful url testing, similar in part to https://chrome.google.com/webstore/detail/advanced-rest-clie... I haven't seen anything even remotely similar for FF, maybe a optional plugin for this kind of tool, it would make my development process much quicker for the client-side code which is being used for res…

Better auto-complete for css fields for the css editor in the new FF, such that it's on par with the firebug auto-complete functionality in the dom/css inspecter

Auto-complete for css properties and easier value editing (up/down arrows) would definitely be a huge help. With that, I could see myself switching to FF for CSS development.

The responsive features in the web console - which imho HAS to be monosopace - are also definitely exciting, and make me want to switch to FF.

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

#176

Post by olivierbeaulieu »

paulrouget wrote: post #63
olivierbeaulieu wrote: post #53

I work a lot on a Firefox extension, and honestly, the absence of dev tools for addons is really painful. Developping our extension for Chrome was super easy, since all their default devtools work in extension panels as well, but in Firefox it's been a nightmare, almost no tools. We are left off in a console.log madness trying to figure out what's causing bugs. It would be soooooo awesome to have Firefox's default de…

We have the inner architecture for "chrome" debugging (extensions debugging). This sill needs some more work though.

Can we expect improvements to this in the near feature? It would definitely make the idea of making firefox addons more inviting.

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

#177

Post by tholex »

FF's web console has some nice resizing features to test responsiveness. They keep me coming back and trying aurora once in a while but the CSS property / value editor is currently lacking.

Either keyboard shortcut mappings for web console commands, or a simultaneous view of different responsive sizes would definitely be killer for responsive development.

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

#178

Post by callmevlad »

mbell wrote: 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…

(Disclaimer: I'm working on http://www.webflow.com to try to solve this exact problem.)

I've been thinking about this issue a lot over the last year, and it's really as hard as you state (and then some). We ended up having to create our own supersets of the DOM/CSSOM in order to keep track of individual elements/selectors as they are created/removed/changed. I would be very surprised (and pleased) if Mozilla was able to implement this in a way that works without lots of additional/manual inputs. If you think JS source maps are a hard problem to solve, I'd say this one is at least an order of magnitude harder.

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

#179

Post by Arelius »

I'd personally really like a remote debugging API (Does one already exist) Particularly I'd rather debug in my editor than in Firefox, at least for certain things, there is integration that I could implement in emacs, or even a javascript based Development Environment that just would not be doable without project specific code.

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

#180

Post by Arelius »

callmevlad wrote: post #178
mbell wrote: 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…

(Disclaimer: I'm working on http://www.webflow.com to try to solve this exact problem.) I've been thinking about this issue a lot over the last year, and it's really as hard as you state (and then some). We ended up having to create our own supersets of the DOM/CSSOM in order to keep track of individual elements/selectors as they are created/removed/changed. I would be very surprised (and pleased) if Mozilla was able…

I'm not sure I would say that JS source maps are a hard problem to solve.
Post reply on HN