3 ms·
Agreed. I suspect one current thing hurting adoption from the JS community is the very heavy JVM based tooling. With the Google Closure compiler now running on
by ledgerdev 9y ago
Agreed. I suspect one current thing hurting adoption from the JS community is the very heavy JVM based tooling. With the Google Closure compiler now running on top of JS, there would seem to be a path for the CLJS(not clj) tooling to become more JS ecosystem friendly.
For the JS developers out there, is this something that's of interest? Or is the existing tooling(lein) good enough? What would be your ideal tooling story?
- philbo 9y agoAs a JS programmer with some Clojure experience I can confirm that the JVM is absolutely the biggest turn-off for me personally. Lisp syntax, immutable data structures, laziness, all splendid. The build/runtime environment, not so much. Sounds like I should revisit CLJS based on your comment.
- ledgerdev 9y agoWell at the moment, the tooling is all lein/JVM based. That said, Figwheel hooked up with atom+protorepl+parinfer is pretty amazing if you haven't tried it. https://github.com/bhauman/lein-figwheel https://github.com/bhauman/lein-figwheel https://www.youtube.com/watch?v=0WMga5E7Vsk https://www.youtube.com/watch?v=0WMga5E7Vsk
- lsdafjklsd 9y agoParinfer is a huge game changer. Everyone afraid of writing lisp needs to try again using parinfer.
- owebmaster 9y agoI like leiningen. The stability is something I never saw anywhere. You have plugins without updates for like 2 years and working like it was updated recently. Although it is becoming less common for clojure/script projects to be unmaintained.
- lilactown 9y agoAs a JS developer using CLJS in my spare time, I've found that once I got my project setup with figwheel and everything, I can pretty much ignore the JVM. The moment that "classpath" is mentioned I usually try to find another way, though.