Develop Reference

How do I ensure my script file isn't cached when debugging a VS MVC website?

I came across a problem today where the only way for the web program I am developing showed the most recent copy of a modified script was to reboot the machine. It is a file bundled in the master layout page, in a script bundle. I tried CTRL-F5 and deleted all files (I think) in Internet Options of IE11 to ensure it wasn't using the cached copy, but that was not sufficient.
I then suspected the cause is related to the fact I am using the VS Development server in VS2010. I tried killing WebDev.WebServer40.exe, hypothesizing it was caching it there, but that was not it either. I made the test as basic as modifying the entire contents of the script file to be a single alert() message, which never appeared, until I rebooted the machine.
I've seen suggestions to add args to the file when referencing it, or rename it each build, but clearly that's not productive when running many iterations in new development. I am wondering if there's perhaps a Visual Studio or Internet Explorer option here that guarantees to load the un-cached file each build? Is IE also possibly caching this info in some other memory space I need to be aware of too? thanks
EDIT:
Ok, it turns out the root cause of the problem was a post-build step modifying the script files I was working on. Rebooting was therefore a coincidental fix. As always, blame the writer. :). However, I have seen this problem occur many times in the past, genuinely, and am still curious if there's browser settings available (with specifics) that ensure scripts (and CSS files) are never cached, in development.

Disable the browser cache. Accessed through the debugger or developer tools (usually F12).
Here are some examples:
Chrome
Firefox
IE11

Internet Explorer Developer Tools does not show source code using RequireJS

I am attempting to debug a page issue where IE 9 will work the first time on my requirejs/backbone application, but will fail on the page reload. However, when I attempt to debug this problem using the f12 IE developer tools, I cannot navigate to the source to set a breakpoint because IE does not load any of the files that RequireJS includes. How can I get around this issue to fix my IE headache??

I guess I am late for the party but hope my answer helps you and others as well.
The file that you want to debug or the line in the file, simply add this --> debugger;
before that line.
So, when require.js loads your script and encounter that string i.e. debugger; exists it will automatically be stopped at that line.

You can generate a single js File with require tools :
include requirejs in this single file
(http://requirejs.org/docs/optimization.html#onejs)
set optimise to
none (no source minified -
http://requirejs.org/docs/optimization.html#shallow)
In your index.html link this file instead of require.js.
You can debug with IE.

I have the same problem from time to time. What sometimes helps: Close all the files in Debugger view, leave the DevTools open, press Play to allow page to continue and then make your action on the page or reload - if it halts on the debugger; again, all the files will be loaded. But still investigating ;)

Understanding Firefox extension structure

I'm trying to write a Firefox extension that intercepts a certain HTTP request and return static content without the request making it to the actual server (similar to AdBlock).
I've looked up the tutorials and I've got a basic file layout. I've also worked out that I need to use the nsITraceableChannel API and add an observer to do what I want and I have example code for that.
Problem is, where do I actually put this code? And when is my extension actually loaded and executed? Is it running constantly and asynchronously in the background or is it loaded per page view?
The documentation doesn't seem very clear on this. This extension won't need a GUI so I don't need the layouting XUL files (or do I?). I tried writing some XPCOM (I don't think I did it right though) component, registered it in chrome.manifest but it doesn't seem to run.
Can anyone explain exactly how the Firefox extensions work and where should I put my actual JavaScript code to monitor requests? Or have I got the whole idea of what an extension is wrong? Is there a difference between add-ons, extensions and plugins?

Concerning the difference between add-ons, extensions and plugins you should look at this answer. But in general, you seem to have the correct idea.
The problem is, there are currently three very different types of extensions:
Classic extensions (not restartless): these will typically overlay the browser window and run code from this overlay. Since there is one overlay per window, there will be as many code instances as browser windows. However, classic extensions can also register an XPCOM component (via chrome.manifest as of Gecko 2.0). This component will be loaded on first use and stay around for the entire browsing session. You probably want your component to load when the browser starts, for this you should register it in the profile-after-change category and implement nsIObserver.
Restartless extensions, also called bootstrapped extensions: these cannot register overlays which makes working with the browser UI somewhat more complicated. Instead they have a bootstrap.js script that will load when the extension is activated, this context will stay around in background until the browser is shut down or the extension is disabled. You can have XPCOM components in restartless extensions as well but you will have to register them manually (via nsIComponentRegistrar.registerFactory() and nsICategoryManager.addCategoryEntry()). You will also have to take care of unregistering the component if the extension is shut down. This is unnecessary if you merely need to add an observer, nsIObserverService will take any object implementing nsIObserver, not only one that has been registered as an XPCOM component. The big downside is: most MDN examples are about classic extensions and don't explain how you would do things in a restartless extension.
Extensions based on the Add-on SDK: these are based on a framework that produces restartless extensions. The Add-on SDK has its own API which is very different from what you usually do in Firefox extension - but it is simple, and it mostly takes care of shutting down the extension so that you don't have to do it manually. Extensions here consist of a number of modules, with main.js loading automatically and being able to load additional modules as necessary. Once loaded, each module stays around for as long as the extension is active. They run sandboxed but you can still leave the sandbox and access XPCOM directly. However, you would probably use the internal observer-service module instead.

How can I debug a minified JS in firebug?

I have a web page which includes insane amount of minified JS files. The web page works perfectly fine on my local network but throws some JS error on staging. There is an issue in JS and I wan't to debug it. When I load the JS in Firebug's script tag it appears in one long horizontal line. Is there a way out in Firebug that expands or beautifies the script for debugging? I know I can use jsbeautifier but they wont help me. I can not upload an expanded file to CDN, defeats the purpose of using CDN.
Points to be noted,
a) I can not control the box which serves JS, its on CDN, I mentioned it.
b) I can use beautifiers etc but would that help me in debugging the script in run time? IMHO, no
c) Being bound by NDA and other legal things I can not share the script but its a generic problem, you can encounter it with a minified jQuery

Beautify your script
Add the CDN host in /etc/hosts or your local DNS to resolve it to your own web server
Host the beautified version and everything that you need on said web server
Both Firefox and Chrome (versions as of this edit) support beautifying script with the {} button available in the inspector.

Just load the minified file and press the {} button at the bottom and it instantly beautifies, making breakpoints and other debugging possible. (True for Chrome too)

This is a common problem and the Chrome dev team have recently come up with an elegant solution, which they've called Source Maps - see http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ for more info, I think you'll find it's exactly what you (and the rest of us) have been crying out for! :)

This is more a workaround, but it can help. The idea is that we will replace files coming from the server by files on your machine.
This will work with any browser.
It takes a bit of setup the first time (15 minutes maybe), but then it can be very convenient.
It can also helps testing your bug-fixes in a live/prod environment.
Get Fiddler (it's a web debugging proxy), install it, run it.
http://www.fiddler2.com/fiddler2/
(Restart browser after install to get the Fiddler extension)
If you debug an HTTPS website, check this first:
http://www.fiddler2.com/Fiddler/help/httpsdecryption.asp
From now on, you should see in Fiddler ("Web Sessions" pane on the left) all downloads made by your browser, including JS files.
If not, check this : Fiddler not displaying sessions
Find the file you want to debug in the list (Ctrl+F works)
Click on the file. Then either:
get the file content from the inspectors pane (textView tab), beautify it, save to a file on your local computer
or have access to a file which contains the source code (ex: from your source control)
Go to AutoResponder tab (top left pane).
Select "Enable automatic responses" checkbox.
Select "Unmatched requests passthrough" checkbox.
Drag your file from left pane to right pane (prefills rule editor at the bottom)
Set the other field with the path of your local file
Click the Save button
Reload the page and enjoy your debugging session.
Fiddler can do many more things, but this use-case answers the initial question.

Consider a Change!
Firefox w/ Firebug was my favorite JavaScript debugging method for almost a year, but I've recently moved to Google-Chrome's Developer-Tools which is far more superior.
Chrome supports an On-The-Fly (built-in feature) beautification of JavaScript resources
Once beautified, you are free to debug the JavaScript resource file, as it was "natively" downloaded beautified from the web-server. Breaking-points are set by clicking the line number.
One of the most extremely powerful feature,
Is once You've Stopped In A Breaking-point, You Are Free To Execute Commands (using console) In The Same Scope You ARE In The Breaking-point. In Firefox you can't do that.
Its so easy to debug (even anonymous functions), You'll never be back to Firefox.
Try It!

Pretty-print your JavaScript. Google this and you'll find multiple on-line JS beautifiers.
I happen to use http://jsbeautifier.org/ myself and it works fine, but search for others and use one that suits your needs.
Caveat: You still won't be able to get meaningful local variable names (which are usually renamed by a minifier). If the code was compiled by the Closure Compiler, then you absoutely won't get any useful information back at all, even when beutified, because then all variables and functions and properties are mangled (not only local ones).
Now, if your problem is with debugging code that comes from outside (e.g. a CDN), obviously that code would be minified, and you can't save your beautified version back there. In this case, you can replace the tags that load code from a CDN with a url pointing to your local version, then you can beautify the code (downloaded from the CDN) into your own server and you can then debug with FireBug.
Now, if you don't even control the HTML that contains those tags (e.g. they reside on a outside server), then unfortunately there is no way for you to do what you want without physically downloading the entire site to your own server. Even if you downloaded the entire site (with all the files), it may not work since the site may be driven by a back-end processing language or accesses a back-end database. In such case you'll also need to simulate all those data. It can be done, however -- you just have to go through a lot of pain. My recommendation is to save a version of the web page and run it on your own server, serving beautified code from your own server to debug.

Placing breakpoints on JavaScript makes debugging much easier, but if your code has already made it to production then it's probably been minified. How can you debug minified code? Helpfully, some of the browsers have an option to un-minify your JavaScript.
In Chrome and Safari, simply select the 'Scripts' tab, find the relevant file and then press the "{ }" (pretty print) icon located in the bottom panel.
In Internet Explorer, click the tool icon by the script selection drop down to find the option to format the JavaScript.
Opera will automatically prettify minified JavaScript. Source

JavaScript being loaded asynchronously in Firefox 3 (according to Firebug)?

I'm trying to profile the performance of a web site that I'm fairly confident is being slowed down by the loading of JavaScript files on the page.
The same JavaScript files are included several times on the page, and <script /> tags are scattered throughout the page instead of being included at the bottom.
As I suspected, when looking at FireBug's "Net" tab, most of the time (not all) when JavaScript is being loaded, no other files are requested. The browser waits for the JavaScript to complete loading.
There are a few exceptions however. There are a few occasions where JavaScript is loaded, but then at the same time, other resources appear to get loaded, such as other JavaScript files and images.
I always thought that JavaScript blocks the loading of other resources on the page. Am I incorrect in thinking this, or does this behavior vary depending on the browser or browser version?
UPDATE:
To those who have explained how loading a script blocks the loading of other resources, I'm already aware of this. My question is why a script wouldn't block the loading of other resources. Firebug is showing that some JavaScript files do not block loading other resources. I want to know why this would happen.

Javascript resource requests are indeed blocking, but there are ways around this (to wit: DOM injected script tags in the head, and AJAX requests) which without seeing the page myself is likely to be what's happening here.
Including multiple copies of the same JS resource is extremely bad but not necessarily fatal, and is typical of larger sites which might have been accreted from the work of separate teams, or just plain old bad coding, planning, or maintenance.
As far as yahoo's recommendation to place scripts at the bottom of the body, this improves percieved response times, and can improve actual loading times to a degree (because all the previous resources are allowed to async first), but it will never be as effective as non-blocking requests (though they come with a high barrier of technical capability).
Pretty decent discussion of non-blocking JS here.

I'm not entirly sure that Firebug offers a true reflection of what is going on within the browser. It's timing for resource loading seems to be good but I am not sure that it is acting as a true reflection of exactly what is going on. I've had better luck using HTTP sniffers/proxy applications to monitor the actual HTTP requests coming from the browser. I use Fiddler, but I know there are other tools out there as well.
In short, this many be an issue with the tool and not with how resources are actually being loaded ... at least worth ruling out.

I suppose you're using Firefox 3.0.10 and Firebug 1.3.3 since those are the latest releases.
The Firebug 1.4 beta has done many improvements on the net tab, but it requires Firefox 3.5. If you want to test it in Firefox 3.0, use one of the previous 1.4 alpha versions. But even with the improvements I still struggle to understand the result. I wish the Firebug developers would document more precisely what each part of a download means. It doesn't make sense to me why queuing is after connecting.
My conclusion was not to trust the results in Firebug, and ended up using the WebPageTest. Which was surprisingly good to come from AOL ;-)
Also, what kind of resources are being loaded at the same time as the javascript? Try tracing down the resources that are loaded at the same time, and see if it's referenced in a css/iframe/html-ajax. I'm guessing the reason why nothing else is loaded, is because the browser stops parsing the current HTML when it sees a script tag (without defer). Since it can't continue parsing the HTML, it has nothing more to request.
If you could provide a link to the page you're talking about. It would help everyone to give a more precise answer.

I believe that the content is downloadeded, but not rendered until the JavaScript is finished loading.
This is, from the server's POV, not much of a deal, but to the user it can make a huge difference in speed.

If you think about it a tag has to finish processing before you can continue to render content. What if the tag used document.write or some other wonderfully dumb thing? Until anything within the script tag has finished running the page can't be sure what it's going to display.

Browsers usually have a set number of connections opened to a single domain.
So, if you load all your scripts from the same domain you will usually load them one after the other.
But, if those scripts are loaded from several domains, they will be loaded in parallel.

The reason the browser is blocking during JavaScript downloading is that the browser suspects that there will be DOM nodes created inside the script.
For example, there might be "dcoument.write()" calls inside the script.
A way to hint to the browser that the script does not contain any DOM generation is with the "defer" attribute.
So,
<script src="script.js" type="text/javascript" defer="defer"></script>
should allow the browser to continue parallelizing the requests.
References:
http://www.w3.org/TR/REC-html40/interact/scripts.html#adef-defer
http://www.websiteoptimization.com/speed/tweak/defer/

As others have stated, the script is probably loading other resources through DOM injection.
Script.aculo.us actually loads its child components/scripts itself by doing this -- injecting other <script> tags into the DOM for them.
If you want to see whether or not this is the case, use Firebug's profiler and take a look at what the scripts are doing.

Like others said, one non-blocking way is to inject <script> tags in the page head.
But firefox can also execute loaded <script>s in parallel:
Copy the two lines below:
http://streetpc.free.fr/tmp/test.js
http://streetpc.free.fr/tmp/test2.js
Then go to this page, paste in the input textarea, click "JavaScript", then "Load Scripts" (which builds and adds a <script> child element to the head).
Try that in FF : you'll see "test2 ok", move the dialog box to see "test ok".
In other browsers, you should see "test ok" (with no other dialog behind) then "test2 ok", (except for Safari 4, showing me tes2 before test).

Firefox 3 has introduced connection parallelism feature to improve performance while loading a webpage, I bet this is the source of your problem ;)
When you open a web page that has many
different objects on it, like images,
Javascript files, frames, data feeds,
and so forth, the browser tries to
download several of them at once to
get better performance.
Here's the ZDNET blogpost about it.