Which piece of code do you think makes ClojureScript significant?

It’s like showing why ClojureScript is ClojureScript, and why it’s different and it should be learnt. If possibly that can be shown with a piece of code.

1 Like

Are you looking for code that can be showcased in a landing page? :slight_smile:

1 Like

Yep. I’m still trying to introduce ClojureScript to wider audience around me and my friends.


Somewhat more specific than ClojureScript: I found Reagent (or other React wrappers) the pivotal library to go for ClojureScript instead of something else. A little example where you can have an atom for state and a function as a React component which reacts on that state in a couple of lines: mindblowing.

But just having a sane coherent language and tooling instead of JavaScript + NPM etc. is worth it. No ImmutableJS/Ramda/etc. needed, it’s all immutable and functional first.


I think this front-end framework comparison makes a pretty good case https://medium.freecodecamp.org/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-2018-update-e5760fb4a962


That is just not true. The npm tooling ecosystem is outstanding and easy to use. You can go from 0 to a working skeleton in a matter of seconds. There are plenty of yeoman templates for literally any setup that you want. Not to mention that yeoman is a tool without competitors. If you think that lein templates are the same thing you definitely don’t know yeoman.

When I started with JS it was easy to me to pick the tools up, while starting to work with clojurescript was a nightmare.

In my opinion what makes the language significant is it’s philosophy. You can’t compete with npm in easy of use or libraries.
Also saying that you don’t need as many libraries will not convince anyone since installing a library on JS and start using it is a matter of 2 lines npm i library + require(library) so nobody is worried about installing ramda or immutable.

People nowadays is becoming more convinced about FP and immutable data, so the selling point of CLJS is that it is a language with those principles built in / first class


Let’s focus on the point we agree on:

the selling point of CLJS is that it is a language with those principles built in / first class

Yes. JS + ImmutableJS is not coherent in the sense that you always have to wonder: do they use an Immutable data structure here or a plain mutable object? In CLJS you don’t (unless you’re doing interop).


For what it’s worth, my experience with Yeoman has been quite different - it found it baffling by how bad the default were from so pretty popular templates. It essentially gets you started very quickly with a ball of mud.

I see Yeoman more as a symptom than an asset to the JS ecosystem - more precisely, a symptom that any JS project requires a LOT of tooling to provide a reasonable workflow. We simply don’t need that much tooling in CLJS, because we have an all-tracks syntax, macros, a powerful REPL environment, and a comprehensive standard library.


I don’t want to leave your comment unreplied, but I don’t want to steal the thread neither. I agree to some point with you, but I don’t want to continue the off-topic that I started, shame on me. If you want to continue this “discussion” about the topic we can do it through other dedicated topic.


1 Like

(swap! state-atom update-in [:a :b] + 10)

Here is the workshop I like to give that builds up to this and extracting this pattern into a little cursor abstraction: https://docs.google.com/document/d/1GdRjOmq9GaSp0ej-c_WM3jLjU98_BvDUUaZE93_QWig/edit#heading=h.wwy2uel0h5r


Maybe some code about piping ? It’s one of the nicest features, and one of the hardest things to see clearly on javascript.

1 Like
(-> {:data "is all there is"}                               ;;<-- data
    (get :data)                                             ;;<-- query it
    string/upper-case                                       ;;<-- transfrom it
    ((fn [query-res]                                        ;;<-- render it
         [:div (str "don't be fooled... data " query-res "...and sometime we render it somewhere")]))) 
1 Like

Reminds me of this thread:


Not a piece of code, but I tried to express the value prop of CLJS to a JS crowd in a meetup a few years ago, still relevant IMO: http://slides.com/valwaeselynck/clojurescript-parisjs#/, especially this slide.


I think you could use as-> instead o fn to give that feeling of edgeness :]

1 Like

3 posts were split to a new topic: Meetup in Shenzhen, 15 April

I like doto it cleans up a lot of redundancy usually present in js code while setting parameters.
For instance clearning and setting canvas context in a javascript

would be like

var clearCanvas = function(state) {
    let canvas =  document.getElementById("board")
    let context = canvas.getContext("2d")
    const size = state.pixel
    const width = state.width * size
    const height = state.height * size
    //Calling functions on the same context again and again redundantly.
    context.clearRect(0, 0, width, height)
    context.fillRect(0, 0, width, height)

while in clojure it looks like :

    (defn clear-canvas [state]
      (let [canvas (.getElementById js/document "board")
            ctx (.getContext canvas "2d") size (@state :pixel)
            width (* size (@state :width)) 
            height (* size (@state :height))]
        ;; Meanwhile in clojure we can use **doto**
        (doto ctx
          (.clearRect 0 0 width height)
          (set! -fillStyle "black")
          (.fillRect 0 0 width height))))

Lastly Clojurescript looks so elegant, JS looks dumb.

1 Like

Lastly Clojurescript looks so elegant

agreed. There is so much meaning conveyed by the syntax alone… when you squint your eyes, it is like going up a level of abstraction and seeing pieces of a puzzle.

1 Like

You should stop thinking about examples that are almost identical to javascript but with a different syntax. I think your feel of elegance just comes from the fact that you are familiar with ClojureScript. The javascript example is even shorter and very clear for anyone while the ClojureScript one will only be obvious to those that already know the doto macro and the atoms. On your doto example you are just saving one word, because you are writing canvas and doto (2 words) just to save you writing canvas 3 times.
In my opinion we are not going to convince any js developer with syntax comparisons, we need to enforce the benefits of cljs for functional Programming wich is the big thing right now

Haha, you are right this wont convince a JS developer, but we have fig-wheel for that purpose.