Clojurians Log v2

the most impactful build size wise is :shadow-keywords. turns new $("shadow.cljs","init-complete?","shadow.cljs/init-complete?",-609406251); into O("shadow.cljs","init-complete?");. basically one step further for the optimize constants thing. new cljs.core.Keyword repeats the namespace string, and the hash is not very gzip friendly. impact varies greatly between build using a lot of namespaced keywords, or even just keywords. I've had reports for this shaving off between 5 and 10% of the gzip'd build size. basically just introduces a https://github.com/thheller/shadow-cljs/blob/4a20a459baf49fb1a78227a03cfe8bdac4b121d6/src/main/shadow/build/closure.clj#L683-L685 and rewrites new cljs.core.Keyword to use that instead. never could measure any difference regarding the dropped hash value, so just removed it.

others are more about aesthetic than about build size. defonce just turns into def for optimized builds. defonce can leave a rather nasty and long typeof chain for namespaces with many segments, which just isn't needed for optimized builds. that just annoyed me, but no measurable difference for build size really.

I also implemented https://ask.clojure.org/index.php/8879/cljs-should-macros-support-lifting-vars-to-the-ns-level, which shaves a bit of reify. but also not really measurable

I know I had some more but can't even remember what they are, but again very minor stuff

only thing with any impact really is the constants thing

ok the constants thing is interesting - that could just be something :lite-mode does, drop the precomputed hashes

doubt people using :lite-mode are gonna be very keyword heavy

keyword don't add that much as far as I can tell.

basically all the non-collection types are not that bad.

I can believe the compression problem though