Getting started with ClojureScript, how robust is it?

Hello all,

This is my first post in the forum !

I am a long time JavaScript developer, and during the last 2-3 months I have discovered Clojure initially and then naturally ClojureScript. I really like the language , mainly for its pragmatic functional approach and due to the fact that it’s a LISP which I have previous experience with from my university times.

I’m interested in using ClojureScript for a full stack application (NodeJS and React) . Is the language suited for that according to your opinion?

One thing I’ve noticed is that a lot of libraries are not maintained anymore or their last update was years ago , is that something I should worry about ?

Also is there somewhere a complete list of recommended well maintained libraries to use for my purpose?

Thank you all in advance,
Sotiris.

1 Like

Hi Sotiris,

great to hear that you like Clojure(Script) and planning to build an app with it. I would say it is very robust. We are very happy with it, we are using it to build Storrito.com and Audiocado.com

I never used ClojureScript for the server side. But I would take a look at:

https://macchiato-framework.github.io/

On the client side I can recommend http://shadow-cljs.org/ as build tool, it is well integrated with npm / yarn. This template is a good starting point:

lein new shadow-cljs your-project +reagent

(https://github.com/shadow-cljs/lein-template)

Clojure and ClojureScript libs tends to stabilize after sometime, most often this is the reason why there are no more commits, while the lib is still maintained. In comparison to many other ecosystems, there are very few breaking changes in those libs and none in the language itself. Therefore you do not have to keep up with the latest versions all the time.

Best regards and happy coding,

Max

3 Likes

Around here, stable libraries are one of the benefits. Clojure/Script isn’t a moving target, so a well-written library tends to last forever unless it has some other Java/Script dependency that can’t sit still.

P.S. Which libraries are you considering?

1 Like

Hey Max,

Thank you for your detailed response, I’ll definitely have a look at the links you recommended.

Another question pops up for me, that maybe someone has an answer.

As I understand, the most common combination is JVM (Clojure) for backend and ClojureScript for front end. But would I miss something if I use ClojureScript full stack ? ( Apart from the platform differences ).

My only argument for choosing ClojureScript full stack is because I’m very familiar with the JavaScript ecosystem.

Thank you again,
Sotiris

1 Like

Hi Phill,

Nothing specific yet regarding libraries, I am playing at the moment with Reagent. I have also tried secretary for routing but later I’ve found a better alternative according to the suggestions I gathered reitit.

1 Like

I did Secretary for a long while, then upgraded to Accountant, but am now very happy with Reitit for all of my teams’ applications. It has excellent development and is nicely data driven, even if you don’t tap into its superpower of working with both CLJ/CLJS.

The reasons I keep JVM back-end is because JVM is extremely battle-tested (industry standard) and, if you desire robustness and industrial performance, Node can’t hold a candle to it. Secondly, the Java ecosystem is very, very powerful (for me this includes Neaderthal GPU-leveraging deep learning and linear algebra possibilities, data4j numerics and AI, caching, portability, Stanford NLP stuff, etc). However, not everyone has those needs, and there are probably other things provided by NPM that might make a NodeJS back-end what you want (there’s a reason NPM overtook Java/Maven for raw number of libraries). So whether to keep the JVM depends on your needs; there isn’t a pure-Clojure reason for one or the other.

Not really, platform differences is all there is to it. I’ve heard of some people using ClojureScript with Node for backend, and like others pointed, the existence of Macchiato shows that.

The only thing is you’ll probably find less material to learn from and less people to help you with a ClojureScript backend compared to a Clojure one.

1 Like

Many Clojure libs only target the JVM. Some can be ported to ClojureScript or rather cljc very quickly. However using Java libs and Java interop is a common practice, which makes porting more difficult. Therefore you have access to way more Clojure libs on the JVM.
I also prefer to have multi-threading, so that I don’t have to use async code all the time. Last but not least I would choose the JVM to be able to use Datomic.

I recently learned that modern Node supports multi-threading with message passing, but not shared memory. I think that was a new development which I found might make choosing Node backend more viable with regards to Java backend.

The remaining limitations would be that the V8 VM is still slower than the JVM for overall computation, though if you are still more on the side of IO bound with occasional CPU work, it seems Node could actually be quite compelling, since its conceptual model is very good at handling async io.

1 Like

@Yogthos, one of Macchiato’s creators could likely comment on why and when they reach for it over Luminus on the JVM. This video (haven’t watched it) says it explains some of the reasons: https://www.youtube.com/watch?v=u2biHsx04Zg

We’ll talk about when and why we’d want to use Node instead of the JVM. Then we’ll take a look at how the Ring stack was ported to Node, and the key differences in using the two platforms from Clojure.

I would go with the JVM on the server unless there was a specific reason not to. The main reasons are startup time, research usage, and platform specific libraries. I think GraalVM is starting to address the first two concerns, but in many environments like AWS Lambda it’s still easier to just use Node. One place where we use Macchiato at work is as a wrapper for Puppeteer to generate PDF documents from Hiccup.

2 Likes

More and more hip libraries exist in the nodejs ecosystem. I had to use it a few days ago, since Java doesn’t have a unified cryptocurrency exchange API library, but npm has. The experience with shadow-cljs was a decent one.

Otherwise I recommend to use Java as a backend target for serious work too.

It’s cool now to use Clojure in 3 huge ecosystems. Years ago we only had Java and the stress with cljsjs in production.