Hi, I'd like to present a new RFC for your consideration: https://www.mediawiki.org/wiki/Requests_for_comment/Minifier
It is about how we can shave 10-15% off the size if JavaScript delivered to users.
Your comments are highly welcome!:)
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 [email protected]:
Hi, I'd like to present a new RFC for your consideration: https://www.mediawiki.org/wiki/Requests_for_comment/Minifier
It is about how we can shave 10-15% off the size if JavaScript delivered to users.
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,
On Tue, Sep 1, 2015 at 8:43 AM, Jérémie Roquet [email protected] wrote:
Has the RFC been abandonned because of lack of interest?
Speaking for myself: at the time the RFC was written, I was skeptical that the benefits would be worth incurring a dependency on an external service (or the requirement of shelling out). But since then we have had a lot of discussions (in the RFC meetings) on how to do micro-services correctly, and some good abstractions have come out of that. So +1 for reviving it.
On Tue, Sep 1, 2015 at 8:49 AM, Ori Livneh [email protected] wrote:
So +1 for reviving it.
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/
Ori Livneh wrote:
On Tue, Sep 1, 2015 at 8:43 AM, Jérémie Roquet [email protected] wrote:
Has the RFC been abandonned because of lack of interest?
Speaking for myself: at the time the RFC was written, I was skeptical that the benefits would be worth incurring a dependency on an external service (or the requirement of shelling out). But since then we have had a lot of discussions (in the RFC meetings) on how to do micro-services correctly, and some good abstractions have come out of that. So +1 for reviving it.
I'd personally prefer that we move in the other direction, removing the minification. I think it's harmful to the open Web to minify, or worse, obfuscate our code. As expected, we've encountered a number of bugs that disappear when the debug=true URL parameter is specified. And given other performance optimization work and existing optimizations such as gzip compression, I don't see the benefits outweighing the costs.
MZMcBride
2015-09-02 1:53 GMT+02:00 MZMcBride [email protected]:
Ori Livneh wrote:
On Tue, Sep 1, 2015 at 8:43 AM, Jérémie Roquet [email protected] wrote:
Has the RFC been abandonned because of lack of interest?
Speaking for myself: at the time the RFC was written, I was skeptical that the benefits would be worth incurring a dependency on an external service (or the requirement of shelling out). But since then we have had a lot of discussions (in the RFC meetings) on how to do micro-services correctly, and some good abstractions have come out of that. So +1 for reviving it.
I'd personally prefer that we move in the other direction, removing the minification. I think it's harmful to the open Web to minify, or worse, obfuscate our code. As expected, we've encountered a number of bugs that disappear when the debug=true URL parameter is specified. And given other performance optimization work and existing optimizations such as gzip compression, I don't see the benefits outweighing the costs.
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,
On 3 Sep 2015, at 01:02, Jérémie Roquet [email protected] wrote:
2015-09-02 1:53 GMT+02:00 MZMcBride [email protected]:
[..] our code. As expected, we've encountered a number of bugs that disappear when the debug=true URL parameter is specified.
[..]
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.
Quick notes:
1. We've had little to no bugs caused by minification. If you encounter a bug that doesn't occur in debug mode, it is most certainly caused by the loading procedure, caching layers, or a race condition. Never minification.
2. In fact, debug mode has been known to cause bugs due to how it loads code differently than production mode.
3. We use neither JSMin nor JSMin+ for minification. They are too slow and cause bugs. We use JavaScriptMinifier.
-- Krinkle
[1] https://www.mediawiki.org/wiki/JavaScriptMinifier https://www.mediawiki.org/wiki/JavaScriptMinifier
On 09/01/2015 07:53 PM, MZMcBride wrote:
I'd personally prefer that we move in the other direction, removing the minification. I think it's harmful to the open Web to minify, or worse, obfuscate our code.
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.
As expected, we've encountered a number of bugs that disappear when the debug=true URL parameter is specified.
Not all of those are related to minification. In fact, I think most are not.
And given other performance optimization work and existing optimizations such as gzip compression, I don't see the benefits outweighing the costs.
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
Thanks, I thought I was alone with being confused by this e-mail. As Jérémie correctly states we'll likely to get __less__ bugs with a more maintained library. Obfuscation without source code being made available is anti-open source but that's not what's being talked about here.
With regards to Krinkle's comment links to bugs in future would be useful.
Thanks Jérémie for re-opening the dialog here.
On Thu, Sep 3, 2015 at 3:24 PM, Matthew Flaschen [email protected] wrote:
On 09/01/2015 07:53 PM, MZMcBride wrote:
I'd personally prefer that we move in the other direction, removing the minification. I think it's harmful to the open Web to minify, or worse, obfuscate our code.
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.
As expected, we've encountered a number of bugs that disappear when the debug=true URL parameter is specified.
Not all of those are related to minification. In fact, I think most are not.
And given other performance optimization work and existing optimizations such as gzip compression, I don't see the benefits outweighing the costs.
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
Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Sep 3, 2015 at 4:15 PM, Jon Robson [email protected] wrote:
Thanks, I thought I was alone with being confused by this e-mail. As Jérémie correctly states we'll likely to get __less__ bugs with a more maintained library.
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
On Thu, Sep 3, 2015 at 4:37 PM, Roan Kattouw [email protected] wrote:
On Thu, Sep 3, 2015 at 4:15 PM, Jon Robson [email protected] wrote:
Thanks, I thought I was alone with being confused by this e-mail. As Jérémie correctly states we'll likely to get __less__ bugs with a more maintained library.
Less than zero? No one has managed to find a single bug in JavaScriptMinifier.php since 2011.
:) We can do it!! haha :) As I said. Links are useful when we make claims!! I have no background knowledge in this matter.
I have nothing against moving to uglify (provided that source maps come first), but don't use false arguments as a reason for migrating.
Agreed. Hence my point.
Maybe this RFC is a good topic for the frontend standards meetings ? cc Volker who I believe is leading that.
Roan _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2015-09-04 1:37 GMT+02:00 Roan Kattouw [email protected]:
On Thu, Sep 3, 2015 at 4:15 PM, Jon Robson [email protected] wrote:
Thanks, I thought I was alone with being confused by this e-mail. As Jérémie correctly states we'll likely to get __less__ bugs with a more maintained library.
Less than zero? No one has managed to find a single bug in JavaScriptMinifier.php since 2011.
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.
Isn't that one of these bugs? https://phabricator.wikimedia.org/T75714 https://phabricator.wikimedia.org/T96901
Best regards, Helder