The Trouble with DNN JavaScript / CSS Minification (aka Client Dependency / Resource Management)

Basically it's a system in DNN which should be told what CSS / JS files the page will use, and then delivers them all in one single request. Combined, minified and zipped, from the server to the browser. It also takes care of the sequence of loading things, to ensure that the order of items works - so that jQuery is loaded before your stuff, etc. This should improve performance and reliability. So basically it does a few core things

1. Ensure that each script is only included once (if multiple components need a script, it will only be added once)
2. Attempt to order the scripts correctly (so that jQuery comes before your script)
3. Attach all files into one file
4. Do some minification / zipping
5. Cache this combination of files

There are quite a few issues with the CDM / CRM, some of them conceptual, some of them in implementation. For example, the script-ordering result is a bit random. The conceptual issues I will skip, because what hurts us as module developers is the implementation. Here's a common story:

It starts with someone using our module and reporting a bug. The bug can be anything - like

1. It can on the server or the client, doesn't matter
2. The problem can be on all pages, or just on some pages - this varies from installation to installation
3. The exception can occur in JS (because the JS was expected a different setup on the server) or it can be on the server (because the JS called something on the server, expecting a different API)
4. Very often: the user recently updated to a newer version (but might not be aware of it)

It almost always turns out to be that the JS  in the browser is not in Sync with the installed system. This causes small differences in APIs which are called or parameters which are passed around.  So the user will update to version 08.03.05 and will experience an issue. He will assume that 08.03.05 has a bug, and never realize that this version actually works, but that his browser is still running the JS of 08.02.03.

We will always waste our users time and ours to try to figure it out. The solution is usually to get the user to manually invalidate his previous bundles. This is terrible! Upgrading should be simple and just work - but it isn't.

This is BTW by far not the only really bad issue, and there are ways to work around each of them. But at the end of the day we end up spending a lot of time working around features which should have helped, but actually don't.

Edit: I just heard that it is fixed in DNN 8.0.1 :)
Yes we should - but it wouldn't help anybody developing modules. If (a) the community fixes it (and yes, someone should) and (b) the fix actually addresses all the right problems and (c) it actually makes it into DNN without too many people voicing alternate ideas, then it might probably end up in a distribution of DNN within 3-6 months, and after some fixes from real-life projects, really, really work one release later (in about 1 year from now).  

So if we do fix it in DNN, you can expect a working solution in a real distribution in about 1 year, meaning the customers would use it in published projects in about 1-2 years (yes, this is true!), and all previous versions 7+ would never, ever benefit from the change. So if you want a solution to work for real customers, than you can't wait for a fix.

Since I was so focused on solving things the DNN way, I completely missed the fact that ASP.net also has a solution. Bogdan from DNN-Sharp showed it to me, and said their support-frequency dropped by more than 50% after this change. It doesn't do as much as the DNN solution (yea!) but reliably. Actually all it does is prevent multiple files from being added. This is very, very important, because loading a JS twice can have serious side-effects like double execution and timing issues. 

Here's some code as 2sxc does it from now on (you see that it also appends the version number, which will also ensure that the browser will load a new version after an upgrade):