Aryeh Gregor wrote:
On Thu, May 20, 2010 at 3:20 PM, Michael Dale mdale@wikimedia.org wrote:
I like the idea of a user preference. This way you don't constantly have to add &debug to the url, its easy to tests across pages and is more difficult for many people to "accidentally" invoke it.
It also means that JavaScript developers will be consistently getting served different code from normal users, and therefore will see different sets of bugs. I'm unenthusiastic about that prospect.
hmm ... if the minification resulted in "different" bugs than the "raw" code that would be a bug with the minification process and you will want to fix that minfication bug. You will want to know where the error occurred in the minfied code.
Preserving new-lines is a marginal error accessibility gain when your grouping many scripts, replacing all the comments with new lines, striping debug lines, and potentially shortening local scope variable names. Once you are going to "fix" an issue you will be fixing it in the "actual" code not the minified output, so you will need to recreate the bug with the non-minified output.
In terms of all-things-being-equal compression wise using \n instead of semicolons consider: a = b + c; (d + e).print();
With \n instead of ; it will be evaluated as: a = b + c(d + e).print();
We make wide use of parenthetical modularization, i.e all the jquery plugins do soemthing like: (function($){ /* plugin code in local function scope using $ for "jQuery" */})(jQuery); Initialization code above line with /\n/, ';' substitution will result in errors.
The use of a script-debug preference is for "user-scripts" development that is hosted "live" and developed on the server wiki pages. Development of core and extension javascript components should be tested locally in both minified and non-minified modes.
peace, --michael