ClojureScript Unraveled(funcool.github.io)
funcool.github.io
ClojureScript Unraveled
http://funcool.github.io/clojurescript-unraveled
3 comments
> [C]ould I start using something like ClojureScript instead of Javascript and be able to use the libraries I currently use, like I would with coffeescript?
Clojure has an opinionated idea about how data should be handled and changed over time. This interacts very poorly with data binding so if your current libraries are Ember, Angular, Knockout, or the like then the answer is no. You can call into any JS library fairly easily so if you want to use jQuery, d3, three, or whatnot then it's doable but not in the "it's just javascript" way of coffeescript.
On the other hand, Clojure fits into the React model like toothpaste in tubes and the community has switched almost universally (save the Hoplon guys) to one of the React wrappers. I recommend starting with Reagent [1]. Om has more mindshare but Reagent's model is considerably simpler. If you need more structure around the app, check out Re-frame [2]. In either case you want to set up your project with figwheel [3] (lein new figwheel <project>) and add reagent/re-frame as a dependency.
[1] http://holmsand.github.io/reagent/ [2] https://github.com/Day8/re-frame/ [3] https://github.com/bhauman/lein-figwheel
I encourage you to give the langauge a try but I don't really recommend Clojurescript at work unless you're already working at a Clojure shop. The language is nicer than Javascript and I care enough about that to take a job working in cljs full time but the language isn't mature nor enough of a productivity boost over js (especially babelized js) to justify saddling your company with a niche language maintenance burden when you leave. If you're going to evangelize, I recommend starting in Clojure where the win over Java is much, much bigger.
P.S. I use Vim for everything non-lisp but I use Emacs with Evil mode for lisps. Evil mode is bar none the best vim emulator I've used and is the only one I can stand to use on an extended basis.
Clojure has an opinionated idea about how data should be handled and changed over time. This interacts very poorly with data binding so if your current libraries are Ember, Angular, Knockout, or the like then the answer is no. You can call into any JS library fairly easily so if you want to use jQuery, d3, three, or whatnot then it's doable but not in the "it's just javascript" way of coffeescript.
On the other hand, Clojure fits into the React model like toothpaste in tubes and the community has switched almost universally (save the Hoplon guys) to one of the React wrappers. I recommend starting with Reagent [1]. Om has more mindshare but Reagent's model is considerably simpler. If you need more structure around the app, check out Re-frame [2]. In either case you want to set up your project with figwheel [3] (lein new figwheel <project>) and add reagent/re-frame as a dependency.
[1] http://holmsand.github.io/reagent/ [2] https://github.com/Day8/re-frame/ [3] https://github.com/bhauman/lein-figwheel
I encourage you to give the langauge a try but I don't really recommend Clojurescript at work unless you're already working at a Clojure shop. The language is nicer than Javascript and I care enough about that to take a job working in cljs full time but the language isn't mature nor enough of a productivity boost over js (especially babelized js) to justify saddling your company with a niche language maintenance burden when you leave. If you're going to evangelize, I recommend starting in Clojure where the win over Java is much, much bigger.
P.S. I use Vim for everything non-lisp but I use Emacs with Evil mode for lisps. Evil mode is bar none the best vim emulator I've used and is the only one I can stand to use on an extended basis.
I don't think Om necessarily has more mindshare (although it does have a significant amount), just that Reagent people are a perhaps a little less vocal (or at least, have their discussions on their own mailing list).
I would also recommend Reagent + re-frame + figwheel, which I'm using for my current project after having used Om for many months previously. Its an excellent model for writing complex apps.
I would also recommend Reagent + re-frame + figwheel, which I'm using for my current project after having used Om for many months previously. Its an excellent model for writing complex apps.
Big +1 for reagent + reframe + figwheel.
We're using it to build a medium-large web app and it's been working out great. Being able to reason about the state of UI hasn't been this easy for me before.
We're using it to build a medium-large web app and it's been working out great. Being able to reason about the state of UI hasn't been this easy for me before.
Thanks for the writeup! I'm currently experimenting with Ring/Liberator on the server side and Mithril on the client, and was unsure whether I should just use ClojureScript or plain JS. I chose plain JS for simplicity, but damn, reagent and figwheel look like a killer combination.
To me it seems client side Clojure is a bit harder at first than server side, since most of it has to do with mutating DOM state - do you think thats true?
It is difficult, which is why Clojurescript adoption didn't really take off until React (via Om) showed up. The whole point of the virtual dom model is to avoid stateful DOM manipulation and instead have view code that is an idempotent (and generally pure) transformation from app state to virtual dom. This is a great fit for any functional programming language and makes keeping the DOM in sync mostly a solved problem.
I haven't tried Mithril in cljs personally but it fits the model so you should be fine with just writing a wrapper function or macro to save some boiler plate on the cljs to js data structure conversion.
The challenges in the cljs app I'm working on are the same challenges you run into any app: how do you separate concerns, where does state reside, how do you keep it in sync with the server, etc. A problem that's unique to React based apps is how to get data from your app state to a component without higher level components needing to be changed.
My main annoyance with cljs is that rethrowing errors in Chrome swallows the stack trace and core.async wraps everything in a try/catch block. This means that you need to debug by breaking on error, typing `ex.stack` in the console, and reading compiled JS frames to find the source.
I haven't tried Mithril in cljs personally but it fits the model so you should be fine with just writing a wrapper function or macro to save some boiler plate on the cljs to js data structure conversion.
The challenges in the cljs app I'm working on are the same challenges you run into any app: how do you separate concerns, where does state reside, how do you keep it in sync with the server, etc. A problem that's unique to React based apps is how to get data from your app state to a component without higher level components needing to be changed.
My main annoyance with cljs is that rethrowing errors in Chrome swallows the stack trace and core.async wraps everything in a try/catch block. This means that you need to debug by breaking on error, typing `ex.stack` in the console, and reading compiled JS frames to find the source.
Sounds like React is going on my todo list (picked AngularJs for my current project so have to stick with it).
Great suggestions btw, and I absolutely agree with Clojures a big win over Java, I was actually very briefly learning myself Clojure during Java and algo labs but the teachers didn't appreciate that at all :(
> P.S. I use Vim for everything non-lisp but I use Emacs with Evil mode for lisps. Evil mode is bar none the best vim emulator I've used and is the only one I can stand to use on an extended basis.
I love reading that, I have been using Vim for 4 years or so, but for a month or two I actually managed to switch to emacs with evil-mode. I did however notice that my knowledge of the different modes was too limited, and I was basically just using vim in emacs, so dropped it again. Since today I actually switched back to Emacs, found my self-written cheat-sheet and so far it's going great (no evil-mode so far).
Great suggestions btw, and I absolutely agree with Clojures a big win over Java, I was actually very briefly learning myself Clojure during Java and algo labs but the teachers didn't appreciate that at all :(
> P.S. I use Vim for everything non-lisp but I use Emacs with Evil mode for lisps. Evil mode is bar none the best vim emulator I've used and is the only one I can stand to use on an extended basis.
I love reading that, I have been using Vim for 4 years or so, but for a month or two I actually managed to switch to emacs with evil-mode. I did however notice that my knowledge of the different modes was too limited, and I was basically just using vim in emacs, so dropped it again. Since today I actually switched back to Emacs, found my self-written cheat-sheet and so far it's going great (no evil-mode so far).
[deleted]
Good summary but I disagree that jumping off a cliff with 3 other guys is always a bad idea. Sometimes you can grow wings and sour over the beautiful mountains others are struggling to climb
It's been almost 2 months since I started learning Clojure+ClojureScript.
The language itself is beautiful and very powerful, you feel like you're gaining new superpowers as you learn it. You also start to understand your imperative languages much better as you learn Clojure and grasp concepts like functional programming, data (im)mutability, runtime polymorphism and get some new insights into concurrency. Lisp's Code is data and 'data is all you need' is an extremely powerful concept too.
Interactive development is a really cool thing.
But the path was not all flowers, I must confess.
I've struggled for weeks with the editors and Repl integration (I chose Cursive eventually), setting up the projects and the workflow for clojure, browser and node.js vm.
We have a tendency to try and adapt the stuff we learn to the things we already know and sometimes I did just that, trying to fit a square into the circle that I know and it never quite fits. It's best if you 'forget' all your previous programming knowledge and just go with the Clojure/ClojureScript way of doing things. The language (and especially the tools/libs) are evolving rapidly so check the date on the articles you read: if earlier than 2014, chances are things are done differently now. Also, the best way to get help fast is through the IRC channels on freenet. I would have saved days if not weeks if I've figured this out earlier.
That being said, ClojureScript is not like CoffeeScript. While it compiles to javascript, there's little benefit in using it as a 'javascript dialect'. It's power is in it's ability to be Clojure in the browser and the most benefit is when you have the tandem of clojure server and clojurescript client (which is actually one single application - go figure).
You can also feel that clojure is on the rise right now - there's stuff appearing every day - articles, books, libraries and cool demos, I think programmers are just starting to grasp the true power of the 21st century lisp. It kind of feels like the early days of node.js, so things will definitely grow in the future.
The language itself is beautiful and very powerful, you feel like you're gaining new superpowers as you learn it. You also start to understand your imperative languages much better as you learn Clojure and grasp concepts like functional programming, data (im)mutability, runtime polymorphism and get some new insights into concurrency. Lisp's Code is data and 'data is all you need' is an extremely powerful concept too.
Interactive development is a really cool thing.
But the path was not all flowers, I must confess.
I've struggled for weeks with the editors and Repl integration (I chose Cursive eventually), setting up the projects and the workflow for clojure, browser and node.js vm.
We have a tendency to try and adapt the stuff we learn to the things we already know and sometimes I did just that, trying to fit a square into the circle that I know and it never quite fits. It's best if you 'forget' all your previous programming knowledge and just go with the Clojure/ClojureScript way of doing things. The language (and especially the tools/libs) are evolving rapidly so check the date on the articles you read: if earlier than 2014, chances are things are done differently now. Also, the best way to get help fast is through the IRC channels on freenet. I would have saved days if not weeks if I've figured this out earlier.
That being said, ClojureScript is not like CoffeeScript. While it compiles to javascript, there's little benefit in using it as a 'javascript dialect'. It's power is in it's ability to be Clojure in the browser and the most benefit is when you have the tandem of clojure server and clojurescript client (which is actually one single application - go figure).
You can also feel that clojure is on the rise right now - there's stuff appearing every day - articles, books, libraries and cool demos, I think programmers are just starting to grasp the true power of the 21st century lisp. It kind of feels like the early days of node.js, so things will definitely grow in the future.
>I think programmers are just starting to grasp the true power of the 21st century lisp.
Now, if programmers would only realize that Scheme and Common Lisp are even better and start using them more. It's nice to see a Lisp get some mainstream acceptance, but it's unfortunate that it has to be Clojure.
Now, if programmers would only realize that Scheme and Common Lisp are even better and start using them more. It's nice to see a Lisp get some mainstream acceptance, but it's unfortunate that it has to be Clojure.
I only have the utmost respect for Scheme & Common Lisp. However the thread is about ClojureScript and neither Scheme nor Common Lisp have comparable mature compile-to-JavaScript technology that I'm aware of. Back in the day I was very excited about Scheme2JS, but it didn't support macros. ClojureScript launched with compile-time macro support which is one of many reasons why I got involved with its development.
>but it's unfortunate that it has to be Clojure
Could you elaborate on that a bit ? Why is Scheme/CL superior to clojure ?
I chose to explore Clojure out of practicality. Clojure has the jvm (and the ocean of libs for it) and javascript (with another ocean of libs) on it's fingertips and in theory it allows you to build any modern application.. While CL, Scheme doesn't seem to have as much library support (although I honestly don't know a lot about either of them).
Could you elaborate on that a bit ? Why is Scheme/CL superior to clojure ?
I chose to explore Clojure out of practicality. Clojure has the jvm (and the ocean of libs for it) and javascript (with another ocean of libs) on it's fingertips and in theory it allows you to build any modern application.. While CL, Scheme doesn't seem to have as much library support (although I honestly don't know a lot about either of them).
>Why is Scheme/CL superior to clojure ?
Clojure's license choice is unideal: the GPL-incompatible Eclipse Public License. On the JVM, it's startup performance is quite slow, and personally I don't like the Java environment at all. Furthermore, the syntax choices baffle me: Having to specifically know when a form uses () or [] is just odd. The 'let' form stands out as a good example of Clojure's bad language design choices. There's also no tail-call optimization, one has to explicitly use a 'recur' form to approximate it. I'll stop here.
Now that I've ranted about that, here's what I like about Clojure: The persistent data structures and the concept of transients. Both of these can be implemented in the Lisp of one's preference, though, and someone's already done the basic work for my Lisp of choice: Guile Scheme.
>CL, Scheme doesn't seem to have as much library support
Any decent CL or Scheme implementation gives you access to a C FFI, which provides another ocean of libs. But yes, there are fewer libraries generally, but people were okay with that for Clojure. Clojure hackers wrote a whole bunch of libraries because they were excited about the power the language gave them. If more people would recognize the immense power and value of CL and Scheme, libraries would cease to be an issue, people would write the missing bits.
I work on a GNU/Linux distribution written almost entirely in Scheme. I think that's a pretty practical application, and good evidence that Lisps that aren't Clojure are good choices, too.
Clojure's license choice is unideal: the GPL-incompatible Eclipse Public License. On the JVM, it's startup performance is quite slow, and personally I don't like the Java environment at all. Furthermore, the syntax choices baffle me: Having to specifically know when a form uses () or [] is just odd. The 'let' form stands out as a good example of Clojure's bad language design choices. There's also no tail-call optimization, one has to explicitly use a 'recur' form to approximate it. I'll stop here.
Now that I've ranted about that, here's what I like about Clojure: The persistent data structures and the concept of transients. Both of these can be implemented in the Lisp of one's preference, though, and someone's already done the basic work for my Lisp of choice: Guile Scheme.
>CL, Scheme doesn't seem to have as much library support
Any decent CL or Scheme implementation gives you access to a C FFI, which provides another ocean of libs. But yes, there are fewer libraries generally, but people were okay with that for Clojure. Clojure hackers wrote a whole bunch of libraries because they were excited about the power the language gave them. If more people would recognize the immense power and value of CL and Scheme, libraries would cease to be an issue, people would write the missing bits.
I work on a GNU/Linux distribution written almost entirely in Scheme. I think that's a pretty practical application, and good evidence that Lisps that aren't Clojure are good choices, too.
I don't like the Java environment at all. Furthermore, the syntax choices baffle me: Having to specifically know when a form uses () or [] is just odd. The 'let' form stands out as a good example of Clojure's bad language design choices. There's also no tail-call optimization, one has to explicitly use a 'recur' form to approximate it. I'll stop here.
Everything you've said in the above quoted text is a selling point for me, not a negative thing. I like having the java environment because it brings a lot to the table. I really like (let [...] ...) because it makes it visually obvious to me where the bindings are. I also like explicitly using recur because it makes intent obvious and lets the compiler complain if its not in a tail position.
Everything you've said in the above quoted text is a selling point for me, not a negative thing. I like having the java environment because it brings a lot to the table. I really like (let [...] ...) because it makes it visually obvious to me where the bindings are. I also like explicitly using recur because it makes intent obvious and lets the compiler complain if its not in a tail position.
+1 for recur. It was first puzzling to me, and looked like a limitation, until I saw the light. It actually forces you to make sure you not going to cause actual recursion (so no stack overflow).
I also like the [] vector syntax, since you don't need to quote it (no calls expected there).
I also like the [] vector syntax, since you don't need to quote it (no calls expected there).
Clojure still has a long way to go to become "mainstream", but as you can see from this list, it's getting there.
http://clojure.org/companies
Walmart, Twitter and Amazon would be three notable examples of companies that have achieved large scale that are using it.
http://clojure.org/companies
Walmart, Twitter and Amazon would be three notable examples of companies that have achieved large scale that are using it.
Vim has great plugins for Clojure.
https://github.com/tpope/vim-fireplace
https://github.com/guns/vim-sexp
https://github.com/guns/vim-clojure-static
Also, this might be useful:
https://github.com/ctford/vim-fireplace-easy
https://github.com/tpope/vim-fireplace
https://github.com/guns/vim-sexp
https://github.com/guns/vim-clojure-static
Also, this might be useful:
https://github.com/ctford/vim-fireplace-easy
> But it seems it's not main-stream [1] enough to have tons of tutorials, books, tools, employees that would appreciate it.. yet.
My "Clojure Books" folder contains 10 books. Several more came out recently, but I stopped buying the beginner ones.
How many more do you need?
> I just don't want to spend my time learning something that could become obsolete, (in the eyes of coworkers/employers!)
As Master Yoda would say – "I sense much fear in you" :-)
My "Clojure Books" folder contains 10 books. Several more came out recently, but I stopped buying the beginner ones.
How many more do you need?
> I just don't want to spend my time learning something that could become obsolete, (in the eyes of coworkers/employers!)
As Master Yoda would say – "I sense much fear in you" :-)
Yes, you can use any JS library you normally would from ClojureScript. Pretty much the only JS "framework" that feels natural to use from ClojureScript is React, but things like jQuery, Highcharts, etc... all work just like they would in CoffeeScript.
In Clojurescript, the google Closure Library is favored over using something like jQuery since Clojurescript leverages the Closure Compiler, not as famous as jQuery but is a solid lib used by gmail, google docs, maps and much more.
Yeah I agree, for basic DOM manipulation it's easier to just call out to the google closure functions than worrying about including jQuery... HOWEVA, there are a lot of useful libraries (highcharts, jqueryUI etc...) that are built on top of jQuery so I find myself including it frequently in my cljs builds.
ready to turn over a new leaf and try reactive clojurescript? :)
there is a community curating effort around http://cljsjs.github.io/ for popular external libraries
How big are the generated js files for clojurescript applications compared to say coffeescript or Dart ? The last time I tried it-- when it was still new , the files were too big to be useful for 3G Mobile devices. Has that changed?
If you've been serving jQuery (~30K gzipped) to mobile web applications, ClojureScript has always been a fine alternative. ClojureScript applications start at around 20K gzipped and go up from there.
ClojureScript is passed through the Google Closure compiler and you can give various directives to the compiler (e.g. simple, advanced etc.) in order to set how aggressively the compiler optimizes the code.
Medium sized apps' should have an advanced optimized ClojureScript component of 200 - 300 KB after being gzipped. This will, of course, vary depending on your specific app.
Medium sized apps' should have an advanced optimized ClojureScript component of 200 - 300 KB after being gzipped. This will, of course, vary depending on your specific app.
This could really do with having someone copy-edit. The constant spelling and grammatical errors make it quite hard to read, unfortunately.
The authors said on the mailing list that they're not native english speakers and would love if somebody would help them with that.
But I'm getting more hopeful every time I see a new post surface with a new language or tool that is lisp-y.
Btw, this is not the first time I'm wondering this, but could I start using something like ClojureScript instead of Javascript and be able to use the libraries I currently use, like I would with coffeescript?
[1]: No something does not have to be main-stream or widely used/acknowledged as good to be good, but you can't deny it helps. I just don't want to spend my time learning something that could become obsolete, (in the eyes of coworkers/employers!)