This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-11
Channels
- # admin-announcements (10)
- # arachne (2)
- # beginners (74)
- # boot (302)
- # cider (49)
- # cljs-dev (11)
- # cljs-edn (7)
- # cljsjs (13)
- # cljsrn (1)
- # clojure (164)
- # clojure-austin (1)
- # clojure-brasil (3)
- # clojure-finland (2)
- # clojure-greece (4)
- # clojure-russia (48)
- # clojure-uk (11)
- # clojurescript (138)
- # community-development (1)
- # cursive (13)
- # datascript (1)
- # datomic (19)
- # emacs (4)
- # events (1)
- # garden (1)
- # hoplon (123)
- # jobs-discuss (9)
- # keechma (5)
- # lein-figwheel (4)
- # leiningen (2)
- # luminus (15)
- # mount (1)
- # off-topic (8)
- # om (66)
- # on (1)
- # onyx (28)
- # other-languages (2)
- # planck (1)
- # proton (5)
- # re-frame (18)
- # reagent (15)
- # untangled (15)
the proposal is in two parts now
I just want the spiritual equivalent JavaScript’s package.json file
JS suffers from fragmentation, and the central config and task interface are optional means for solving it
I think if we take the optional approach, that is, you can use the builds part if you just want that, tools can start adopting them piecemeal
i’ll wait for comments before building something for marketing it
@shaunlebron: I may be wrong but it seems that you are heading down the road of a third build tool, but one that focus's on ClojureScript, in the short term I'm uncertain that this will clear up or help folks that are new to ClojureScript. A build tool is a yuge undertaking, take a long look at the issue and commit history of lein and boot and gulp, etc. You are probably going to need to use Java or Clojure in this tool so this begs the question ... why another individual build tool? I would suggest that we work to move our current build tools forward in relationship to ClojureScript in terms of ease of use. It's really hard to divorce ClojureScript from Clojure. If you look at the State of the Clojure, Clojure is still the dominant backend and if you ask me this is a very sound technical decision. You could say that this is because the build tools favor Clojure users but I don't feel that is entirely fair. I guess what I'm saying is let's make changes that will get adopted using the tooling we have available. I see this as very possible at the library level, if we create libraries that are extremely attractive for tools to use. Libraries for ClojureScript compilation and use, that provide good configuration, feedback and validation. If your focus is to build a tool to bring equivalence to self-hosted and Clojure based CLJS, I think it is really early and you would probably end up creating a tool for only self-hosted CLJS as it would ignore the needs of the vast majority of ClojureScript users who rely on the Clojure environment for their backends.