A problem with JVM-based components being used in a tool-like manner is the
relatively huge cost associated with just starting the JVM.
E.g. if I start a JRuby-console ("irb"), it takes 2-3 seconds, whereas a
MRI console basically opens instantly. Even with the work being put into
reducing
nashorn's own warm-up time, the JVM's share will remain. An approach here
seems to be to have one JVM running at all times and then relegating the
invocations of your tools to it. Nailgun is an implementation of this
recommended by the JRuby team. But such an approach certainly brings its own
share of problems. In the end, I think that with the JIT, the JVM's very
promise has always been that getting prime performance on it requires your
application to be a bit on the longer-lasting side. Otherwise, AOT
optimized code will just be plain faster. And with most commandline tools,
I feel,
invocation speed means a lot.On 24 December 2014 at 19:02, KARR, DAVID <[email protected]> wrote: > Nashorn and Avatar are interesting to me, but not personally as much for > the ability to write standalone or server-based JavaScript applications. > > I see Node.js being primarily used in two different ways. It is used to > write those standalone and server-based JavaScript applications, but it is > also used entirely in the building and testing process of web applications, > primarily with the Karma, Bower, and Grunt Node modules. I imagine there > are other Node modules like that that are primarily used as a tool, not as > a component in a custom Node.js application. > > You might consider this a "niche" application, but I'm primarily > interested to see whether Nashorn will be able to make it easier to use > Gradle to build web applications and run JavaScript unit tests, without > involving Node.js. > -- Benjamin Sieffert metrigo GmbH Sternstr. 106 20357 Hamburg Geschäftsführer: Christian Müller, Tobias Schlottke, Philipp Westermeyer Die Gesellschaft ist eingetragen beim Registergericht Hamburg Nr. HRB 120447.
