I played around with Nashorn/jjs recently - if anyone's curious how roughly things work I did a little write-up here with a couple of examples showing some simple use-cases: http://blog.mclemon.io/discover-a-linux-utility-jjs

I did a presentation on using Nashorn (and jjs) about a year ago at SacJUG (our local Java user group). It's pretty interesting the level at which you can intermix Java and Javascript in Nashorn.

I tinkered with the idea of using a library called Spark on Netty to make web services in JS, but this library (and others mentioned here) actually did the job :-)

https://docs.google.com/presentation/d/19KTud9_3I3MgJiYlVdF9...

https://github.com/roboprog/nashorn_play

I also did a lightning talk demo on Nashorn vs Node performance a few months ago (local JS user group).

For the little string mashing benchmark I put together (originally to compare sequential / fork / thread performance in various languages), Nashorn's (Java 8) JIT eventually catches up and passes Node. Alas, it's one of those "O(n) for large n" problems where n has to be around a million before this happens.

... And Perl still mops the floor up with all of them. (Perl is good at string handling, even if not so much at many other things)

I actually used Spark via the "Nasven" wrapper for maven to create the simple thumbnail server I wrote about on my post (it's at the end of a lot of boring text): https://github.com/smcl/thumbooo

We are using J2V8, found Nashorn to be a bit lacking in performance.

How these tests are run will potentially create large differences. For instance, pure Nashorn will compile each script _every_ time before executing it. PurpleJS only compiles a script once and then caches it for re-use.

Yep - you're right in that it's not fast. On my post I nabbed a graph from someone who did some performance measurements and the difference is pretty stark.

- Performance: I guess looking at Nashorn performance tests would be relevant. Additionally, PurpleJS apparently compiles a javascript file on first run an then caches it for next execution, until the file is changed or the app is restarted. This would affect performance extremely over running the scripts from scratch each time. Compared to Node, you can for instance utilize a 32 core processor with a single runtime - compared to starting 32 node runtimes.

- Async: PurpleJS is a pure server-side framework. Thanks to the JVM it is capable of providing traditional multi-threaded approach to SSJS development which is both easier to understand and debug. The JVM helps you cope with the parallellism. I assume it should even be possible to add event driven capabilities to PurpleJS as well given that Java has a powerful event system.

Isomorphic: I see your point. However isomorphic scripts are naturally limited to anything that will successfully run on both server and client. For instance the DOM is just as little accessible to Node as it is to PurpleJS.

Apparently there is a new issue for 'console' in PurpleJS issues now - seems reasonable.

> The world is async

While that may be true, most algorithms, recipes, procedures, and instructions are synchronous. So human beings are used to synchronous programming.

So long as one executor is executing the recipe/procedure/etc it makes sense to simplify directions to make them appear synchronous. When I turn my computer on and wait for it to start, I don't literally freeze up and stop breathing. I go do other things and wait for a signal that startup is complete or I poll the status of the computer from time to time. The synchronous instruction "wait for the computer to start up" is interpreted as "do whatever you want or need to do until the computer has started up".

As soon as two parties are involved, instructions start making sense asynchronously. Try writing a recipe for baking a cake by two bakers, keeping both chefs occupied the entire time. You'll see that the instructions must be read asynchronously otherwise each baker would not be able to continue reading his/her instructions when a "thread" of operation for the other baker has been called out.

Async is not parallell. With Node, only one of your bakers would actually be working at a time since Javascript does not support multithreading! Only way to achieve this would be dispatching to other node processes and start handling this yourself. With the JVM however you could actually do things in parallell without any such RPC handling.