Fast JavaScriptCore Desktop ClojureScript REPL(blog.fikesfarm.com)
blog.fikesfarm.com
Fast JavaScriptCore Desktop ClojureScript REPL
http://blog.fikesfarm.com/posts/2015-07-16-fast-javascriptcore-desktop-clojurescript-repl.html
22 comments
Oh, and I left out one of the biggest benefits. We will have a simple option to ship the compiler inside your application, to allow things like the ability to "eval". Just think of interactively inspecting and modifying a running application after it is shipped.
Surely ClojureScript JS could just shell out to the Google Closure compiler, when available?
Yes it very well could. It really is the same compiler - and the compiler generates Closure Compiler compatible JavaScript.
Author here. Willing to answer questions.
Cool. Can you explain exactly what the phrases "ClojureScript apps that bootstrap themselves" or "bootstrapped ClojureScript runtime" mean?
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...
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...
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.
This is really cool stuff. You've turned iOS into a classical lisp machine.
I've been using the Reagent library for all my web UI's and it's simply incredible. I desparately want to translate this same workflow to iOS.
I'm a huge fan of React Native, but it's just not the same writing it in Javascript vs. using ClojureScript/Reagent. With the Javascript React Native workflow you're still forced to include npm modules to do basic enumerations, and the technical debt added to your codebase because of JSX is really painful.
Since Reagent components turn into React functions it seems like you should be able to write React Native apps in ClojureScript/Reagent and solve all these problems. I just don't even know how to start setting that up. Can I just use the regular CLJS compiler to save a javascript file and run it on the iPhone? Is there a tutorial or really simple example of the clojurescript to react-native workflow somewhere that you know of? If you wanted to learn more about this stuff where would you recommend starting?
I'm a huge fan of React Native, but it's just not the same writing it in Javascript vs. using ClojureScript/Reagent. With the Javascript React Native workflow you're still forced to include npm modules to do basic enumerations, and the technical debt added to your codebase because of JSX is really painful.
Since Reagent components turn into React functions it seems like you should be able to write React Native apps in ClojureScript/Reagent and solve all these problems. I just don't even know how to start setting that up. Can I just use the regular CLJS compiler to save a javascript file and run it on the iPhone? Is there a tutorial or really simple example of the clojurescript to react-native workflow somewhere that you know of? If you wanted to learn more about this stuff where would you recommend starting?
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...
The general state of things is covered here: http://blog.fikesfarm.com/posts/2015-07-06-clojurescript-wit...
Hi Mike! Great work!
So when do you think we'll be able to make a solid app using React Native and cljs on iOS? What's the biggest impediment for being able to do that now?
So when do you think we'll be able to make a solid app using React Native and cljs on iOS? What's the biggest impediment for being able to do that now?
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...
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...
So how much work is it to add another compile target than JS, now that Clojurescript is bootstrapped?
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 think Fogus's post is still relevant: http://blog.fogus.me/2012/04/25/the-clojurescript-compilatio...
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.
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.
[deleted]
"I'm amazed at how quick Clojure is to launch." Said no one ever..
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 :)
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 :)
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.
I find myself restarting the repl once an hour or so, and running lein 2-3 times an hour (I run lein test before each push and lein install after most rebase/merge).
I suspect it sticks out like a saw thumb as its the only bit of Clojure that feels significantly bad.
OK, given a choice, I'd probably go for Elm style error messages, then go for faster startup time.
I suspect it sticks out like a saw thumb as its the only bit of Clojure that feels significantly bad.
OK, given a choice, I'd probably go for Elm style error messages, then go for faster startup time.
Even a Scala user ?
way to go Mike!!! :)
--Marc
--Marc
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.