Hi everyone, I was running some experiments with UglifyJS lately and so I stumbled upon this RFC which shows that if I've not discovered anything new, we can still get ~15% smaller JS files. 2014-03-19 22:16 GMT+01:00 Max Semenik <maxsem.wiki(a)gmail.com>om>: Now, it's also about supporting newer versions of ECMAScript (if we don't target full backward compatibility, of course), because it seems to me that unlike UglifyJS, JSMin+ has not been updated for a while and could choke on some valid syntax with error messages that are not exactly… explicit for casual JS developers (I've experimented that a few weeks ago with local scripts making use of reserved words as identifiers — not exactly valid code, indeed, but code that had worked for years in most browsers). Has the RFC been abandonned because of lack of interest? Best regards, -- Jérémie

On Tue, Sep 1, 2015 at 8:49 AM, Ori Livneh <ori(a)wikimedia.org> wrote: Feel free to, however I myself have neither the time nor inclination to work on this; the components are: * The extension itself: https://github.com/wikimedia/mediawiki-extensions-Minifier * Minifier service in extension's /server/ directory * Core change https://gerrit.wikimedia.org/r/#/c/74293/ -- Best regards, Max Semenik ([[User:MaxSem]])

2015-09-02 1:53 GMT+02:00 MZMcBride <z(a)mzmcbride.com>om>: I had the same point of view only a few days ago (discussions at Debian got me there), but since then, I've changed my mind after some experiments: minification can save additional percents compared to gzip (the actual impact for our code is to be computed, but for jQuery, it's already about half the size). I see no need to obfuscate for the sake of obfuscation, indeed, but neither do I see how minification can be harmful to the open Web per se: in our case, the original, non-mangled source code is always available. In my eyes, it's not different from running binaries or bytecode instead of interpreting the source code for performance reasons: as long as you have the source code and the ability to do reproducible builds, it's ok. As for bugs, I fully agree with you. It's an argument against minification, but also an argument in favor of dropping JSMin+ for another more used and actively maintained minifier, such as UglifyJS. Best regards, -- Jérémie

On 09/01/2015 07:53 PM, MZMcBride wrote: I don't agree with this. However, I do think source maps (which allow you to serve minified code but see the original source code as soon as you open the script inspector/debugger) are important. UglifyJS apparently has support for this already (https://github.com/mishoo/UglifyJS2), so this would actually probably make it more likely to get implemented. Not all of those are related to minification. In fact, I think most are not. unminified + gzip is still noticeably bigger than minified + gzip. All of our software is free and open source. There is no reason we have to use more bandwidth than needed. Matt Flaschen

On Thu, Sep 3, 2015 at 4:15 PM, Jon Robson <jdlrobson(a)gmail.com> wrote: Less than zero? No one has managed to find a single bug in JavaScriptMinifier.php since 2011. I have nothing against moving to uglify (provided that source maps come first), but don't use false arguments as a reason for migrating. Roan

2015-09-04 1:37 GMT+02:00 Roan Kattouw <roan.kattouw(a)gmail.com>om>: Yeah! Could I be the last person to have reported a bug in it? :D https://phabricator.wikimedia.org/T30207 More seriously: I assume we still use JSMin+ somewhere, don't we? When saving scripts, for validation, maybe? The issues I've encountered a few weeks ago with gadgets that broke when migrated to ResourceLoader because of their use of reserved identifiers were clearly related to it (I traced them back to include/libs/jsminplus.php in core) and not to JavaScriptMinifier. I thought it was at minification time, but it seems I was wrong. -- Jérémie