I won't argue about shadow-cljs, although it's self description doesn't say much about what it does (provide some good defaults). I assume your goal is to use CLJS library in an application bundled for the browser using Webpack. CLJS compiler has an option to emit node.js compatible code using :target :nodejs option. You would presumably use this to bundle up your CLJS project as CommonJS module. With this, you can annotate your public functions like so (defn ^:export do-somthing [a b] (...)) you could then use them in your JS code as myns.foo.do-somthing(a, b) after require() or import your module. So that's how you would use your module in production build. If you want live coding, I think figwheel is amazing in what it can do, far more than Webpack's HMR (eg. CIDER, Fireplace, ...). If you want to use live-code your CLJS library in your Webpack JS application, you can comment out the require() or import in your JS client code, and include Figwheel enabled JS file in an extra <script> tag. Hence you won't use Webpack's HMR for CLJS code, you will get faster reloads, and you will be able to eval code from your editor, in your running Webpack app in the browser, and you won't need additional dependency on shadow-cljs