Live data from Hacker News

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

news.ycombinator.com

241–250 of 360 posts

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

#241
Hello. I think first and foremost FireFox should build in support for disabilities, so that one can get to its UI Elements. The nice side-effect is that governments, which has laws regulating software for the benefit of disabled workers, then are able to use it.

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

#242

I believe all the current development tools do it wrong, and the right place for a tool is outside the browser, as a custom shell around the main browser component. This is how I tend to work: I load up an app. I set up my credentials (by logging in or setting a particular cookie manually, for example). I debug using Firebug, mainly using the DOM view, the console and the JavaScript REPL. Then I might change my crede…

You should, I like that idea very much. I was also having a similar problem with mixing work & personal data. Now I am using Canary as development browser, that itself is enormous resource hog. If you will continue working on such a project I am happy to help!

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

#243
post #54

Earlier quoted context omitted.

How exactly does this help web developers? This has been considered and rejected as inferior to the current approach. The Android browser used this and it was rewritten to get rid of it. Let's focus on doing things that improve the user experience rather than blindly copying features from other browsers without considering if they make sense. Moreover, it has absolutely nothing to do with the question asked.

I'm not sure what he said, but I assume he said something about Electrolysis. Didn't they ditch Electrolysis because of issues with many nsplugins? I am not aware of other reasons it was shitcanned.

Plugins and add-ons AFAIK. There are also memory/performance implications, which apparently were not insignificant on mobile platforms. Given that Chrome uses more memory than Firefox, it's perhaps not insignificant on desktop either.

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

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

Not perfect but what I did last time I played with backbone:

* As I used sass, coffeescript and haml, I used guard (https://github.com/guard/guard) to watch the source files and automatically compile them

* Used serve (https://npmjs.org/package/serve) to serve the directory over http, could use python -m SimpleHTTPServer too

* Used live.js to pull for changes (http://livejs.com/)

As I said it's not perfect though, while CSS changes get applied transparently, changes in javascript will reload the page (you can also watch only for CSS changes). Still for working on CSS, especially together with LESS or SASS it's quite pleasant. Also it spams your Firebug console pretty bad.

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

#245
+1 for "design in the browser" capabilities.

But, a more easier (I guess) but similar feature I would like is, full color picker for color values, and a gradient generator with color stops etc. which can be invoked for all gradient background supported elements, both color and gradient should update the rendering as the values are changed.

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

#246
post #43

Earlier quoted context omitted.

[deleted]

Meh, if you're referring to making every tab its own process, I personally don't like that. I'm sure there's performance or stability reasons for Chrome's decision, but I also don't really like having 30 different processes open for the one application.

Why not? I'd say 30 processes is a lot better than 1 process. You also need to take into consideration that the number of cores is increasing pretty quickly. Pretty soon consumers will have 32 cores and whatnot. I'm a Firefox user but really it's the largest weakness Firefox is having. If I open two new tabs simultaneously, the whole browser can freeze for a bit.

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

#247
Hi Paul, I think some sort of explicit URL protocol would be nice for short-circuiting DNS without having to add entries to your hosts file and restart; something like:

httpe://1.2.3.4@www.domain.com/index.html

would connect to 1.2.3.4 and ask for domain.com, without querying DNS either locally or otherwise. I'd find it useful.

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

#248
post #39

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…

I thought that the latest browser tests showed that FF used less ram than Chrome. http://lifehacker.com/5976082/browser-speed-tests-chrome-24-... Unfortunately, reputations stick.

This is my current Chrome memory usage

  Browser	                                    	       
  Google Chrome 25.0.1364.97

  Memory 
  Private      Shared  Total
  3,950,040k 12,805k 3,962,845k

  Virtual memory
  Private      Mapped
  4,728,936 k 937,320 k
This is with 18 tabs and ~20 extensions. Chrome isn't really light on memory usage anymore. 1.5GB of that is split between Google Reader and the Spotify web player though, anything Javascript heavy seems to use an absurd amount of RAM after it's been left open for a few days.

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

#249

Earlier quoted context omitted.

Meh, if you're referring to making every tab its own process, I personally don't like that. I'm sure there's performance or stability reasons for Chrome's decision, but I also don't really like having 30 different processes open for the one application.

Why not? I'd say 30 processes is a lot better than 1 process. You also need to take into consideration that the number of cores is increasing pretty quickly. Pretty soon consumers will have 32 cores and whatnot. I'm a Firefox user but really it's the largest weakness Firefox is having. If I open two new tabs simultaneously, the whole browser can freeze for a bit.

Honestly (and I'm fairly certain this is a bad reason), it's a cleanliness thing. If I use top or the process manager, it gets annoying to scroll through countless variations of 'chrome'. Maybe if the process manager could group those into one heading where I just see "Chrome (30 processes)", I'd feel better about it?

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

#250
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, have you ever heard of WebDAV? It was thought up along the same lines and it's virtually dead now.

A better solution for now would be for source maps to tell you the full local path to the original source file. Yes, in a world where we all develop from Chromebook-like devices against files in the cloud, this won't work. We are a long way from that world at the moment.

Post reply on HN