Macchiato: ClojureScript on the Server

21 contributors and the author is a famous programmer:

https://en.wikipedia.org/wiki/Audrey_Tang

It'd be doable but getting a nice Clojure-y API over it would take a little more work.

To start, you could try making a 1-to-1 mapping by closing over the web worker methods with cljs functions. To keep track of the web workers, you could put them in a cljs map inside an atom. This is what servant does to handle web workers.[0]

The other interfaces could be handled in a similar way by closing over methods with functions too.

It might be better after brute forcing a basic 1-to-1 style to create one or more layers of abstraction to make the interop more usable and Clojure-y. There could be cljs deftypes for the threads or web workers which hook into core cljs protocols[1] so that cljs.core functions would work over them. Macros could add syntactic sugar to lower level functions to make your API easier to use (looks like servant did that).

There are lots of options for how to build a good API depending on how powerful an abstraction you want to make for yourself. Getting basic support for the library could work by just closing over functions and adding some glue though.

[0]https://github.com/MarcoPolo/servant/blob/master/src/cljs/se...

[1]https://github.com/clojure/clojurescript/blob/master/src/mai...

If you use Rasberry Pi, real-time web apps.

In most use cases the jvm will be superior.

here, footprint is 'memory footprint,' the amount of main memory used by the application.

this is useful b/c VPSes are priced mostly based on memory

-----

i like that this says it's mostly trying to be "ring for node" ..

Here's a couple significant disadvantages to the jvm.

A simple jvm clojure app running jetting deployed as an uberjar takes about 12 seconds to start on a 1GB digital ocean vm.

Using jvm clojure as with aws lambda, it takes ~20 seconds for a cold start. Normal java is typically a couple of seconds, and it's likely that a cljs/node instance will be sub-second cold start.

It's probably a play, similar to the name of CoffeeScript

I see the /snark, but I'll answer seriously.

Most JS code assumes it's targeting either a browser or node.js. Nashorn is very barebones, and can't pass for either. trying to run core.async on Nashorn didn't work for me because it expects either Window.setTimeout (which browsers use) or whatever-node-js uses for timers. I expect a large percentage of the libraries you'd want to use will be similarly affected.

Oracle started a project called avatar-js that aims to clone the Node runtime in Nashorn. I've only POC'd with it a while back, not run in prod.

Yes. Recent cljs using the nashorn repl anecdotally performs as well as unprofiled and unoptimized clojure for a bunch of common stuff I've tested. Theoretically you could reexpose the missing parts of the JVM clojure api to cljs on nashorn given that most of the missing parts of clojure are written in java. That would let you have things like the STM if you wanted them.