Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
241–250 of 360 posts
Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
#242I 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…
Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
#243Earlier 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.
Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
#244This 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…
* 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?
#245But, 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?
#246Earlier 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.
Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
#247httpe://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?
#248Honestly, 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.
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?
#249Earlier 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.
Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
#250This 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'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.