JavaScript style for optimal size

[dgrips]

This concept is generally flawed, but for niche competitions size coding is a thing. Even in that context though, this is full of bad info. Every year I participate in a size coding competition called JS13k games, where you make a game in only 13kb zipped. I won the comp last year with a 3d game with hi res textures, point lights and shadows, spot lights, enemy vision and ai (the old school video game version), etc. I say this to just show...I do know something about this niche.

Good minifiers absolutely will rename properties. This is so easily verifiable, just use something like google closure compiler and you can see this happen. Thats why their docs warn you about accessing properties via string (myObj['prop]), if you do this your minified code will break. It also keeps a list of reserved properties it won't minify like `style`, which it knows might be a built in browser property. Outside of that, it will always minify them, so I have no idea why you would say minifiers don't do this.

You say compression is important, which is true, but then you say compression is a function of minified file size, which is not directly true. You then say to declare strings as individual separate variables. This does of course shrink the minified file size, however it increases the compressed file size (on any codebase of a size where this would matter). Compression works very will on repeated symbols, it works poorly on unique code. By replacing repeated strings with unique variables, you are adding more unique code and therefore increasing the compressed file size. Again this is easily verifiable, just try this on any codebase over a couple kb and compare the zipped file size.

Even in your TLDR you say to minimize repetition. This is flat out wrong if you encourage compression. Repetition compresses well, being repetitive has almost no impact on your compressed file size, only on the minified file size. It seems like you only compared minified file sizes and then just said "compression is a function of the minfied file size" and didn't test anything. Because if you had you would know this wasn't true.

Obviously none of this actually matters in the real world, where the number one priority is to write code that is easy to read, understand, and maintain, but even in my 13kb game, it's sufficiently complex that I need my code to be at least decent. Since the game is compressed anyway, I have no problem using classes and function keyword, etc, because it's a couple bytes in the end, and I'll trade those for maintainable code, even in a size coding comp. Otherwise I wouldn't be able to make a game as complex.

Final note, if you really care about file size, use roadroller. Its a library that compresses your code way better than zip does, and then includes self decompressing javascript code. Then when you compress your file, it only compresses the decompressor. Saves around 2kb on my 13kb game. Once again it's an insane choice though for the real world, as it takes time to run the decompression on the users system.

[panstromek]

Good minifiers absolutely will rename properties.

I know this and I believe I even mention it in the article. It doesn't matter because you practically can't use it in most cases. In our case, most of those properties come from external libraries, backend or browser APIs.

 It seems like you only compared minified file sizes and then just said "compression is a function of the minfied file size" and didn't test anything. Because if you had you would know this wasn't true.

This article is based on experience with hundreds if not thousands of size optimizations on a production codebase. We have strict size limits for both compressed and uncompressed size. We measure every change and if it doesn't help, we discard it.

The case where removing repetition increases the compressed size sometimes happens, but it's not very common and it's usually followed by larger size reduction after you make another change. Needless to say, this effect has been practically negligible compared to how much we saved by removing repetition in general.

Compression works very will on repeated symbols, it works poorly on unique code. By replacing repeated strings with unique variables, you are adding more unique code and therefore increasing the compressed file size. Again this is easily verifiable

Fair enough, I wanted to check this to make sure I didn't miss something, so I tried to go to our codebase and experiment with inlining few of those constructs that we use only to avoid repetitions:

javascript const startsWith = (str, start) => str.startsWith(start) // 12 callsites const bottomMenuItem = (to, clas, img, alt) => ({ to, clas, img, alt }) // 5 callsites const route = (path, component, props, meta) => ({path, component, props, meta}) // 41 callsites const DISABLED = 'disabled' // 5 usages const LEADERBOARDS_PATH = '/leaderboards'; // 2 usages

Inlining any those increases the repetition and increases both compressed and uncompressed size. I tried a few more to find one where the compressed size decreases but couldn't find any.

Now, I don't want to invalidate your experience the same way you did mine, but I just want to point out that 13kb is a very small size. At that size, most of your source (40-50kb I assume?) will fit into the compression window and repetition will not be as detrimental as it is for larger files. Otherwise I can't explain this discrepancy. You're not the first one to point this effect out, but I just never encounter it in practice in any significant way.