mfikes

Indeed, try Replete for example, in the iOS and macOS App Stores (https://replete-repl.org).

I've also had a separate commercial in the iOS App Store based on ClojureScript since 2014. (This pre-dated React Native, even, and is based on Goby.)

It is so cool to see how far things have come since ClojureScript first worked with React Native in 2015. Krell is the best REPL for this IMHO, and it does this largely by getting out of your way. :)

Vouch Key is not tied to Apple products. It works with Android, for example.

I haven't. But I suspect that's next. If you compare things like Lumo / Planck (ClojureScript) to Babashka (GraalVM-based Clojure), you can clearly see the perf benefits of going native.

This stuff is arguably just an initial foray into the embedded world. You could imagine a Clojure dialect or compiler that emits WASM, or C, or even native code.

The primary challenge is RAM. The (simplistic) approach I took with establishing a ClojureScript REPL is to have the standard library available, and that requires a lot more RAM than most Espruino boards have. Even with the ESP32, I had to make a few tweaks to Espruino in order to make more of the ESP32's RAM available.

Perhaps a more sophisticated approach could be devised involving "faulting in" ClojureScript standard library functions on demand as they are used, and by doing this use less RAM and reduce startup latency. If that were done, things would run on a broader range of chips (less RAM needed).

Indeed, the board is not required. I've added a note to the Tindie description to that effect.

I created the board for an upcoming Clojure/north 2020 talk https://clojurenorth.com/mike-fikes.html

But, your assessment is correct... the software is definitely the interesting bit (the challenges associated with getting ClojureScript to run on that hardware, with a REPL, etc.)

Additionally, the Graal team has done some great work to ensure that the JavaScript produced by ClojureScript runs quickly under Graal.js. For more details, see https://github.com/graalvm/graaljs/issues/29

I personally mainly use Replete for quick checks of things when AFK (seeing what a particular form might evaluate to, checking a docstring, etc.) In, short I've never really used Replete for any heavy development.

When Lisping existed (it is evidently no longer available), I was never really motivated to use it to develop code with Replete.

Yes. There used to be an iOS app named Lisping

https://news.ycombinator.com/item?id=11658418

and you could edit text in Lisping and send it to Replete for evaluation. (The generic hooks still exist in Replete, so in theory other apps could do the same.)

Ahh, cool. TIL.

One advantage is that Replete requires no network connectivity to evaluate forms. The compilation and evaluation is done directly on your device.

You’d need to first do

  (require ‘replete.http)

in order to load the code for that namespace.

You should be able to copy output by pressing on a history row.

Yeah, ClojureScript is really a dialect of Clojure.

They have hugely different applications, but at a certain level, they look like the same language.

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.

It is all open source, for those interested in how it works: https://github.com/replete-repl/

Apple allows you to embed JavaScriptCore into native apps, writing some of your logic in JavaScript. See this WWDC 2013 presentation: https://developer.apple.com/videos/play/wwdc2013/615/

If you would like your JavaScript to be derived from ClojureScript, and you would like a live REPL experience, then Ambly can be used for that.

An example library that uses this technique to drive a native iOS app is https://github.com/mfikes/goby

No. ClojureScript works with React Native, and in that case you can use the Figwheel REPL. See http://cljsrn.org

Ambly can be useful in other situations where you are not building a React Native app, but still want ClojureScript driving things. For an example with Ejecta, see http://blog.fikesfarm.com/posts/2017-04-29-clojurescript-eje...

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.

Bravo António! Keep up the great work. :)

[1] http://swannodette.github.io/2015/07/29/clojurescript-17

[2] https://twitter.com/mfikes/status/702243790225068032

[3] https://twitter.com/swannodette/status/752957621204692992

Here is the source: https://gist.github.com/mfikes/c531a4801a84e2c06af11588ce290...

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!

This is a great intro to the subject. In particular, if you've ever run into something you think could be improved in the compiler, Maria shows that you need not be intimidated by the prospect of diving into its code.

This reminds me of one of the points pg makes in What Made Lisp Different [1], under #9:

  "compiling at runtime is the basis of Lisp's use as an extension language in programs like Emacs"

This Excel capability is an extremely cool demonstration of where ClojureScript's self-hosting capability can take us. Seems like there's no stopping it. Kudos to Christian Felde!

[1] http://www.paulgraham.com/diff.html

I'm wondering what Parinfer would feel like if used when editing the expression to submit in a REPL. (In other words, it could be nice outside of source editors.)

Here is nvbm's article on ClojureScript on Android: https://nvbn.github.io/2015/06/04/livecoding-android/

And... with React Native for Android, perhaps driven by Om or Reagent. :)

I believe nvbm's demo running Bocko on Android using ClojureScript is actually using JavaScriptCore.

Rhino is indeed much slower; that's why Tahmid Sadik is motivated to covert Replicator to use JavaScriptCore over Rhino.

If you're referring to the 5× — 7× speed difference for Bocko I included at bottom of the article, I'd be interested in knowing as well. :) Perhaps nvbm (the author) could shed some light. I can only hazard to guess that JavaScriptCore is simply more heavily optimized to reduce startup latency, with this really paying off in the mobile environment.

This makes it extremely easy to try out React Native with ClojureScript. Natal automates pretty much everything—you just type `natal MyProjectName` and you are up and running.