I'm not sure if this is the case; due to the immense body of work on JIT JavaScript, ClojureScript would usually perform better than Clojure for everything but math, hence would be good idea for server side usage as well. YMMV, of course.
The jvm has also had an immense amount of work done on its jit. One oft cited problem is its boot time, but other than that, its clojurescript really faster?
Internal tests, heard the same from others. I didn't do much digging, but I think it's the JVM being very under optimized for code not written in Java.
When node.js came out I was extremely excited. I remember watching video where Ryan Dahl received standing ovations and I almost jumped myself out of my chair to applaud.
I neither liked Javascript nor hated it but the idea of having same semantics on the back-end and front-end was really enticing. Sadly, after years working in node I realized that the promise of shared code was a lie and it is simply just doesn't work as I wish it would.
But then I tried Clojure and Clojurescript and to my surprise the idea of shared code actually somehow works here, despite the fact that you are essentially living in two different worlds - JVM and Javascript VM.
Do you think it is feasible to run the entire stack on closure script?
JVM just irks me the wrong way. Probably less than electron / nodejs does but if I'm stuck with one set of primitives and externs (npm) I'd rather use the same one both places even if the JS one is suboptimal in all cases (I've written enough JS that I'll be able to deal.)
Re The shared code thing between server and client for JS I never understood the proposition. You're solving different problems sharing code _never_ made sense.
I think what people were really talking about when they said they wanted it was sharing data. Sharing their object relations, or sharing their mapping code. Or better yet, not having to share mapping because with the same language in both places you no longer need to map data.
And nodejs/browser js does in fact get you all of that. Provided you have clean models and clear conventions / functions to manage that shared state.
Where the story breaks down is the lack of native immutability, and the problems that leads to elsewhere, namely, if you have some data in the client that maps perfectly to serverside data you likely still end up with that serverside version of it including g server side only infoyou don't want exposed. Likely this is the what you should do boundary wise but it is what often ends up happening anyway.
Closure forcing immutability also forces not only the data structures but also the library code that makes reasoning about, and slicing and dicing those structures far easier / natural or I guess you would say isocratic.
For those curious, Replete relies on the ability of ClojureScript to self-host, and thus essentially carry its compiler with it.
Replete iOS was one of the first applications of self-hosted ClojureScript (around 2015, the first time we could evaluate ClojureScript forms directly on iOS, no JVM in sight).
Just recently Replete was ported to Android, via some amazing work of Roman Liutikov.
I find the constant breaking changes troublesome as well. I've never seen that with another framework and am hoping that things converge towards stability.
I'm astounded by the pace of progress. It was only mid-2015 that ClojureScript first self-hosted [1], roughly year ago when it was stable [2], and mid-2016 when I had first heard that Google Closure runs in JavaScript [3], and now this.
CLJS Fiddle is based on bootstrap (self-hosted) ClojureScript, so it includes the entire compiler in the JavaScript downloaded. But, there are things that can be done to improve things, even in this situation (work to make artifacts smaller, bring up UI while things load, etc.)
This is cool, IMO. My main ClojureScript experience to date has been non-web (mobile, bootstrap, etc.), but this fiddle even makes it ridiculously easy for someone like me to quickly try an idea out and just experiment.
No need to run through the ClojureScript "Quick Start"—this is just "Start". :) Bravo!
Derek does a great job of providing a critical overview of ClojureScript, where it's been, and how it can be improved. All while being highly entertaining to watch!
They have hugely different applications, but at a certain level, they look like the same language.