I can't tell if this is satire or not, but I'm assuming it's genuine.
Compression is not a replacement for minification. The client still needs to parse and run the uncompressed source code. Minification provides measurable performance gains for clients by reducing parse times and p̴o̴t̴e̴n̴t̴i̴a̴l̴l̴y̴ ̴e̴v̴e̴n̴ ̴a̴l̴l̴o̴w̴i̴n̴g̴ ̴f̴u̴n̴c̴t̴i̴o̴n̴s̴ ̴t̴o̴ ̴b̴e̴c̴o̴m̴e̴ ̴s̴m̴a̴l̴l̴ ̴e̴n̴o̴u̴g̴h̴ ̴t̴h̴a̴t̴ ̴t̴h̴e̴y̴ ̴c̴a̴n̴ ̴b̴e̴ ̴i̴n̴l̴i̴n̴e̴d̴ (the inclining part is not true anymore; see child comment).
Licence retention isn't a reason to skip minification either. Practically every modern minified retains licence comments.
And finally, your users can still read the original source code if you ship source maps.
Care about your users, please minify your JavaScript :)
> potentially even allowing functions to become small enough that they can be inlined
Apparently, that's no longer the case, at least in V8[0]
Parse times however are indeed a real concern and start to matter a lot as you go down the list of mobile hardware and their performance. This graph[1] shows parse times for a 1MB bundle of JavaScript in various devices.
Yes, but performance differences between various devices are still fairly significant, as per your own link[0], meaning we probably shouldn't disregard potential performance gains from minification in slower devices.
> Minification provides measurable performance gains for clients by reducing parse times
That sounds like an omission from the talk indeed, assuming the gains are indeed noticeable and not just theoretically measurable. Do you have some numbers for this, or a link to some?
Comparing uncompressed but minified JavaScript to compressed JavaScript is not an honest comparison. Obviously the minified JavaScript would also be compressed and smaller than the unminified JavaScript.
Most of the arguments in this short presentation feel disingenuous. Minified versions of most 3rd party libraries are provided directly by the open source maintainers, so minifying your own code and including their minified library isn't violating anything. Companies are under no obligation to provide their own proprietary source code in a readable format with variable names intact.
Somewhere between 99.99% and 100% of users would prefer the faster loading, more responsive site with minified code. I think the authors started with a conclusion they wanted and tried to walk backward until they found some arguments in favor of their conclusion.
> Minified versions of most 3rd party libraries are provided directly by the open source maintainers, so minifying your own code and including their minified library isn't violating anything. Companies are under no obligation to provide their own proprietary source code in a readable format with variable names intact.
You didn't understand what the speaker meant here. The point is (indeed) not that the license states that you must provide a readable format with variable names intact. You can use map files for that or just link the original where they can find the software for themselves. It's this link and notice that people can go out and use it for themselves, the license that you are required to include, that might be stripped by minification.
If the authors provide a minified, unlicensed version themselves, then that is copyrighted and you're not allowed to use it. You don't have a license without a license, so if the minified version doesn't contain a license, then you can't use it. Likely, there is a separate file or page saying what the code is licensed as and that covers the minified version as well. But that doesn't give you a get out of jail free card: that separate license will (almost always) still say that you have to include a copyright notice somewhere. Perhaps not in the minified file itself, but then elsewhere on the site.
For example, from the MIT license:
> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
> Comparing uncompressed but minified JavaScript to compressed JavaScript is not an honest comparison. Obviously the minified JavaScript would also be compressed and smaller than the unminified JavaScript.
This is dumb. The argument is that minifiers strip out copyright notices, except I'm not aware of any minifier that's actually used these days that doesn't leave in copyright notices by default.
That's also what I was thinking; the latter at least, not the 'this is dumb' part. I do agree with the author that minified javascript is a pain, even if not for the license reason. Sometimes map files are provided, but often not, and it's annoying to have to reverse engineer software that runs on my own computer when, as the author says, the gains are marginal compared to just gzipping the original.
I love the thought behind it, but the sad reality is that browsers prefer minimized code these days. Long and descriptive variable and function names require storage. TypeScript and React generate a lot of verbose code that minifiers chew through (and usually expect that release mode will be minified).
If you want to give your users access to your code, minify (preferably with a minifier that uses newlines where possible) and use source maps.
Browsers don't particularly care about minified vs. unmagnified. Parsing time increases relative to the number of bytes being parsed. If a minified (among other things) strips dead code, that will give you a win.
Do minifiers typically strip dead code? Beyond removing whitespace and unnecessary semicolons, I know they rewrite some if statements into confusing?alternative:formats that save bytes but do the same thing, but really cutting parts out?
Obviously less non-whitespace data to parse will make the parsing faster, but I would be curious whether it bothers trying to detect dead code. It seems similar to a halting problem, knowing whether something can be reached, but I'm not well-versed enough in that theory to really say much more than this gut feeling.
minifies like typescript compilers, etc can remove dead code.
I recall some minifiers that definitely did - whether they're still in use I don't know (I haven't been working in engine dev for a few years).
For JSC's parsing the most expensive things are strict mode, and certain "errors" which basically trigger a rollback in the parser and then a reparse with more validation.
Other than longer variable names taking up more storage, is there anything built into browsers that actually prefers minified code? The only feature I've seen that's related is the pretty-print a minified file option.
Even if you're minifying, providing the .map file is the best of both worlds: users get faster transfer times and slightly more performant parsing, and for those that want the licenses (and even better, the ability to debug easily), they will follow the .maps of the minified code to the full, uncompressed versions.
Minify, include mappings, and you are good to go.
That being said, the most important point the author makes is to ensure that compression is on when you deliver your assets! Whether it be gzip, brotli, or whatever other arcane format, make sure for your users that it is on.
> Minifying stops users from copying the code your site uses for their own sites
Exactly. There are countless JS-powered sites that for any multitude of reasons don't want it to be easy to extract their code. Ignoring whether or not that's "right" or ethical, those sites are fully within their rights to make it as difficult as possible to duplicate the work that they've put in to create their platform.
I would imagine if you asked most C-level and legal teams "is the code on your website something you want people to be able to copy at will?", 95%+ would say they don't want that to be possible, and you might even spur some of them to force their developers to spend time making it _even harder_ to copy.
Unfortunately, the web isn't the free/public/open-source utopia it once was, because a large majority of business takes place online. Sure there are niche sites that still cater to such ideals, but a majority of the population couldn't give a rat's ass if it's easy to copy the JS from Facebook/Amazon/YouTube/etc.
So, one issue not discussed in the comments is transparency and trust. For example, I can take a look at the js in HN, and I can read what it is and know they aren't doing shady stuff. Of course, this is of interest to very few people, and in most pages that make extensive use of js, it's not even practical to revise the code even if it's clear and well documented. I'm personally biased towards serving as little js as possible as clearly as possible, abundant comments included, but many commenters make a good point for focusing on the target audience. I guess if there's not much code and you don't want to hide it, better serve it without minifying, because any picture you end up serving will make the js seem meaningless in comparison, but I still have doubts.
I thought the point of minification was to obscure the code, making it harder to copy? As to "caring about the users", I would be surprised if more than 1 web reader in 1000 is the slightest interested in the source code. Makes more sense to optimise for the target audience.
It’s called minification, not obfuscation. The goal is in the name.
Of course it does also obfuscate to a point where large chunks of code are not easily reusable. You can still easily understand small snippets if you try.
Because it's not needed, you can save even more by minifying + compressing. And if you want to view it normally, either you can get the formatted version of the code just by clicking on pretty print in chrome or ff or you can load from source map instead
The pretty print is far, far from the original. Function names, variable names, comments, structure like if turning into ?:, etc. You indeed need to provide map files and that's often not done. Given how marginal the gains are, I can see the author's point.
Right, but that's where you can split my response into two:
either you minify by removing comments and whitespaces - then pretty print is enough. The other option is that you also mangle the code and obfuscate it, remove variable names etc. and that's when source maps comes into play
What if you want, say, continuous scrolling in your blog?
What's the point of advocating against client-side rendering if the alternative is server-side rendering that only covers some of the features you want?
Trust me, I REALLY do not want most of the features that people trying to shove on me with JavaScript. Continuous scrolling is a wonderful example. My experience of continuous scrolling is that I can't find where I saw something with a search, because the text literally is not there to be found. I also have no idea how far I really have to go. And there is a good chance that the person who implemented it will fail to create proper URLs.
In general when I see people recreating browser features (like display layout) using JavaScript, they do a strictly worse job of it than what is already built in to the browser. Most JavaScript therefore makes my life worse.
But there are things that can be done which are not possible any other ways. Interactive games, live chats, the scrolling in Google Maps and so on. They can be great. But far too often, they aren't. :-(
Compression is not a replacement for minification. The client still needs to parse and run the uncompressed source code. Minification provides measurable performance gains for clients by reducing parse times and p̴o̴t̴e̴n̴t̴i̴a̴l̴l̴y̴ ̴e̴v̴e̴n̴ ̴a̴l̴l̴o̴w̴i̴n̴g̴ ̴f̴u̴n̴c̴t̴i̴o̴n̴s̴ ̴t̴o̴ ̴b̴e̴c̴o̴m̴e̴ ̴s̴m̴a̴l̴l̴ ̴e̴n̴o̴u̴g̴h̴ ̴t̴h̴a̴t̴ ̴t̴h̴e̴y̴ ̴c̴a̴n̴ ̴b̴e̴ ̴i̴n̴l̴i̴n̴e̴d̴ (the inclining part is not true anymore; see child comment).
Licence retention isn't a reason to skip minification either. Practically every modern minified retains licence comments.
And finally, your users can still read the original source code if you ship source maps.
Care about your users, please minify your JavaScript :)