4 ms·

I am surprised to discover that wikipedia appears to not use a standard minifier on their JS, but rather they have a custom one (written in PHP) that appears to

by evmar 7y ago

I am surprised to discover that wikipedia appears to not use a standard minifier on their JS, but rather they have a custom one (written in PHP) that appears to just do whitespace-style removal, which they appear to run in part of the critical path of serving (?!) rather than as an offline build step. https://www.mediawiki.org/wiki/ResourceLoader/Architecture#Resource:_Scripts https://www.mediawiki.org/wiki/ResourceLoader/Architecture#R... You can 'view source' on a page to confirm that their JS doesn't even do "safe" transformations like local variable renaming.

kevan 7y ago
One of the benefits mentioned is "a transparent "build"-free environment for the developer", so they don't have a build pipeline at all. Plus, with heavy caching thanks to Apache this would probably only get hit on server startup. Given the (self-imposed) design constraints it seems like a reasonable solution. Definitely some room for improvement on the minifier implementation.
- evmar 7y ago
  They mention (in https://www.mediawiki.org/wiki/ResourceLoader/Architecture#JavaScriptMinifier https://www.mediawiki.org/wiki/ResourceLoader/Architecture#J... ) that even with the cache, they can't afford a stronger minifier. Don't get me wrong, I really like the "just ship less code" approach to making apps fast. I am just shocked that running a processor on the code that they do ship to make it smaller was not one of the first things they tried. (Disclaimer: I work in this space and have even tinkered with writing such a tool. http://neugierig.org/software/blog/2019/04/js-minifiers.html http://neugierig.org/software/blog/2019/04/js-minifiers.html )
ryan_lane 7y ago
Were you logged in? MediaWiki treats logged-in users completely differently. It's also possible that mediawiki.org doesn't minify at all purposely to make it easier to view the JS/CSS. There's definitely a minifier at work for anon users.
hinkley 7y ago
Does it really surprise you that people write their own? Or perhaps more importantly here, that people write their own and then never revisit that decision as the industry builds up around them? Sadly all too common in my experience. Disappointing? Absolutely. But few things of this sort surprise me anymore.
- Ididntdothis 7y ago
  They have something that works for them. Why change?
  - hinkley 7y ago
    Because it's a form of vendor lock-in, but for an internal vendor. Also, is it really working for them? We're responding to someone who thinks it isn't.
- evmar 7y ago
  I'm not at all surprised they wrote their own, because it's often the case that people have different use cases, design constraints and so on. I am surprised here that someone attempting to reduce the JS download bundle size after the fact didn't start by running the standard programs (uglify/terser/etc) used to reduce JS download size!
20after4 7y ago
Doesn't gzip already do a good enough job at minimizing the number of bytes used by repeated strings such as variable names? I don't think the ultimate byte count is much smaller (post-gzip) if you change all the variable names to minimal length random strings.
20after4 7y ago
Turns out we've already partially migrated to using webpack. More background: https://phabricator.wikimedia.org/phame/post/view/146/migrating_code_from_mediawiki_s_resourceloader_to_webpack/ https://phabricator.wikimedia.org/phame/post/view/146/migrat...

by evmar 7y ago

kevan 7y ago

One of the benefits mentioned is "a transparent "build"-free environment for the developer", so they don't have a build pipeline at all. Plus, with heavy caching thanks to Apache this would probably only get hit on server startup. Given the (self-imposed) design constraints it seems like a reasonable solution. Definitely some room for improvement on the minifier implementation.

evmar 7y ago
They mention (in https://www.mediawiki.org/wiki/ResourceLoader/Architecture#JavaScriptMinifier https://www.mediawiki.org/wiki/ResourceLoader/Architecture#J... ) that even with the cache, they can't afford a stronger minifier. Don't get me wrong, I really like the "just ship less code" approach to making apps fast. I am just shocked that running a processor on the code that they do ship to make it smaller was not one of the first things they tried. (Disclaimer: I work in this space and have even tinkered with writing such a tool. http://neugierig.org/software/blog/2019/04/js-minifiers.html http://neugierig.org/software/blog/2019/04/js-minifiers.html )

ryan_lane 7y ago

Were you logged in? MediaWiki treats logged-in users completely differently. It's also possible that mediawiki.org doesn't minify at all purposely to make it easier to view the JS/CSS. There's definitely a minifier at work for anon users.

hinkley 7y ago

Does it really surprise you that people write their own? Or perhaps more importantly here, that people write their own and then never revisit that decision as the industry builds up around them? Sadly all too common in my experience. Disappointing? Absolutely. But few things of this sort surprise me anymore.

Ididntdothis 7y ago
They have something that works for them. Why change?
- hinkley 7y ago
  Because it's a form of vendor lock-in, but for an internal vendor. Also, is it really working for them? We're responding to someone who thinks it isn't.
evmar 7y ago
I'm not at all surprised they wrote their own, because it's often the case that people have different use cases, design constraints and so on. I am surprised here that someone attempting to reduce the JS download bundle size after the fact didn't start by running the standard programs (uglify/terser/etc) used to reduce JS download size!

20after4 7y ago

Doesn't gzip already do a good enough job at minimizing the number of bytes used by repeated strings such as variable names? I don't think the ultimate byte count is much smaller (post-gzip) if you change all the variable names to minimal length random strings.

20after4 7y ago

Turns out we've already partially migrated to using webpack. More background: https://phabricator.wikimedia.org/phame/post/view/146/migrating_code_from_mediawiki_s_resourceloader_to_webpack/ https://phabricator.wikimedia.org/phame/post/view/146/migrat...