Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On 31/01/11 13:51, Roan Kattouw wrote: I can work around it in the extension, but we should watch out and make sure we've got regression tests covering any cases we find. Yes, we need minifier tests. Isn't this an upstream issue? If so we could send them our patches. -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
There are 2 components to the JavaScriptDistiller library. One of them (the ParseMaster class) is 100% in sync with the official distribution. The other (the JavaScriptDistiller class) was originally based on the JavaScriptPacker::_basicCompression function. That function had some issues that we have worked out, and in the process of doing that we've gotten really far away from the original source. It appears that our version is just about stable, so I plan to offer the code in JavaScriptDistiller to the JavaScriptPacker author to try and help make his library better as well. In the former case, any changes should be strictly passed upstream. In the latter case, I think we should offer them upstream but realize that we have deviated from the original author's structure and possibly intentions enough that they may or may not be wanted. - Trevor On Feb 1, 2011, at 10:35 AM, Ashar Voultoiz wrote: On 31/01/11 13:51, Roan Kattouw wrote: I can work around it in the extension, but we should watch out and make sure we've got regression tests covering any cases we find. Yes, we need minifier tests. Isn't this an upstream issue? If so we could send them our patches. -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On 01/02/11 19:42, Trevor Parscal wrote: In the former case, any changes should be strictly passed upstream. In the latter case, I think we should offer them upstream but realize that we have deviated from the original author's structure and possibly intentions enough that they may or may not be wanted. As always, thanks for the clear clarification Trevor :-) -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
Trevor Parscal wrote: There are 2 components to the JavaScriptDistiller library. One of them (the ParseMaster class) is 100% in sync with the official distribution. The other (the JavaScriptDistiller class) was originally based on the JavaScriptPacker::_basicCompression function. That function had some issues that we have worked out, and in the process of doing that we've gotten really far away from the original source. It appears that our version is just about stable, so I plan to offer the code in JavaScriptDistiller to the JavaScriptPacker author to try and help make his library better as well. In the former case, any changes should be strictly passed upstream. In the latter case, I think we should offer them upstream but realize that we have deviated from the original author's structure and possibly intentions enough that they may or may not be wanted. - Trevor How should they be sent upstream? I did for instance a small change at r81207, but given that we don't have any tests, decided to wait before annoying the upstream author (I think that would be Nicolas?). I don't see a repository there, so we could as well offer him space for it in our hierarchy. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
I was planning on emailing him a patch, probably after I wrote some tests to ensure I wasn't submitting him something with issues. - Trevor On Feb 1, 2011, at 1:41 PM, Platonides wrote: Trevor Parscal wrote: There are 2 components to the JavaScriptDistiller library. One of them (the ParseMaster class) is 100% in sync with the official distribution. The other (the JavaScriptDistiller class) was originally based on the JavaScriptPacker::_basicCompression function. That function had some issues that we have worked out, and in the process of doing that we've gotten really far away from the original source. It appears that our version is just about stable, so I plan to offer the code in JavaScriptDistiller to the JavaScriptPacker author to try and help make his library better as well. In the former case, any changes should be strictly passed upstream. In the latter case, I think we should offer them upstream but realize that we have deviated from the original author's structure and possibly intentions enough that they may or may not be wanted. - Trevor How should they be sent upstream? I did for instance a small change at r81207, but given that we don't have any tests, decided to wait before annoying the upstream author (I think that would be Nicolas?). I don't see a repository there, so we could as well offer him space for it in our hierarchy. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
2011/1/30 Brion Vibber br...@pobox.com: I noticed a regression in the JS minification with a bit of sloppy third-party code being imported through ResourceLoader in SVGEdit: https://bugzilla.wikimedia.org/show_bug.cgi?id=27046 Fixed now. The regex stripping C++-style // comments was also stripping the newline following them. I've now changed it to replace a comment plus newline (i.e. !//[^\r\n]*[\r\n]!) with a newline, so these newlines are always preserved, regardless of whether vertical whitespace stripping and collapsing is enabled. I can work around it in the extension, but we should watch out and make sure we've got regression tests covering any cases we find. Yes, we need minifier tests. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
I noticed a regression in the JS minification with a bit of sloppy third-party code being imported through ResourceLoader in SVGEdit: https://bugzilla.wikimedia.org/show_bug.cgi?id=27046 I can work around it in the extension, but we should watch out and make sure we've got regression tests covering any cases we find. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On 1/22/11 5:40 PM, Maciej Jaros wrote: Just remember that people all over the world are hacking into Mediawiki all the time. Making it harder won't help a bit. I think minification is orthogonal to the hacking question. I've said it before here but the key to enabling hackers is to have a stable and documented API (both a remote web service, and an API for things one might want to do in Javascript on the page). We know that people are going to hack and that we like that, but if we don't want to be trapped into supporting old APIs forever we should document what's likely to change and what we will aim to keep stable. -- Neil Kandalgaonkar (| ne...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
Michael Dale (2011-01-21 16:04): On 01/21/2011 08:21 AM, Chad wrote: While I happen to think the licensing issue is rather bogus and doesn't really affect us, I'm glad to see it resolved. It outperforms our current solution and keeps the same behavior. Plus as a bonus, the vertical line smushing is configurable so if we want to argue about \n a year from now, we can :) Ideally we will be using closures by then and since it rewrites functions, variable names and sometimes collapses multi-line functionality, new line preservation will be a mute point. Furthermore, Google even has a nice add-on to firebug [1] for source code mapping. Making the dead horse even more dead. I feel like we are suck back in time, arguing about optimising code that came out eons ago in net time ( more than 7 years ago ) There are more modern solutions that take into consideration these concerns and do a better job at it. ( ie not just a readable line but a pointer back to the line of source code that is of concern ) [1] http://code.google.com/closure/compiler/docs/inspector.html Great. Now I only need to tell the user to install Firefox, install Firebug and some other addon, open the page in Firefox... Oh, wait. This error does not occur in Firefox... Please, I can live with folding new lines (thou I don't believe those few bites are worth it) acutely compiling the code (or packing as some say) would be just evil for Mediawiki or Wikimedia to be more exact. Just remember that people all over the world are hacking into Mediawiki all the time. Making it harder won't help a bit. Regards, Nux. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On Sat, Jan 22, 2011 at 5:40 PM, Maciej Jaros e...@wp.pl wrote: Great. Now I only need to tell the user to install Firefox, install Firebug and some other addon, open the page in Firefox... Oh, wait. This error does not occur in Firefox... Please, I can live with folding new lines (thou I don't believe those few bites are worth it) acutely compiling the code (or packing as some say) would be just evil for Mediawiki or Wikimedia to be more exact. Just remember that people all over the world are hacking into Mediawiki all the time. Making it harder won't help a bit. Making it more powerful and more self-aware may, however, help a **lot**. ResourceLoader provides a relatively sane module-loading system for managing what bits of code and data are flying around. Consider supplementing this better encapsulation with in-browser development tool helpers -- say, to provide a code editor with syntax highlighting and flagging of errors, and to let you load your custom site/user/gadget JS modules in context while you're working on them. Common tasks like adding custom tabs or grabbing some part of the existing UI to modify can be made much easier by a script editor that knows these things exist, and can help you identify which bits of the UI you want to work with by clicking on them. Even coming back down to earth, consider that current versions of every major browser now have at least a basic Firebug-like debugging console and a DOM inspector available. Debugging JavaScript on IE used to consist of getting a dialog box with a file name and line number that were usually *entirely wrong*... other browsers gave you better error messages but not much more. Debugging JavaScript in today's browsers can at least pop up the live code in context for you, and by sticking '?debug=false' on your URL, all our minification will be conveniently gone from view, and the individual modules easier to identify by hand. (This too could probably be given a nice UI helper in a script debugging tool or even in a global error handler... which could also do things like report JS errors upstream to MediaWiki developers.) Whether you have all the magic of a real debugger or not, that's *hugely* useful in debugging, and has made a world of difference in my experience. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
2011/1/23 Brion Vibber br...@pobox.com: Debugging JavaScript in today's browsers can at least pop up the live code in context for you, and by sticking '?debug=false' on your URL, all our minification will be conveniently gone from view, and the individual modules easier to identify by hand. I recommend using ?debug=true for that ;) Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On Fri, Jan 21, 2011 at 5:30 AM, Tim Starling tstarl...@wikimedia.org wrote: On 21/01/11 12:46, Trevor Parscal wrote: Joke or not, it's in there, and it's a violation of the GPL. Did you try emailing the author and asking for a dual license? I believe that people from Redhat have already tried that and failed. Bryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On Thu, Jan 20, 2011 at 8:30 PM, Tim Starling tstarl...@wikimedia.org wrote: Sure, but Trevor is claiming that he wrote it because of the license issue. Since he has publically ranted three times: http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/50082 http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/50910 http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73196#c13027 about how terrible my changes to JSMin.php were, in September, December and January, I can't help but think that there was another motive for this rewrite. I have no problem with Trevor reverting that change, I said so the second time this came up, so I think it's amusing that Trevor needed the excuse of license incompatibility before he actually did something. I'm glad that he's finally found the motivation from somewhere, so that he can stop bothering me with his periodic rants. This is really unnecessary and unhelpful on a public mailing list. I think we'd all be better off if snark like this were kept to private channels. -- Andrew Garrett http://werdn.us/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On Fri, Jan 21, 2011 at 10:49 AM, Andrew Garrett agarr...@wikimedia.org wrote: This is really unnecessary and unhelpful on a public mailing list. I think we'd all be better off if snark like this were kept to private channels. Agreed. Or better yet, not said at all. Since we evidently no longer have a benevolent dictator whose word we all accept without question, we need to work amicably to resolve disputes, and getting into fights about 1% size savings vs. dubious increases in readability is really not useful. At least get into fights about something *significant*. (FWIW, I was and am against removing *all* newlines from JS output, but I'm fine with collapsing consecutive newlines. This way errors will actually point to a recognizable line.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On Fri, Jan 21, 2011 at 7:21 AM, Aryeh Gregor simetrical+wikil...@gmail.com wrote: On Fri, Jan 21, 2011 at 10:49 AM, Andrew Garrett agarr...@wikimedia.org wrote: This is really unnecessary and unhelpful on a public mailing list. I think we'd all be better off if snark like this were kept to private channels. Agreed. Or better yet, not said at all. Since we evidently no longer have a benevolent dictator whose word we all accept without question, we need to work amicably to resolve disputes, and getting into fights about 1% size savings vs. dubious increases in readability is really not useful. At least get into fights about something *significant*. I agree. Talk about the code, not the committer. But I really don't think we need a benevolent dictator. Brion never really had to step in and play traffic cop; we've all gotten along and worked well over the years without generally needing one and I see no reason why that needs to change now. And yes, I think we should keep the arguments confined to major things. Ok everyone stop for a second. We're arguing about a few lines of vertical whitespace. Full stop. Lets argue about complex architecture changes or something else worthwhile. It's really not worth it to waste so many bytes (and my e-mail now just adds to the pile, I know) over something so incredibly trivial. Back to the subject at hand... While I happen to think the licensing issue is rather bogus and doesn't really affect us, I'm glad to see it resolved. It outperforms our current solution and keeps the same behavior. Plus as a bonus, the vertical line smushing is configurable so if we want to argue about \n a year from now, we can :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On 21/01/11 23:21, Aryeh Gregor wrote: On Fri, Jan 21, 2011 at 10:49 AM, Andrew Garrett agarr...@wikimedia.org wrote: This is really unnecessary and unhelpful on a public mailing list. I think we'd all be better off if snark like this were kept to private channels. Agreed. Or better yet, not said at all. Since we evidently no longer have a benevolent dictator whose word we all accept without question, we need to work amicably to resolve disputes, and getting into fights about 1% size savings vs. dubious increases in readability is really not useful. At least get into fights about something *significant*. Why does everyone think I care about the issue when I keep saying that I don't? My email was an expression of frustration at the fact that Trevor keeps attacking me about the change I made despite the fact that I made it abundantly clear last time around that I don't care about it and don't want to hear anything more about it. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On 01/21/2011 08:21 AM, Chad wrote: While I happen to think the licensing issue is rather bogus and doesn't really affect us, I'm glad to see it resolved. It outperforms our current solution and keeps the same behavior. Plus as a bonus, the vertical line smushing is configurable so if we want to argue about \n a year from now, we can :) Ideally we will be using closures by then and since it rewrites functions, variable names and sometimes collapses multi-line functionality, new line preservation will be a mute point. Furthermore, Google even has a nice add-on to firebug [1] for source code mapping. Making the dead horse even more dead. I feel like we are suck back in time, arguing about optimising code that came out eons ago in net time ( more than 7 years ago ) There are more modern solutions that take into consideration these concerns and do a better job at it. ( ie not just a readable line but a pointer back to the line of source code that is of concern ) [1] http://code.google.com/closure/compiler/docs/inspector.html peace, --michael ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On 22/01/11 02:49, Aaron Schulz wrote: This sounds like thinking out loud (not to say whether it's true or false). It seems like there just has to be some better, more private, means to discuss things like this... Fair enough. Apologies to the list. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
For those of you who didn't see bug 26791, our use of JSMin has been found to conflict with our GPL license. After assessing other options ( https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I decided to try and use the minification from JavaScriptPacker, but not its overly clever but generally useless packing techniques. The result is a minifier that outperforms our current minifier in both how quickly it can minify data and how small the minified output is. JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript code at about 2x the speed of Tim's optimized version of JSMin, and 4x the speed of the next fastest PHP port of JSMin (which is generally considered the standard distribution). Similar to Tim's modified version of JSMin, we chose to retain vertical whitespace by default. However we chose not to retain multiple consecutive empty new lines, which are primarily seen where a large comment block has been removed. We feel there is merit to the argument that appx. 1% bloat is a reasonable price to pay for making it easier to read production code, since leaving each statement on a line by itself improves readability and users will be more likely to be able to report problems that are actionable. We do not however find the preservation of line numbers of any value, since in production mode most requests are for many modules which are concatenated, making line numbers for most of the code useless anyways. This is a breakdown based on ext.vector.simpleSearch * 3217 bytes (1300 compressed) * 2178 bytes (944) after running it through the version of JSMin that was in our repository. Tim modified JSMin to be faster and preserve line numbers by leaving behind all vertical whitespace. * 2160 bytes (938 compressed) after running it through JavaScriptDistiller, which applies aggressive horizontal minification plus collapsing multiple consecutive new lines into a single new line. * 2077 bytes (923 compressed) after running it through JavaScriptDistiller with the vertical space option set to true, which applies aggressive horizontal minification as well as some basic vertical minification. This option is activated through $wgResourceLoaderMinifyJSVerticalSpace, which is false by default. The code was committed in r80656. - Trevor (and Roan) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On 20 January 2011 22:13, Trevor Parscal tpars...@wikimedia.org wrote: For those of you who didn't see bug 26791, our use of JSMin has been found to conflict with our GPL license. On behalf of all aspiring Dark Lords, may I thank the Wikimedia Foundation for protecting our freedom to use MediaWiki for evil. BABY MULCHING WIKI IS GO! - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
Trevor Parscal (2011-01-20 23:13): For those of you who didn't see bug 26791, our use of JSMin has been found to conflict with our GPL license. After assessing other options ( https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I decided to try and use the minification from JavaScriptPacker, but not its overly clever but generally useless packing techniques. The result is a minifier that outperforms our current minifier in both how quickly it can minify data and how small the minified output is. JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript code at about 2x the speed of Tim's optimized version of JSMin, and 4x the speed of the next fastest PHP port of JSMin (which is generally considered the standard distribution). Similar to Tim's modified version of JSMin, we chose to retain vertical whitespace by default. However we chose not to retain multiple consecutive empty new lines, which are primarily seen where a large comment block has been removed. We feel there is merit to the argument that appx. 1% bloat is a reasonable price to pay for making it easier to read production code, since leaving each statement on a line by itself improves readability and users will be more likely to be able to report problems that are actionable. We do not however find the preservation of line numbers of any value, since in production mode most requests are for many modules which are concatenated, making line numbers for most of the code useless anyways. This is a breakdown based on ext.vector.simpleSearch * 3217 bytes (1300 compressed) * 2178 bytes (944) after running it through the version of JSMin that was in our repository. Tim modified JSMin to be faster and preserve line numbers by leaving behind all vertical whitespace. * 2160 bytes (938 compressed) after running it through JavaScriptDistiller, which applies aggressive horizontal minification plus collapsing multiple consecutive new lines into a single new line. * 2077 bytes (923 compressed) after running it through JavaScriptDistiller with the vertical space option set to true, which applies aggressive horizontal minification as well as some basic vertical minification. This option is activated through $wgResourceLoaderMinifyJSVerticalSpace, which is false by default. Yes, I know I'm stubborn, but 6 bytes (0.6%)? Seriously? Doesn't seem convincing to me and seems like it could at least use $wgResourceLoaderMinifyJSHorizontalSpace (even if true by default). Regards, Nux. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On Thu, Jan 20, 2011 at 2:33 PM, David Gerard dger...@gmail.com wrote: On 20 January 2011 22:13, Trevor Parscal tpars...@wikimedia.org wrote: For those of you who didn't see bug 26791, our use of JSMin has been found to conflict with our GPL license. On behalf of all aspiring Dark Lords, may I thank the Wikimedia Foundation for protecting our freedom to use MediaWiki for evil. BABY MULCHING WIKI IS GO! Amateur. I'd describe my evil effort, but it's too sensitive to even be on the net. -- -george william herbert george.herb...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On Thu, Jan 20, 2011 at 5:13 PM, Trevor Parscal tpars...@wikimedia.orgwrote: For those of you who didn't see bug 26791, our use of JSMin has been found to conflict with our GPL license. Thank you for removing JSMin! Thou shall use mediawiki for evil! ;) -Katie (@aude) - Trevor (and Roan) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
2011/1/21 Maciej Jaros e...@wp.pl: Yes, I know I'm stubborn, but 6 bytes (0.6%)? Seriously? Doesn't seem convincing to me and seems like it could at least use $wgResourceLoaderMinifyJSHorizontalSpace (even if true by default). Trevor probably didn't choose a very good test case. He also tested it on jQuery, though, and found that the unmodified version of JSPacker was faster than JSMin and produced output that was 1% larger after gzip. So in the general case, JSDistiller probably doesn't quite minify JS optimally, but the difference with JSMin is small and the difference in performance is ridiculous. That, and it doesn't present legal problems. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
Roan Kattouw (2011-01-21 00:50): 2011/1/21 Maciej Jarose...@wp.pl: Yes, I know I'm stubborn, but 6 bytes (0.6%)? Seriously? Doesn't seem convincing to me and seems like it could at least use $wgResourceLoaderMinifyJSHorizontalSpace (even if true by default). Trevor probably didn't choose a very good test case. He also tested it on jQuery, though, and found that the unmodified version of JSPacker was faster than JSMin and produced output that was 1% larger after gzip. So in the general case, JSDistiller probably doesn't quite minify JS optimally, but the difference with JSMin is small and the difference in performance is ridiculous. That, and it doesn't present legal problems. You've misunderstood me. As long as it's well tested and performs nicely then I'm all for (though I don't remember using MediaWiki for Evil ;-)). Great job, really. I was only hoping to have an option to fully preserve vertical space, but I've made a rotation in the name :-). So the option could be $wgResourceLoaderMinifyJSVerticalSpacePreserved or maybe $wgResourceLoaderMinifyJSPreserveEmptyLines. Regards, Nux. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On 21/01/11 09:13, Trevor Parscal wrote: For those of you who didn't see bug 26791, our use of JSMin has been found to conflict with our GPL license. You're talking about the good not evil joke clause? -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
Joke or not, it's in there, and it's a violation of the GPL. - Trevor On 1/20/11 5:44 PM, Tim Starling wrote: On 21/01/11 09:13, Trevor Parscal wrote: For those of you who didn't see bug 26791, our use of JSMin has been found to conflict with our GPL license. You're talking about the good not evil joke clause? -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
2011/1/21 Trevor Parscal tpars...@wikimedia.org: Joke or not, it's in there, and it's a violation of the GPL. Plus the alternative is better anyway. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
As mentioned in the bug, it would be nice to have configurable support for the closure-compiler as well ;) ( I assume Apache licence is compatible? ) Has anyone done any tests to see if there are any compatibility issues with SIMPLE_OPTIMIZATIONS with a google closure minification hook? --michael On 01/20/2011 04:13 PM, Trevor Parscal wrote: For those of you who didn't see bug 26791, our use of JSMin has been found to conflict with our GPL license. After assessing other options ( https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I decided to try and use the minification from JavaScriptPacker, but not its overly clever but generally useless packing techniques. The result is a minifier that outperforms our current minifier in both how quickly it can minify data and how small the minified output is. JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript code at about 2x the speed of Tim's optimized version of JSMin, and 4x the speed of the next fastest PHP port of JSMin (which is generally considered the standard distribution). Similar to Tim's modified version of JSMin, we chose to retain vertical whitespace by default. However we chose not to retain multiple consecutive empty new lines, which are primarily seen where a large comment block has been removed. We feel there is merit to the argument that appx. 1% bloat is a reasonable price to pay for making it easier to read production code, since leaving each statement on a line by itself improves readability and users will be more likely to be able to report problems that are actionable. We do not however find the preservation of line numbers of any value, since in production mode most requests are for many modules which are concatenated, making line numbers for most of the code useless anyways. This is a breakdown based on ext.vector.simpleSearch * 3217 bytes (1300 compressed) * 2178 bytes (944) after running it through the version of JSMin that was in our repository. Tim modified JSMin to be faster and preserve line numbers by leaving behind all vertical whitespace. * 2160 bytes (938 compressed) after running it through JavaScriptDistiller, which applies aggressive horizontal minification plus collapsing multiple consecutive new lines into a single new line. * 2077 bytes (923 compressed) after running it through JavaScriptDistiller with the vertical space option set to true, which applies aggressive horizontal minification as well as some basic vertical minification. This option is activated through $wgResourceLoaderMinifyJSVerticalSpace, which is false by default. The code was committed in r80656. - Trevor (and Roan) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
On 21/01/11 12:46, Trevor Parscal wrote: Joke or not, it's in there, and it's a violation of the GPL. Did you try emailing the author and asking for a dual license? On 21/01/11 12:58, Roan Kattouw wrote: Plus the alternative is better anyway. Sure, but Trevor is claiming that he wrote it because of the license issue. Since he has publically ranted three times: http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/50082 http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/50910 http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73196#c13027 about how terrible my changes to JSMin.php were, in September, December and January, I can't help but think that there was another motive for this rewrite. I have no problem with Trevor reverting that change, I said so the second time this came up, so I think it's amusing that Trevor needed the excuse of license incompatibility before he actually did something. I'm glad that he's finally found the motivation from somewhere, so that he can stop bothering me with his periodic rants. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!
iirc there are some issues with the Apache license in GPLv2. GPLv3 however is fine with the Apache license. As for dropping JSMin... I never really liked Crockford anyways, nor JSMin... so I don't really have any problem. I also don't like the idea of maintaining what's essentially a local fork from the upstream, so if this is a performance improvement and eliminates the need to fork something to get it to do what we want... perfect. Personally I always had a preference towards YUI's minifier. I haven't quite jumped onto closure just yet... in the early days I wasn't sure about trusting it to not introduce edge cases into code (since it basically does some rewriting of code above what other minifiers do and I wasn't sure about it's implementation. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] On 11-01-20 06:57 PM, Michael Dale wrote: As mentioned in the bug, it would be nice to have configurable support for the closure-compiler as well ;) ( I assume Apache licence is compatible? ) Has anyone done any tests to see if there are any compatibility issues with SIMPLE_OPTIMIZATIONS with a google closure minification hook? --michael On 01/20/2011 04:13 PM, Trevor Parscal wrote: For those of you who didn't see bug 26791, our use of JSMin has been found to conflict with our GPL license. After assessing other options ( https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I decided to try and use the minification from JavaScriptPacker, but not its overly clever but generally useless packing techniques. The result is a minifier that outperforms our current minifier in both how quickly it can minify data and how small the minified output is. JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript code at about 2x the speed of Tim's optimized version of JSMin, and 4x the speed of the next fastest PHP port of JSMin (which is generally considered the standard distribution). Similar to Tim's modified version of JSMin, we chose to retain vertical whitespace by default. However we chose not to retain multiple consecutive empty new lines, which are primarily seen where a large comment block has been removed. We feel there is merit to the argument that appx. 1% bloat is a reasonable price to pay for making it easier to read production code, since leaving each statement on a line by itself improves readability and users will be more likely to be able to report problems that are actionable. We do not however find the preservation of line numbers of any value, since in production mode most requests are for many modules which are concatenated, making line numbers for most of the code useless anyways. This is a breakdown based on ext.vector.simpleSearch * 3217 bytes (1300 compressed) * 2178 bytes (944) after running it through the version of JSMin that was in our repository. Tim modified JSMin to be faster and preserve line numbers by leaving behind all vertical whitespace. * 2160 bytes (938 compressed) after running it through JavaScriptDistiller, which applies aggressive horizontal minification plus collapsing multiple consecutive new lines into a single new line. * 2077 bytes (923 compressed) after running it through JavaScriptDistiller with the vertical space option set to true, which applies aggressive horizontal minification as well as some basic vertical minification. This option is activated through $wgResourceLoaderMinifyJSVerticalSpace, which is false by default. The code was committed in r80656. - Trevor (and Roan) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
