New RFC: better JS minification

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

New RFC: better JS minification

Max Semenik
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!:)

--
Best regards,
  Max Semenik ([[User:MaxSem]])


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New RFC: better JS minification

Jérémie Roquet-2
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 <[hidden email]>:
> 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,

--
Jérémie

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New RFC: better JS minification

Ori Livneh
On Tue, Sep 1, 2015 at 8:43 AM, Jérémie Roquet <[hidden email]>
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.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New RFC: better JS minification

Max Semenik
On Tue, Sep 1, 2015 at 8:49 AM, Ori Livneh <[hidden email]> 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/

--
Best regards,
Max Semenik ([[User:MaxSem]])
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New RFC: better JS minification

MZMcBride-2
In reply to this post by Ori Livneh
Ori Livneh wrote:
>On Tue, Sep 1, 2015 at 8:43 AM, Jérémie Roquet <[hidden email]>
>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



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New RFC: better JS minification

Jérémie Roquet-2
2015-09-02 1:53 GMT+02:00 MZMcBride <[hidden email]>:

> Ori Livneh wrote:
>>On Tue, Sep 1, 2015 at 8:43 AM, Jérémie Roquet <[hidden email]>
>>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,

--
Jérémie

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New RFC: better JS minification

Krinkle
> On 3 Sep 2015, at 01:02, Jérémie Roquet <[hidden email]> wrote:
>
> 2015-09-02 1:53 GMT+02:00 MZMcBride <[hidden email]>:
>> [..] 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>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New RFC: better JS minification

Matthew Flaschen-2
In reply to this post by MZMcBride-2
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New RFC: better JS minification

Jon Robson
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
<[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New RFC: better JS minification

Roan Kattouw-2
On Thu, Sep 3, 2015 at 4:15 PM, Jon Robson <[hidden email]> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New RFC: better JS minification

Jon Robson
On Thu, Sep 3, 2015 at 4:37 PM, Roan Kattouw <[hidden email]> wrote:

> On Thu, Sep 3, 2015 at 4:15 PM, Jon Robson <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New RFC: better JS minification

Jérémie Roquet-2
In reply to this post by Roan Kattouw-2
2015-09-04 1:37 GMT+02:00 Roan Kattouw <[hidden email]>:
> On Thu, Sep 3, 2015 at 4:15 PM, Jon Robson <[hidden email]> 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.

--
Jérémie

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New RFC: better JS minification

Helder .
Isn't that one of these bugs?
https://phabricator.wikimedia.org/T75714
https://phabricator.wikimedia.org/T96901

Best regards,
Helder

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l