Hacker News Reader

Comment by evmar | Hacker News Reader

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#R...

You can 'view source' on a page to confirm that their JS doesn't even do "safe" transformations like local variable renaming.

View on HN

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.

They mention (in 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 )

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.

They have something that works for them. Why change?

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.

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!

Turns out we've already partially migrated to using webpack.

More background: https://phabricator.wikimedia.org/phame/post/view/146/migrat...

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.

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.

Reply on news.ycombinator.com