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.
Professionally I have most often developed on Node but on the side have been really interested in FP. Applying FP ideas to JS is certainly possible, but this new accessibility of CS to my current world is exciting!
Assuming a commercial web application, appropriately sized hardware, and correctly optimized code, when is "footprint" a significant disadvantage? How is "footprint" defined? When are startup times a significant disadvantage?
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.
Note that with Lambda a cold start doesn't have to happen every time - if the function is executed frequently enough, the application will be kept around on the executing node.
Also, if your application has fairly stable load, then startup times are irrelevant 99% of the time, since you can just run persistent servers.
I was going to base it on Express.js originally. Express and espresso were both taken on Clojars, so I that's how I ended up with macchiato. I later realized that I didn't need Express.js after all, but decided to keep the name.
Can I write Clojure that gets compiled to JavaScript with ClojureScript and run that on JVM's JavaScript engine Nashorn?
Obviously turning code into JavaScript at least once is a mandatory requirement for fulfilling the "web" part of "web scale" and running the JavaScript on JVM gives me the "scale" part.
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.
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.
https://github.com/audreyt/node-webworker-threads