I'm only vaguely familiar with clojure, but why would you want to use clojurescript over clojure?

For what GP mentioned ("systems automation") depending on the JVM (as one would with Clojure) is kind of a non-starter, due to the long startup time. By contrast, Clojurescript (essentially the same language, but compiled to JS instead of JVM bytecode) can run in something like Node.js, where startup times are considerably faster.

Edit: this new development (CLJS compiled with CLJS) is remarkable because previously, compiling CLJS required a running JVM. One could still compile automation scripts and run those, but that wouldn't really be true to the "scripting" style anymore.

You can dynamically compile and run ClojureScript scripts so long as you have properly hooked things up to a JavaScript engine. I've started on an effort that makes this easy OS X, wrapping JavaScriptCore and I could see similar efforts for Node.js. Here's what I've been working on: http://planck.fikesfarm.com It can run scripts you have on disk, etc, and it has basic file I/O capabilities at the moment so you can write simple text processing scripts, for example.

planck is a really exciting project. What IO capabilities do you think are missing at this point?

Just for DX / ergonomics, I'd like to mimic more of the file I/O stuff that you have in Clojure, especially the ability to cope with streams. And then perhaps having network I/O would be interesting as well.

Then there is the `clojure.java.shell` namespace that could prove very useful for scripting.

It actually isn't the JVM startup time that is the problem. The JVM starts up pretty quickly these days.

Clojure itself is the bottleneck. Which means it is at least fixable... but seems to require a huge effort to fix.

Since none of your other responders said this, I will also point out the most common/obvious reason: you're building a website in Clojure, and want to continue using it for your front-end work, too.

"Because Clojure rocks, and JavaScript reaches"

-- Rich Hickey

(or so I've heard)

Sure. There are a lot of scenarios where the 300k overhead hit isn't going to matter all that much.

Not that 300K should be considered a huge amount by today's standards anyway.

Well, that's 300k of gzipped code, so while the bandwidth isn't huge (300k is barely a large image these days), that's a ton of code to be parsed, and might be too much of a CPU hit for anything mobile.

It is actually pretty good for mobile and startup time isn't an issue. We have variants that run on iOS https://itunes.apple.com/us/app/replete/id1013465639?mt=8 and Android is in the works http://tahmid.me/posts/2015-07-15-bootstrapped-cljs-repl-for...

Oh, my comment wasn't at all clear, but I was talking about inclusion on web pages, where you'd be flicking forward and back between them. In which case even 50ms on top of the rest of a page load would be hurting you.

I'm sure it's fine for a SPA, and for a mobile app it's a total non issue. Actually I'm planning to use it for one with React Native myself.

Luckily, people will probably not be including the full compiler lightly; I just wanted to point out that it's not as cheap as a jpg of the same size would be, an impression I thought the parent comment was giving.

> Oh, my comment wasn't at all clear, but I was talking about inclusion on web pages, where you'd be flicking forward and back between them

On the other hand - in case of single page webapps it would only be loaded once and could be made to load only once thanks to browser caching.

It would load only once SPA or not, that's the point of browser caching.

He's referring to parsing the JavaScript on page load.

Ah, missed that bit ;-)

You'd probably not want to use this on websites, unless you want to be able to compile code directly in the browser, such as when you're making an interactive tutorial or similar. Otherwise, you're better off with stripping out all of those parts.

Also, check out http://clojurescript.net which is running bootstrapped ClojureScript. It starts up instantly on an iPhone.

There are a lot of commonly used mobile libraries that are larger than this. Some of them (e.g., JQuery Mobile, which weighs in at several megs) make this look tiny by comparison.

The equivalent jquery mobile size - minified then gzipped - is 53kb.