views:

1038

answers:

6

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?

A: 

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?]

CJM
+1  A: 

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.

This insanity was enough reason for me to ditch MS Ajax completely and switch over to jQuery, which is far better library, especially since Visual Studio now has Intellisense for jQuery.

Josh Stodola
Who down-voted this answer, and why?
Josh Stodola
Not sure, up vote from me because I share your view on ASP.NET Ajax.
Martijn Laarman
I got downvoted too - perhaps we have an MS staffer on SO? :) I do wish down-voters would explain why they have voted thus...
CJM
+1 added back on.
CJM
Josh, in ASP.NET 3.5 they allow you to combineclient scripts now, see Combining Client Scripts into a Composite Script, http://msdn.microsoft.com/en-us/library/cc488552.aspx. Has anybody tried it?
nickyt
That's good to know. Haven't tried it, as we have yet to upgrade our framework.
Josh Stodola
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
+1  A: 

Which would you rather have:

  1. MicrosoftAjax.js comes compressed, obfuscated already.
  2. MicrosoftAjax.js comes uncompressed and open so you can read and understand it yourself.
Jon Grant
why not both? jQuery comes in both, right?
Neil N
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.
CJM
@Neil N. I agree, why not both? When developing use uncompressed and in prod use the minified/obfuscated version.
nickyt
+3  A: 

See http://www.codeproject.com/KB/aspnet/AspNetOptimizer.aspx, you need the

enableScriptMinification="true"

option and add MicrosoftAjax.js to the list

J-16 SDiZ
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.
nickyt
+18  A: 

I'm surprised at these misleading answers.

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.

Additionally, you may use the "retail" setting to force compressed scripts regardless.

Dave Ward
Thanks for this Dave. Great to know.
nickyt
+7  A: 

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.

Not looking for rep here, just wanted to give more detail.

InfinitiesLoop
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?
nickyt
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.
InfinitiesLoop