I compress my own JS using YuiCompressor, but is there any reason why MicrosoftAjax.js not minified? Or is there some setting to say run the compressed version of it (if there is a compressed version). Or do I need to decompile it and minify the script resource myself?

Well from the responses I got, there does not appear to be anyway to get a minified/compressed version of MicrosoftAjax.js out of the box. So it looks like DIY is the way to go as I mentioned in the answer I picked. As I mentioned to Josh, in ASP.NET 3.5 you can combine scripts now, msdn.microsoft.com/en-us/library/cc488552.aspx. We haven't migrated to 3.5 yet, but when we do I will check it out. I've read mixed reviews about it. As well, I added jQuery to the project a while ago, so I am slowly jQuerifying everything that can be jQuerified.
–
nickytonlineJun 30 '09 at 17:14

2

My comment above is no longer true. Dave Ward's answer is the good one, so no DIY.
–
nickytonlineJul 13 '09 at 14:36

6 Answers
6

ASP.NET AJAX has always provided both debug and compressed versions of MicrosoftAjax.js. A combination of the web.config's debug setting and ScriptManager's ScriptMode property control which script is referenced.

All the scripts in System.Web.Extensions are minified -- there are two versions of each, as Dave Ward's excellent answer points out. ScriptManager by default will use the debug version when the web.config is in debug mode. Flip it to release with the retail setting or debug="false", and look at the script then.

Also, scripts served through WebResourceHandler or ScriptResourceHandler are in fact cached. They are cached in the best possible way -- forever, so they don't even need to 301 on future visits. The querystring is as it is, because it contains encrypted data. It is encrypted because it contains information about the script resource, including an assembly name, and also because it prevents cache flooding attacks.

Good to know about the WebResourceHandler or ScriptResourceHandler being cached. So I'm assuming when you make changes and redeploy, these are cached again but as different files because the encrypted querystring has changed?
–
nickytonlineJul 16 '09 at 13:19

2

Yup. Any change to the resource will change the querystring, resulting in a newly cached item. Also I didn't mention that the scripts are gzip compressed, too.
–
InfinitiesLoopJul 16 '09 at 17:55

I've read this article before, but thanks for posting it here. What I was looking for though was an out of the box solution from Microsoft Ajax. Looks like DIY is the way to go on this one.
–
nickytonlineJun 26 '09 at 13:50

While it would be trivial to have both versions, and fairly useful too, if you were going to take the easy way out, you should provide the uncompressed version. +1 because this didn't deserve down-voting.
–
CJMJun 25 '09 at 16:55

@Neil N. I agree, why not both? When developing use uncompressed and in prod use the minified/obfuscated version.
–
nickytonlineJun 26 '09 at 13:48

EDIT: In my defense, at the time of writing this answer I had no experience with .NET 3.5; I now realize they have made several much-needed improvements in this area.

Evidently, MS does not feel the JavaScript file size is very important (which is insane). Additionally, based on my experience with MS Ajax, they also inject several SCRIPT tags (sometimes more than 10) into the markup. These tags bring in scripts from a WebResource.axd handler. So ten or more requests have to be made just to get the necessary Javascript to run the page! Just to add to the ridiculousness, they tack on a crazy query string onto the handler URL, which probably prevents the script from being cached by the browser.

Corrections: "MS does not feel the Javascript file size is very important": Incorrect: they provide a minified version of every script automatically output in release mode. "ten or more requests have to be made": This is an extreme case, we get by with only 1 in a large app without even trying. "which probably prevents the script from being cached": This doesn't prevent browser caching, though some older proxy servers may not cache correctly. In 3.5 the script combiner shoves all scripts for the current page in one url, one cached response. This includes all of our jQuery.
–
Nick Craver♦Aug 18 '09 at 17:06

I can only assume that it has been left as-is for ease of understanding, and as you have already hinted, I see know reason why you can't compress it yourself, it is only JavaScript after all - Although MS might like you to believe otherwise, they don't sprinkle it with magical pixie dust to make it any different! :)

[And let's face it; MS have never been afraid of the size of their code, have they?]