I’m glad you’re thinking about this! “Clojure is hard to get started with” and “Clojure is for experts” is becoming somewhat of a trope.
I’d like to suggest getting started with Clojurescript.
- A guided path with clear goals that leads to a pleasant development experience. Concretely:
a. What does a good development experience look like?
b. How does one actually set up that devlopment experience?
To provide some context, let me provide my own history on the topic.
Lets go back to 2016. Meet Teodor. He likes programming, knows a bit of Python, Java and C#. He has dabbled with Haskell, and gotten bit by the functional pill. Haskell just feels right. From Java, so much can just be removed, things feel tight. But how does one deploy Haskell code? Compile a binary. Oh, so that’s dependent on dynamic linking and static linking. And I can’t just copy the binary to the server. I might have to compile it on the server. That means my 1 GB VPS runs out of memory. Ouch.
Enter Clojure! Run a
lein uberjar, and your application code and static HTML files are collected into a nice little artifact that can be copied over to the server. Now that’s sweet!
But how do we do frontend development? Hmm. Teodor would like to keep the functional sweetness. And Clojure is nice! So Clojurescript sounds good.
… So he manages to compile some Clojurescript and put it on a web site, but its development doesn’t really feel like Clojure. You can’t start a REPL and talk to it. Instead, you must start a live-compiler (that does magic work in the background, not just running the forms you send to it), open a browser and connect to that running process from an editor. Which means you can no longer just start the REPL and do things.
Time passes. 2017 goes by with a bit more Clojure and Python. 2018 comes around, and Teodor starts getting into “real” deployments where you have to think about servers, systemd, nginx, HTTPS, and finally begins to understand the concepts behind continuous delivery. He becomes comfortable making Clojure reach further than “build a jar and run it somewhere”, and looks into PAAS solutions like Dokku. He learns to set up his own Dokku instance on a DigitalOcean droplet, and find that to be quite nice. Not having to configure Nginx with Let’s Encrypt and run the application with a systemd unit file simplifies a lot.
All the while, he tries getting a solid REPL-integrated Clojurescript development experience. For Clojure, CIDER+Spacemacs works very well, but with Clojurescript, he runs into issues with missing CLJSJS libraries when he tries to use Figwheel, and turns to Shadow-CLJS. But that REPL is flakey. And he knows that probably won’t be a problem when he finally learns all the things that go on underneath. What really happens in CLJS repl? He just wants that
C-c C-c to work with Clojurescript. He relies on documentation lookup and autocomplete from his editor – which again requires to be REPL-integrated.
As 2019 passes along, he seriously investigates Shadow-CLJS. Some pieces begin to fall into place. Perhaps jacking into a Clojure REPL and using the API to launch a CLJS repl from there is the way to go. He manages to fix a few of the issues he runs into using oz from Shadow-CLJS through the help of the maintainer and another kind soul. He feels that he is coming closer to a nicer development experience, but still wonders: is this the right target? Lately, working through Jacek Shae’s Learn Re-frame has been helpful.
So that’s been me. Easier to look back at it in the third person, I guess. Still,
Considering you’re making Klipse, I guess you don’t have the same kind of struggles that I do! But that’s my suggestion. Hope it helps!