This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-03
Channels
- # announcements (1)
- # babashka (22)
- # beginners (176)
- # calva (10)
- # cider (4)
- # circleci (5)
- # cljsrn (20)
- # clojure (28)
- # clojure-europe (11)
- # clojure-italy (5)
- # clojure-nl (5)
- # clojure-spec (1)
- # clojure-sweden (2)
- # clojure-uk (29)
- # clojuredesign-podcast (4)
- # clojurescript (38)
- # code-reviews (25)
- # conjure (1)
- # core-typed (1)
- # data-science (16)
- # datomic (23)
- # figwheel-main (16)
- # fulcro (48)
- # helix (9)
- # jobs (3)
- # juxt (5)
- # kaocha (17)
- # malli (19)
- # mount (9)
- # nrepl (4)
- # off-topic (35)
- # pathom (7)
- # re-frame (28)
- # reagent (26)
- # reitit (1)
- # releases (1)
- # remote-jobs (5)
- # sci (6)
- # shadow-cljs (36)
- # spacemacs (3)
- # sql (8)
- # tools-deps (13)
- # unrepl (1)
- # vim (4)
- # xtdb (8)
What benefit has using figwheel main over shadow-cljs? It's ok to give a biased answer, I'm also going to ask in #shadow-cljs
To me, this question feels like a category error: It is not figwheel/shadow. For me the choice is cljs.main/shadow, with figwheel as a dev tool.
This is how I compile the prod version of the app:
clojure --main cljs.main --compile-opts common.cljs.edn --compile-opts min.cljs.edn --compile-opts prod-config.cljs.edn --compile
I strongly prefer the simplicity of that, and the building blocks that give me.
Choosing shadow-cljs
, means that you choose to use shadow to go cljs->js. I choose cljs.main
.
Having made that choice, figwheel-main
affords me awesome development convenience. And I love it for that.
I go through the song and dance of webpack, pre :target :bundle
, to bring in dependencies. I am ok with that, since taking on a new dep should have friction. It is a decision point. Soon I will look into :target :bundle
and see what that simplifies for me.
I am no expert on this, but Figwheel-main seems less complicated to use than shadow-cljs for development, especially where you are predominantly using Clojurescript. If using lots of (bleeding edge) JavaScript packages via npm is important, then shadow-cljs seems to have advantages. Very interesting to read @U9E8C7QRJ comments, seems a very interesting approach.
might be late for the party but i just love shadow
i dont have list of pros and cons but my experience.
i developed website using figwheel-main and sometimes i had issues with advanced compilation where i had to turn on warnings about infers to spot the issue.
with shadow i never had issues like that and also i use a lot of npm
and i never had an issue with that.
Before this i used luminus (and figwheel) so adding anything npm was annoying as hell.
Mind you i am just novice but those are my experiences. It is very possible that i am attaching my lack of knowledge to tooling
@borkdude Aside from my long reply - we use a version of https://github.com/pesterhazy/cljs-spa-example/tree/master/doublebundle to manage our npm deps. And then I commit (the horror) the resulting npm-libs-bundle-min.js
and npm-libs-bundle.js
- this way my team mates don’t have to touch npm
or even have it installed.
Everyone should hold off installing Big Sur as it breaks file watching in Figwheel https://github.com/bhauman/figwheel-main/issues/253