[WIP] Reduce the vanjs file size even more (by 48 bytes, minimized).

[X-Ryl669]

Just for fun and pushing the limit on readability...

This removes all the redundancy in the code, and using some technics seen in #359 to reduce the minimized file size by 48 bytes.
Unfortunately, this doesn't reduce the gzip'd file size, unless using Zopfli for compression (but don't be too optimistic, see below)

Also replaced Infinity with 1/0 (didn't test alone if it compress better with gzip)
EDIT: Tested, it doesn't make any difference, the minimizer already implement this trick.

Right now, here are my attempts at reducing the VanJS package to the absolute minimum without changing any of the algorithm.

Version	Min file size	Gzip size	Zopfli size	Brotli size
1.5.2	2022	1048	1017	935
this PR	1974	1074	1042	968

Zopfli is a gzip compatible compressor that compress better than gzip. It allows to get a vanjs package below 1kB (with 0 effort, just replace the call from gzip to zopfli).
Brotli is a web standard compressor that's only available on HTTPS, but that compress a lot better than you would expect. It's supported on all major browser, so it's definitively the way to go if you serve a HTTPS website. For obscure reasons linked with Google will to force HTTPS into all users mouth, it's not available on HTTP, sadly.

Just a remark, if one is bundling all the modules of her webapp, having a smaller one might gain final bundle size too (unlike here) because there will be more context to compress from.

[Tao-VanJS]

What I saw is that even with Zopfli and Brotli compression, this PR increases the compressed bundle size rather than decreases it. Thus it's not a net gain regardless what compression algorithm is chosen.

Technically, it's the web server who chooses what compression algorithm to use, not the library author. We choose gzip as the benchmark of compressed bundle size because we believe this is the most-used compression algorithm across the internet. We could use other compression algorithm as benchmark if otherwise.

[X-Ryl669]

True. I was trying to see how small it could get after minimization for fun. The code becomes unreadable, so it's clearly not the way to go.

However, for example Nginx, if it finds a .gz or a .br with the same name as the original file will send it instead of the original file, allowing to skip the compression overhead, and use the best compressor / options.

[kiruthikpurpose]

@X-Ryl669

Great effort pushing the boundaries for fun, but you can still go further! Instead of just focusing on byte-level tricks, try context-aware optimizations—for example, eliminating dead code with advanced tree-shaking or restructuring similar logic together to help compression algorithms like gzip/Brotli spot more patterns. Also, consider breaking down the file into smaller modules and lazy-load non-critical parts to reduce the initial bundle size even more. If you're really bold, check out ML-assisted minification tools that analyze code patterns for you—could save you even more bytes! 😎