Compare embedded JavaScriptCore and Node.js (iojs)

comparison.md

Since an embedded JavaScriptCore can be made to launch quickly, I've been pondering whether it is justified in converting Planck to be a portable (OS X, Linux, Windows) C-based wrapper around JavaScriptCore (so that it is more broadly useful). Right now Planck is not portable owing to the use of Cocoa/Foundation and Objective-C.

I think this partially boils down to wether the launch latency is faster than an equivalent based on Node.js (which is already portable and has a much richer ecosystem). That latency has to be significantly different, and I also think you'd need to be convinced that it is going to remain that way (perhaps V8 will be further optimized, but perhaps the outright launch speed of Node.js isn't a priority).

Here is my first attempt at a comparison, based on Joel Martin's work:

$ time echo '(map inc [1 2 3])' | cljs
cljs.user=> (map inc [1 2 3])
(2 3 4)
cljs.user=> 
real	0m0.826s
user	0m0.748s
sys	0m0.093s

$ time echo '(map inc [1 2 3])' | ~/Projects/planck/build/Release/planck
(2 3 4)

real	0m0.385s
user	0m0.492s
sys	0m0.087s

@kanaka yes, Planck employs a background thread to bring up JavaScriptCore while it does everything else it can until eval is needed.

Perhaps I've been overly focused on startup latency. That has been effectively eliminated for interactive REPL startup (via the background thread) and caching compilation could perhaps do effectively nearly the same for scripts (regardless of Node.js or JavaScriptCore approach). planck-repl/planck#58

If that ends up being the case, then Node is very compelling and will only get better with TurboFan.

Planck has the benefit that it can be shipped as a single binary, this is huge for use as a scripting language runtime.

My 2 cents. Unlike Planck, Node.js isn't designed to be embeddable, it has all the problems of the JVM with respect to that. Further, beyond AWS Lambda, I don't find the Node.js target particularly compelling given the JVM exists for server side applications. I don't even really see an argument for shell-scripting w/ ClojureScript + Node.js, Clojure already has sub-second launch time on modern hardware.

If Planck supported simpler C integration that would be the legitimate killer application. So to me pursuing Windows & Linux should be about broadening embeddability, not trying to achieve Node.js generality (which IMO is an unrealistic goal anyhow).

In summary, Planck has a very compelling niche if doesn't try to replicate what Node.js is already good at.

@kovasb and @swannodette both mentioned C but I'm wondering if they are from different angles.

@kovasb 's comment appeared to be in line with planck-repl/planck#32

But @swannodette 's embedding might be the opposite: You have a native app you'd like to embed some ClojureScript functionality into? Perhaps using Planck as a library?

There's also atom/electron to consider when it comes to wrapping everything up for easy deployment. It's a very different beast, but could be useful to clearly position Planck, I think.

@mfikes iOS and OS X framework inter-op is a huge interest for many Clojure(script) developers.