

Fast JavaScriptCore Desktop ClojureScript REPL - hellofunk
http://blog.fikesfarm.com/posts/2015-07-16-fast-javascriptcore-desktop-clojurescript-repl.html

======
undershirt
some background: the ClojureScript compiler has recently been bootstrapped,
effectively giving us two different versions of the compiler, "ClojureScript
JS" which only relies on a JS runtime, and the original "ClojureScript JVM"
which will continue to be the default choice, partly because the benefits
afforded by the Google Closure compiler (written in Java) are huge and
irreplaceable.

The "ClojureScript JS" compiler cannot replace the original compiler fully,
but is already finding some great use-cases, such as this new insanely fast
Planck REPL, targeting new platforms like iOS (see Replete, Ambly, React
Native), an in-browser try-it-out REPL for our upcoming website, the ability
to try out new libraries from a webpage, and possibly adding ClojureScript
support to CodePen.

Lot of great stuff coming.

~~~
pbiggar
Surely ClojureScript JS could just shell out to the Google Closure compiler,
when available?

~~~
swannodette
Yes it very well could. It really is the same compiler - and the compiler
generates Closure Compiler compatible JavaScript.

------
mfikes
Author here. Willing to answer questions.

~~~
hellofunk
Cool. Can you explain exactly what the phrases "ClojureScript apps that
bootstrap themselves" or "bootstrapped ClojureScript runtime" mean?

~~~
mfikes
Bootstrapped ClojureScript refers to the idea that ClojureScript can compile
itself. Evidently Lisp was the first and ClojureScript was probably the most
recent to accomplish this: [https://en.wikipedia.org/wiki/Self-
hosting](https://en.wikipedia.org/wiki/Self-hosting)

But then there is also the concept that a ClojureScript app which is going to
make use of a REPL needs to do some additional work to bootstrap the
ClojureScript runtime. Normally when you ship a ClojureScript app you would
employ Google Closure to concatenate everything into a single file which is
loaded and evaluated. But if you want to work with individual files (one per
Clojure namespace, which is important when you are working with a REPL), you
need to avoid that and you need to set up things to use Google Closure's
dependency management system (CLOSURE_IMPORT_SCRIPT, etc.). I have a blog post
which attempts to explain the different meaning of "bootstrap" in this
context: [http://blog.fikesfarm.com/posts/2015-03-05-ambly-app-
bootstr...](http://blog.fikesfarm.com/posts/2015-03-05-ambly-app-
bootstrapping.html)

~~~
hellofunk
My God, it's turtles, I mean ClojureScript, all the way down!

This is really cool stuff. You've turned iOS into a classical lisp machine.

------
brudgers
My understanding is that one of the reasons for developing ClojureScript
[beside the unification of browser and server data structures and code models
in a way that goes beyond the limitations of raw JavaScript] is to get the JVM
and its overhead out of the way for uses like shell scripts in exchange for
the scaling and robustness that the JVM can provide.

There's an impedance mismatch between shell scripts and an environmental
dependency on the JVM. Likewise there are some use cases for the JVM that
aren't conducive to JavaScript's idioms and code models.

------
weavie
"I'm amazed at how quick Clojure is to launch." Said no one ever..

~~~
jeremiep
That is the very last of my concerns with Clojure, as I usually just launch
the JVM once and then start developing while everything is running.

I'll take a slower launch any day if it means less code to write, more rubust
programs, more code reuse and everything else Clojure brings to the table :)

~~~
Touche
Slow launch means you tend to write monolithic applications. You can't write
cli tools with Clojure. You can't compose Clojure applications. You have to
write a big bulky JVM app. Which definitely has its place, but ClojureScript
is expanding Clojure's reach.

------
idibidiart
way to go Mike!!! :)

\--Marc

