Bootstrapped ClojureScript FAQ

Does bootstrapped ClojureScript mean that I'll be able to develop ClojureScript without the JVM?

It is not a goal of bootstrapped ClojureScript to eliminate the JVM.

• The JVM is used by Google Closure Compiler. Thus a JVM needs to be present for anything other than compiler :optimizations set to :none. While :none is common for REPL development, :advanced is often used for production builds. While it is possible to run Closure Complier as a separate step, ClojureScript now has non-trivial in-process integration which provides enhanced capability for essential features like source mapping and code splitting.
• The JVM implementation is efficient. As things stand now it usually leads to faster reading, analysis, and compilation than most JavaScript engines. With bleeding edge builds, compared to the JVM when compiling all of cljs.core, JavaScriptCore is 1.5X slower, V8 is 2.75X slower, and SpiderMonkey is 3.3X slower.
• Much of the existing popular and mature ClojureScript tooling (Leiningen, Boot, Figwheel) have fairly deep assumptions about the conventions of the JVM classpath as well as JVM-centric dependency resolution (Maven).

While there may be some advantages to a completely JVM-free implementation, developing and maintaining such a thing is not free, and is thus not a goal of the project.

Having said that, there is nothing preventing the creation of development tools (REPLs, IDEs, etc.) that make use of bootstrapped ClojureScript without a JVM present. However, while alternative community developments are encouraged, it is clear that it will take considerable effort and time to achieve parity with the existing JVM-aware tooling already actively maintained by the community.

Why was bootstrapped ClojureScript created then?

Primarily to broaden the scope of reachable targets. The goal is not to eliminatee the JVM at development time but rather reach targets who cannot realistically provide the JVM runtime.

Without bootstrapped ClojureScript, if you want to build an application that can evaluate ClojureScript forms at runtime, you need to delegate that task to some backend compiler service (this is how Himera works). By enabling the compiler to be used from within the target JavaScript environment, novel use cases can be implemented. This enables innovation in new creative ways:

• Shipping dev tools that don't require a JVM dependency.
• Low-latency scripting, making use of JavaScript engines' inherent fast startup in interpreted mode.
• Live updates to deployed codebases. (Ship code that can be compiled in target environment and dynamically incorporated in app. Mobile app updates, etc.)
• Web pages that provide dynamic online tutorials or showcase ClojureScript libraries.
• REPLs on mobile devices, without requiring network access to a compiler backend.
• Diagnostic REPLs embedded in apps, making it easier to examine state of running app.

The community is just beginning to scratch the surface on what is possible with this new capability!