on the clj side there is optimization where the go macro tracks if a form uses channel ops(called transitions in the code), and if it doesn't it can emit the form as is without state machining it. something like that on the cljs side would solve the use case mentioned without needing to add a an explicit flag.

Comment made by: metametadata

I still run into this issue and have to use the :jvm-opts workaround from https://github.com/emezeske/lein-cljsbuild/issues/303. In my case the StackOverflow also seems to be connected to is in combination with core.async and try-catch.

To show how bad the interaction is between core.async and a library like core.match that also generates a lot of code consider the following:

Without core.async, core.match produces a reasonable amount of code for this typical use of core.match to efficiently match maps - ~230 lines of pretty printed JavaScript.

But if the user wraps this typical expression in a go block:

It generates nearly 4200 lines of pretty-printed JavaScript. I fail to see the value of core.async transforming the optimized conditionals generated by core.match, it just generates 18X more code and the extra generated code is obviously useless - a user is matching a value, they cannot put arbitrary computations in the patterns.

https://gist.github.com/swannodette/7723758

Can you be more specific? This seems like a bad idea, and I wonder why it's desired.