Javascript code management in asp controls

We're looking for a way to manage ever-increasing javascript code for our asp controls (used with RegisterClientScript family). The classic way was to have javascript encoded into string constants inside c# code but now it's getting bigger and you don't want to develop inside c# string. Having code in external file and convert/copy it into a string form before compilation is also somewhat ridiculous. Plus in these scenarios almost same code is sent several times with each instance of the control.

Other important criteria is to have the scripts self-sufficient, with only external dependency on jquery&co, so having control-specific javascript files some开发者_运维问答where else is not desired. All the relevant parts have to be in one place.

My personal best option so far is to have Javascript split into two parts:

- "code behind"-like js file compiled as embedded resource into assembly. This is about 3 times slower than string concatenation but. Plus it brings options for caching and direct-from-file without recompiling for debugging. This part is delivered inline once per page containing the control.

- tiny initialising proxy function calling the main script with control-instance specific parameters. These are delivered also inline but once per control instance.

I'm sure we're not the only ones scratching our heads about this.

So how do you do that?

Update. Getting rid of .net specifics, situation is following. We have some 100+ reusable server-side components each possibly containing some javascript client-side functionality. These controls are of course not used in every page so packing the javascript into one common lib is not desired. On the other hand, having 20+ references to external javascript files each being 1-2Kb in size is also both headache for maintenance and traffic overkill. That is why we want to have the component know and care about its own javascript inclusion.

On the other hand, if you have a project where these components are spread into several libraries, you don't really want for them to depend on some particular filesystem layout which may be of course standardised but it's too much of responsibility for a vehicle tire to enforce your cola choice in a diner, imo.

If you have JavaScript code that is re-used by several controls - why don't you want this in an external *.js file? This will allow you to maintain formatting, and yet still serve up a minimized, gzipped and client side cachable file.