There are many differences regarding code splitting to the regular CLJS implementation. shadow-cljs actually predates that implementation by quite a while and I’d argue has been used more extensively. In the beginning it was actually the reason I created the tool (then shadow-build) in the first place.
Regarding actual differences:
- Basic code splitting for npm packages. Granted regular CLJS can’t import these at all but with
:target :bundleyou only get one JS package that contains all npm dependencies. In shadow-cljs each module/chunk will only contain the npm packages it actually uses. This can be a rather significant difference in larger projects, since npm packages can be moved to edges and lazy loaded. - Helper utils like shadow.lazy (which require compiler support) make things like the
lazy-componentdescribed in my blogpost possible. - Enhanced compiler support so that things like
(cljs.loader/set-loaded! :foo)are not required and added automatically - A couple error messages when your config leads to invalid results (such as empty modules)
- There is no implicit base module. You have more control over your splits.
- Overall easier config I’d argue
- I consider Build reports essential for figuring out what your modules/chunks look like after optimizations
- Built in support for cacheable output, which is otherwise rather difficult since you cannot change the filenames after
There might be other things I’m forgetting. You can get most of this done with the regular CLJS compiler but it’ll take a little more work.