Hacker News new | ask | show | jobs
by ledgerdev 3317 days 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?
3 comments
philbo 3317 days ago
As 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.

link
ledgerdev 3317 days ago
Well 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://www.youtube.com/watch?v=0WMga5E7Vsk

link
lsdafjklsd 3317 days ago
Parinfer is a huge game changer. Everyone afraid of writing lisp needs to try again using parinfer.
link
lilactown 3317 days ago
As 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.
link
owebmaster 3317 days ago
I 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.
link