mfikes

Yep, the ability to directly create network connections will ultimately land in Planck.

If you put the function source into edn and the function doesn't depend on anything but core constructs, it would be nearly trivial to eval using the new cljs.js.

If those functions need to call into other ClojureScript namespaces that you've already compiled into your code then the analysis cache would need to be populated so that eval can operate properly.

For reference, here is cljs.js/eval: https://github.com/clojure/clojurescript/blob/v1.7/src/main/...

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.

In fact, you no longer even need a full-fledged computer. :)

Here is some good exposition on that matter: https://github.com/clojure/clojurescript/wiki/Bootstrapped-C...

All difficult problems in the Clojure community are resolved by sleeping, preferably in a comfortable hammock.

Yep, and within a few months you will find yourself accidentally typing `(if` instead of `if (` in a C-based language.

None of this recent work facilitates compiling ClojureScript into CommonJS modules for use with Node.

But, the opposite is in flight: ClojureScript now has support for depending on libraries that are packaged using the CommonJS system.

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

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...

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.

It can be very fast to get things running. Here is an example using "desktop" JavaScriptCore on OS X: https://twitter.com/mfikes/status/626884586392453120

Clojure and ClojureScript are practically the same language. Both are "hosted", relying on Java and JavaScript for low-level things and providing clean interop for those things.

So, I see no problem with learning either. Especially when you first jump in you are concerned more with the language "proper".

Yes and no. You can write macros for which the source is ClojureScript, but they need to be kept separate. Here is a stab I took at explaining that subject: http://blog.fikesfarm.com/posts/2015-06-19-portable-macro-mu...

There are no plans for the same backend AFAIK.

Some comments I've seen are that it is simply about establishing parity with Clojure 1.7 while keeping the current release strategy (it's not about semantic versioning).

If you are curious, here is the Wiki page that tracks the path to release: https://github.com/clojure/clojurescript/wiki/Road-Map

Wow, since 2013? So you've seen the state of ClojureScript change drastically over the past couple years. Have you stuck with the original tooling as it was back then, or did you try to track ClojureScript as it matured?

Thanks :) This stuff is coming together fast now. Android should be available soon as well. :)

Author here. Willing to answer questions.

Replete is a free and open source (https://github.com/mfikes/replete) ClojureScript REPL, and it was just now made available the App Store.

It is based on a relatively recent ability for ClojureScript to “bootstrap” or “self-host,” and thus is the first time it is possible to evaluate ClojureScript forms directly on a device without resorting to a back-end compiler service. (No network access is needed.)

This is just the first release with a minimal feature set. We would greatly appreciate any feedback for future improvements!

While this blog post is one answer to "what", there is also a good FAQ covering questions related to "why": https://github.com/clojure/clojurescript/wiki/Bootstrapped-C...

Author here, willing to take questions on this. The post is intentionally made very simple, but if there are questions about the subtle details, glad to help out!

Just me thinking off the top of my head: I doubt ClojureScript's ability to compile itself helps with that, but I've never pondered that before. Hmm.

I think Fogus's post is still relevant: http://blog.fogus.me/2012/04/25/the-clojurescript-compilatio...

I actually suspect that you can make a solid app with ClojureScript _today_, QTTT being the thing that makes me think this is so. https://github.com/mfikes/qttt#react-native-port Also, Facebook has shipped apps based on React Native.

The aspect that is rough is the ClojureScript tooling. This post attempts to cover where we are with tooling: http://blog.fikesfarm.com/posts/2015-07-06-clojurescript-wit...

From a tutorial / example perspective, there's this: https://github.com/omcljs/ambly/wiki/ClojureScript-React-Nat...

The general state of things is covered here: http://blog.fikesfarm.com/posts/2015-07-06-clojurescript-wit...

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

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...

Author here. Willing to answer questions.

A bootstrapped ClojureScript REPL now exists for Android. Replicator: http://tahmid.me/posts/2015-07-15-bootstrapped-cljs-repl-for...

Replete is in beta right now, so it simply requires signing up and making use of TestFlight. https://github.com/mfikes/replete/wiki/Beta

Also, it is a slightly older version, but if you want, you can try it directly online here: https://appetize.io/app/8hf37bv29k2zrj0v2j765xt3jr

It is _extremely_ viable: The core REPL functionality is based on a few ClojureScript lines from Joel Martin's initial work for something similar for Node.

In short, to make an Android version would involve just running a JavaScript engine and hooking up a little bit of UI to send strings to it, and get strings back out of it.

Replete is open source... feel free to steal heavily from it.

Look at how simple and rough the first working version of Replete was (see demo of it at bottom of http://blog.fikesfarm.com/posts/2015-06-27-replete-a-standal...)

IMHO an Android version is just waiting to be created by someone. :)

One way to look at it: Replete has a bit of CLJS source which requires the reader, analyzer and compiler namespaces. When Replete's source is built (using the JVM), these additional namespaces get compiled down to JavaScript and are usable by Replete itself, in the R and E parts of the REPL. It is all JavaScript, of course, when on the device.

Google Closure is used for its dependency management (ClojureScript namespaces and how they require other namespaces). But Google Closure is not used for its optimizations (everything is built with :none mode).