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:
2 Likes
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.
4 Likes
I think you could use as-> instead o fn to give that feeling of edgeness :]
1 Like
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.fillStyle("black")
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.
That is one topic I would like you (cljs developers) to expand on. I really want to see advantages of figwheel over react + webpack hot reloading or even vue + webpack hot reloading. I don’t know if you are aware of it, but it is pretty impressive how good does it work. Maybe figwheel was way better and much more advanced 3 years ago, but I want to know the advantages that it has right now. I really feel that there is a gap between javascript developers like me getting into ClojureScript and ClojureScript developers that long ago left javascript behind. The first time I saw about figwheel a year ago or so I thought “this is just hot reloading, good to have it on ClojureScript but it is not so revolutionary as this guy is saying”. I’m pretty sure that any ClojureScript developer thought exactly the same when he saw the opposite on javascript after years of working with figwheel. I think it is a matter of when and in which order do you discover things. Your reaction could vary from total mind-blow to just a “meh”
1 Like
Thanks all. Actually I was trying to render another page of ClojureScript for beginners, using the domain http://clojure-script.org/ .
In this page I listed some code snippets at the first screen. It’s randomly chosen from https://github.com/clojure-china/clojure-script.org/blob/master/src/app/comp/showcase.cljs#L14 . They are mostly from the top links from Google. Thanks for the inspirations, maybe we can add more snippets there.
Small trick: click on ClojureScript logo on the left top to try a random snippet 
I think you are touching a good point here. I believe most people will claim that getting a Figwheel code reloading setup is much more easier/simpler due to more robust fundamentals of the language. Webpack claims hot code reloading but the fundamentals are shaky due to the nature of JS and the ecosystem, that getting it to work might require jumping through hoops or even eventually giving up. If this is not the case, please do share because it could be that JS has caught up.
One other point that is attractive to me is that CLJS and the surrounding ecosystem feels much more stable. The language is mature, tools are relatively stable, it’s not a moving target. Whereas JS seems to be changing all the time with new syntax and features, which actually rely on tooling that also changes constantly (e.g webpack is already at a new version). JS fatigue is real.
1 Like
Hi Daniel, I think you have touched on a good point.
Webpack hot code reloading does work, and in practice I use figwheel the same way as I would use webpack hot code reloading. This is definitely the main feature of figwheel, but today - I can see why javascript developers would shrug and not be impressed.
However figwheel/CLJS hve two additional enhancements that improve my dev workflow:
Access to the figwheel browser repl. This allows me to test small snippets of logic code before the page refreshes.
Figwheel can also serve a ring handler which allows for complete hot code reloading between CLJ/CLJS. In my experience this is harder to setup with Javascript - although I am limited in experience in that area.
Going forward as javascript tooling improves I think the main selling point of Clojurescript will have to be that it is simply a superior language to javascript (which is admittedly subjective)
1 Like
Hello @briangorman and @orestis, thank you for your positive feedback.
Having a webpack making hot-reloading of the frontend and nodemon making hot reloading on the backend is quite simple and like in clojure, you’ll be working on the same language on both sides.
I think that figwheel is superior on that matter, you don’t have a REPL on the server side. However despite the lack of a REPL I feel that debugging javascript tools are a bit superior to clojure ones. I am not even sure if you can debug step by step on clojure code, something which is extremely helpful.
That is, from my point of view, a common misconception, but I can understand why. Seeing the language from the barrier could make you think that it is a moving target and that you will lose your mind if you try to keep things up. This is due to dozends of blog-posts about the new hotness on JS ecosystem and new developers getting excited about trying every new feature/library that appears. However, one of the weak points of JS is one of it’s strengths too: it is retro-compatible almost to the beginning of times. The language is evolving, sure, new libraries are appearing, that’s true too, but you can stick with your libraries of choice, use the same framework and style of programming for decades and it will continue to work. Then once a year you can pick a new feature (the one you find more useful) and a new library and merge them into your base knowledge, and slowly evolve with the language. Trust me, I have been working with JS for years and I don’t have any fatigue.
Sorry, I think I hijack the thread a second time
@danielo515 I have to say +1 on this. I like Clojure, but every year or so when I try ClojureScript again, it’s a painfully frustrating experience and I go back to JavaScript.
If you know the good parts of JavaScript, its actually quite a nice little language. It supports a lot of the paradigms of ClojureScript.
I think we’re facing a new challenge recently, we’ve got JS devs coming to ClojureScript as an alternative to JavaScript. This was not the intended audience at first. The idea of ClojureScript was to allow a single stack from Clojure to the browser for existing Clojure devs to be able to stick to Clojure all the way down. Devs who want a JVM backend.
But in the world of ClojureScript only, without Clojure, or lets call it ClojureScript all the way up, where it is used with a Node backend, the value proposition isn’t as strong, and also hasn’t been as strongly advertised.
I think immutable first datastructures and design is one advantage. The google closure ecosystem being first class is another. The Lisp advantage, aka macros, homoiconicity and paredit. Its proper module system. Its nicer object model based on protocols and records. And the amazing set of core functional functions. Maybe its reactive support also.
Its a good list, but hard to showcase. And its also a smaller list then what Clojure proper brings.
2 Likes
Well this tweet demonstrates why clojurescript has an edge over JS :
2 Likes
I would instead say that ClojureScript’s power is allowing Clojure to run in places where the JVM either can’t go or isn’t a good choice. This includes the browser (obviously), mobile (React Native, &c), quick-starting scripts and various platforms (included embedded ones) that have embraced the JS runtime because of its ubiquity.
Thinking that CLJS is about web apps requires one to forget that there are many kinds of interesting programs that are not web apps.