I'm the author of shadow-cljs.
Replacing figwheel it not the intent here. Enabling JS tools to work better with CLJS is. I made a quick video demo showing how you can use CLJS with "create-react-app" with zero configuration. (Also works with "create-react-native-app" but the video would be too long).
youtube.com/watch
I'm working on some written guides too ... this is all very new still.
If you already have a large JS codebase with HMR configured and just want to gradually introduce some CLJS you don't have to adjust anything. It just works.
If you already have figwheel working for you there is no reason to switch.
fighweel has one definite advantage: Documentation.
I'm trying to work on that but it is going to take some time. As 题叶 said: This is early stage.
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 :nodejsoption. 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 asmyns.foo.do-somthing(a, b)afterrequire()orimportyour 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 therequire()orimportin 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