Live data from Hacker News

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

news.ycombinator.com

291–300 of 360 posts

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

#291
Hi Paul,

I am not a FireFox dev tools user and I highly invested in Chrome devtools. I edit JavaScript code in browser all day. It's hard to not use a fully featured editor but I invested in it to make it better. I submit bugs and sometimes fix small bugs there too.

I will tell you what Chrome dev tools CANT do for HTML and CSS and ask you to implement them to attract more developers.

1. Editing JavaScript code in browser: - Autocompletion (I know this is very hard) - Code block collapsing - A good theme API - Shortcut keys like CMD+/ for comments - Inline watchers for when developer stopped at breakpoint and look at watched value right next to it's position in code (Something like Visual Studio) 2. Editing CSS - Inline CSS reloading (Reloading CSS without refreshing) - Better autocomplete for values - Unminifying CSS 3. Multitouch

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

#292

Earlier quoted context omitted.

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

Your Live Edit idea is a good one, but I think the assumption about "un-pre-processing" would be part of the pre-processing development tools understanding what was being pushed to them, therefore, the need for an open standard as has been alluded to above.

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

#293
post #286

Earlier quoted context omitted.

First off, thanks for the link! I up-voted you; that's a really good introduction to source maps. I believe it would be incredibly useful if FF's dev tools could do some of this on their own; primarily for the reason that the person debugging the Javascript can't always control the build process. The times when you don't have access to the build process and/or the original unminified code are the times when you need…

If you don't have any of those, then I don't see how the developer tools can figure out what the original source is. You need some way of mapping points in the minified file to lines in the original file. Ask your favorite CDN to also host a source map. Otherwise the best the developer tools can do is prettify the minified file, something both Chrome and IE do (I don't recall if Firefox Nightly does).

I agree that source maps are the right solution, but even the ability to pretty-print the indentation and separate statements onto lines would work wonders.

I've had too many errors on line 1.

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

#295

Embed mozrepl https://github.com/bard/mozrepl/wiki or something simular. I'd like network based access (restricted to a socket or localhost by default) to the innards of the browser. Mozrepl works, but has proven fragile. I've had to make several updates to keep it working with the latest Firefox nightlies. I've currently got mozrepl hooked to emacs so when I save a js, coffeescript, or css/scss file it live updates…

>Embed mozrepl https://github.com/bard/mozrepl/wiki or something simular. I'd like network based access (restricted to a socket or localhost by default) to the innards of the browser. Mozrepl works, but has proven fragile. I've had to make several updates to keep it working with the latest Firefox nightlies.

That looks really interesting. I just tried out swank-js and it worked for simple javascript, but it didn't work with dojo (going to debug that and see if there isn't an easy solution).

How does this work with more complex javascript? Does it work with libraries like jquery or dojo? Does the link you gave have your fixes? I will probably give this a try tomorrow, thanks for the link!

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

#296
post #254

It would be nice to record a session and see what CSS rules that were applied. This should include events such as :hover. As an added bonus it could return a clean version of a stylesheet that matches.

Oh, I really like that suggestion!

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

#297
[Inspector] Support more pseudo selectors where applicable. E.g. :link and :visited for links, :target, :enabled, :disabled, :checked, :indeterminate etc.

[Web Console] Add an option to reset when the page reloads (like Chrome). Perhaps it doesn't even have to be an option, but could be the only way.

[Editing HTML/CSS/JS] I don't have a clear idea, but I don't want to edit code in the browser (my editor is my tool of choice), and would love if I didn't have to refresh to update a resource.

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

#298
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…

I'm the author of http://tin.cr , it tries to solve this exact problem for Chrome Devtools. (someone else mentioned this in this thread). I've spent some time thinking about the problem. In an ideal world a standardized protocol to push changes to a server would be awesome. I think it's unrealistic though to expect widespread adoption especially for existing frameworks to add code just for doing this. For example, ha…

This was the original intent of the PUT method in HTTP.

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

#300
One thing that I think would really improve the lives of all firefox users is if firefox would update silently like chrome does. Firefox always chooses the times when I want to get something done to do the updates and so I always cancel the update (in order to do what I want). In chrome, updates happen without me noticing them which is ideal. (this also has the added benefit to devs that older versions of firefox will fall out faster and thus require less support)
Post reply on HN