I 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.
In Chrome, you could Snippets[1] or Live Editing[2] to monkey-patch Javascript sources inline. No need to copy & modify the content - just edit it within the browser and re-run. Complete with syntax highlighting, auto-completion, and the same no-reload goodness you are used to.
I never would have found snippits without it being pointed out to me. Thank you, that seems to be basically what I was looking for. Thought why it is there, and not just a multi-line console confounds me. Then again, so do most of Google's UI decisions for the last ~2 years or so.
Firefox has a feature that's actually called Scratchpad that's likely exactly what you need. It's a small, basic text editor that lets you run javascript code on the current page. It also has open and save file functionality. It can be rather handy.
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.