This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-18
Channels
- # adventofcode (62)
- # aws (5)
- # beginners (59)
- # calva (63)
- # cider (26)
- # cljdoc (1)
- # cljsrn (22)
- # clojure (99)
- # clojure-austin (1)
- # clojure-dev (19)
- # clojure-europe (4)
- # clojure-hamburg (2)
- # clojure-italy (3)
- # clojure-nl (23)
- # clojure-spec (2)
- # clojure-uk (85)
- # clojurescript (41)
- # core-async (17)
- # cursive (20)
- # data-science (11)
- # datascript (2)
- # datomic (31)
- # emacs (7)
- # figwheel (28)
- # figwheel-main (12)
- # graphql (2)
- # hyperfiddle (3)
- # juxt (1)
- # kaocha (2)
- # leiningen (5)
- # nrepl (13)
- # off-topic (45)
- # pathom (13)
- # pedestal (11)
- # re-frame (20)
- # reagent (10)
- # shadow-cljs (92)
- # spacemacs (9)
- # sql (39)
- # tools-deps (32)
- # unrepl (3)
Tried figwheel main for a new hobby project and I’m very happy with it. Thanks @bhauman!
@braden.shepherdson figwheel main does not depend on client cloud
@braden.shepherdson also you “should” be able to do JS only development in figwheel if you follow the goog closure conventions
Sort of related, a general CLJS question. Does compilation emit normal Google closure library files? If so, I should be able to mix CLJS into Google's lazy loading system easily too.
excellent news. all my schemes are progressing beautifully.
I'm trying to knock down possible objections, and integrate nicely. CLJS plays so well with others, I love it.
I want to hook into the translation tools, build system, JS module system, still have Figwheel reloading. then I'll build a prototype that runs inside the Google infrastructure, and demonstrate what small, fast and high-leverage really are.
... and then I'll get burned at the stake as a heretic, figuratively speaking, and switch teams 😞
