FWIW I changed it so idents are their own type. wanted to do that for a while, so I guess it was time before people actually start using this 😉

It's probably not supported right now, but could it theoretically be supported that the build report shows the function size too, so I know where to look if I want to optimize something for size?

function size?

the way I typically look for thing for optimize is running a release build with --pseudo-names and then going over the generating sources. it is fairly easy to identify large chunks and associating them with their respective sources

takes a bit of practice

a test build with :modules may also help. so :modules {:code {:entries [cljs.core]} :target {:entries [the.namespace] :depends-on #{:core}}

so target.js will only contain code from the namespaces I'm trying to tweak

My issue is that in SCI I'm re-implementing macros as normal functions: e.g.:

(defn foo [_ _ body] `(do ~@body)) 

well backtick itself doesn't generate a lot of code

the unintepreted datastructures do

so new cljs.core.List([new cljs.core.Symbol("do", ... and so on

dunno how you'd shrink that

This is what you see in the outputted JS:

user=> '`(do ~@body)
(clojure.core/seq (clojure.core/concat (clojure.core/list (quote do)) body))

user=> '(list* 'do body)
(list* (quote do) body)

hmm but those are not equivalent?

I mean yes, the concat/seq stuff is not ideal but in the end that is only a small part no?

It gets way worse when your macro isn't trivial like the above

Normally in CLJS this isn't a problem, since the JVM deals with this boilerplate at compile time - only if you pull the macro to runtime

I mean yeah I get that. constructing big nested datastructures yields a lot of code

hmm dunno how you'd optimize that