5 ms·
Same here. I still feel Firefox devtools are not innovating fast enough. Chrome workspaces and a lot of other useful features are just not present in Firefox. I
by mundanevoice 12y ago
Same here. I still feel Firefox devtools are not innovating fast enough. Chrome workspaces and a lot of other useful features are just not present in Firefox. I feel that's one of the major reason I could never migrated to Firefox professionally.
I am also quite impressed with IE 10 & 11 devtools. It is really useful and has clean UI and UX.
In short I could say that:
Chrome Devtools > Firebug > IE devtools > Firefox devtools
- mixedbit 12y agoI'm a long time Firefox fan, but very recently I played for the first time with IE 11 memory profiler and I must say, this is the best profiler out there.
- cbaleanu 12y agoThe window title for IE 10&11 devtools is for some reason named "F12" on my windows 7 machine. Maybe it's just me but I find this annoying, feels a little unprofessional.
- interurban 12y agoF12 is the default shortcut for opening the IE devtools, maybe that's why?
- mbrubeck 12y agoYup, the IE devtools are named "F12" after the keyboard shortcut: http://msdn.microsoft.com/library/ie/bg182326%28v=vs.85%29 http://msdn.microsoft.com/library/ie/bg182326%28v=vs.85%29 (F12 is also the keyboard shortcut for opening the developer tools in Chrome, Firefox, and others.)
- deleted 12y ago[deleted]
- cbaleanu 12y agoBy this reasoning 'paste' should be renamed to CTRL-V.
- skrebbel 12y agoSo when Google calls a virtually chromeless browser "Chrome" it's ok, but when Micrsoft calls a tool after its shortcut key, it's stupid?
- kaeawc 12y ago"In design terminology, ‘chrome’ refers to the non-webpage parts of the browser’s interface – the toolbars, tabs and buttons – because our design philosophy was “Content, not chrome” – putting our focus on minimizing the amount of browser UI present, we felt it cheekily appropriate to name the browser Chrome" http://www.thewindowsclub.com/google-chrome-reason-revealed http://www.thewindowsclub.com/google-chrome-reason-revealed
- hibbelig 12y agoIt's great to see humor from MS.
- DatBear 12y agoI think that Firefox has lagged behind because of Firebug. When there is already a way for developers to do things, why invent your own, unless you can make it better?
- ep103 12y agoI still think Firebug + WebDevelopmentToolbar + FF Web Dev Tools is the greatest combo for any browser. Do I need to do any web dev work? Just do it in firebug. Do I need to drastically change my browser's behaviour? There's probably a setting for that in the web dev toolbar. Do I want to do anything that involves monitoring or changing the browser itself? check the FF web dev tools. Between the three, I don't understand how people can claim chrome has a superior toolset.
- kyriakos 12y agoI am still using firebug. Even though performance is not great i find its console and dom inspection to be better than chrome's and mozilla's
- ep103 12y agoI'll use chrome devtools the day they add multiline console support. Really? In 2014, and you want me to shift-enter 200 lines of code?
- IceCreamYou 12y agoI got frustrated with this and created BigConsole[1] to solve it. It's a Chrome extension that adds a Firebug-style split console to DevTools. Then I tweeted about it, and Addy Osmani responded[2] pointing out that Chrome does in fact support multiline consoles with its Snippets[3] feature. It's still kind of obnoxious, but it does the job. [1] https://github.com/IceCreamYou/Chrome-BigConsole https://github.com/IceCreamYou/Chrome-BigConsole [2] https://twitter.com/IceCreamYou/status/354181339408375809 https://twitter.com/IceCreamYou/status/354181339408375809 [3] https://developers.google.com/chrome-developer-tools/docs/authoring-development-workflow#snippets https://developers.google.com/chrome-developer-tools/docs/au...
- mbell 12y agoWhy are you putting 200 lines of code into the console?
- ep103 12y agoI have to say, I stared at this question for a while. I have such a large reliance on using the console as a scratchpad, before ever even opening a script file, that I don't think I've even considered the possibility that one could do front end development work without it. The best answer for you question, would be that throughout my career, the number of situations where I could directly edit a source javascript file, write-run-test-iterate in a typical software development cycle is in the far far minority of the amount of time I've spent writing javascript. The vast majority of my time, iterating changes to javascript files is non trivial. Some examples include Major CMS / CRM systems I've worked on where, even if I have all relevant source code, even finding the location where the page's javascript is generated or stored is non-trivial. Major CMS / CRM solutions where making a change to a single javascript file can result in a 20 minute process before you can see those changes reflected in the browser. Situations where I simply do not have access to the source code, but am none the less manipulating javascript on the page (for example, custom WPF applications that inject js into every page visited in the wpf web browser) Or my current situation, where my company hosts some ~30 different web applications, and fully understanding the processes involved to get to the final page state where I will be doing my work is non-trivial. --- But perhaps the best reason, is when debugging. With javascript, I can simply navigate to the problematic page and say module.function = myNewFunction(); If I start by copy pasting the source for the problematic code into myNewFunction in the console, then I can iterate my changes with 0 regard to how the javascript is served to the page. All my changes are instantaneous, and don't even require a refresh to see take effect. As such, my development time is usually much faster than constantly editing a source file, particularly if that backend framework doesn't update its js when noticing file changes, and is massively faster in any of the situations listed above. But the real key is that once you get used to working in this fashion, it starts to make sense to use the console as your scratchpad to flesh out ideas before ever actually writing real production code whatsoever, in any situation. It just becomes so nice to be able to flesh out your js ideas on the fly, with 0 regard to framework, and against your target environment. But this workflow is entirely impossible in chrome, because every time you want to run your script, you have to hit ente, and every time you need a new line you're shifting, and then you're up arrowing over versions, etc, etc. With firebug, I can just continually edit the text in the console until I'm happy with the results, and then I can keep that on the screen and use it as a reference while I write my (hopefully much nicer) real production code in a source file somewhere.