
Nodyn – Node.js for the JVM - mindcrime
http://nodyn.io/
======
lanceball
As the creator of Nodyn, but being late on the draw, I'll just have to echo
what everyone else has said here. Java provides a large and rich ecosystem
that is either unavailable or prohibitively difficult to bundle into a native
runtime.

Nodyn is not yet complete, though I'd like to have a release in the next month
that is capable of running express.js apps. It is slower than Node.js, but of
course I'd like that to change; and with the JVM underneath, beating Node.js
on performance is possible.

Nodyn is built on top of Vert.x ([http://vertx.io](http://vertx.io)) an
asynchronous polyglot platform which excels on the Techempower benchmarks. The
javascript runtime is DynJS - a new JS runtime for the JVM which is
independent of Oracle. Though it's admittedly slower than Nashorn at the
moment, we hope for that to change.

~~~
nl
Given the asynchronous programming model that node encourages, how have you
found integrating with the traditional Java programming model that most of the
Java ecosystem uses?

~~~
RyanZAG
Vert.x has something called a 'worker verticle' that can run blocking IO in a
thread pool. You'd communicate with the worker by passing messages on the
event bus asynchronously. It makes integrating those kind of services fairly
straight forward, but obviously you'd switch to actual async APIs if
available.

------
eweise
Cool and if I combine it with [http://www.scala-js.org/](http://www.scala-
js.org/) I'll be able to run scala on the jvm.

~~~
vezzy-fnord
I'm not sure what you meant here, considering Scala already _does_ run on the
JVM.

~~~
peter_l_downs
thatsthejoke.gif

------
mmanfrin
Question from a novice-ish developer: What is the purpose of porting things to
the JVM? I had this idea before that porting things like Ruby or Rails to the
JVM was meant to offer ruby the advantages of having a java core (better
threading, garbage collection, faster). But, as I understand it, Node is
faster than JVM languages? What are the other advantages gleaned from porting?

e: Thank you guys for the answers, definitely makes a lot more sense now.

~~~
justinsb
The JVM gives you very good JIT, GC, threading, manageability (profiling,
debugging, memory inspection etc), scalability to huge machines, a huge
ecosystem of software and has basically solved every real-world deployment
problem. (Maybe apart from memory utilization!) It is definitely possible to
beat the JVM on any one of these facets, but to consistently beat it on all of
them is a _lot_ of work. (I'm not sure which benchmark you're referring to
where Node beats the JVM, but I suspect it's relatively 'focused'.)

To my mind, the idea of porting is that you face a choice: you can recreate
the JVM functionality in your own runtime, or you can port to the JVM. Porting
to the JVM is certainly non-trivial, but you then get thousands of man-years
of work in return. It's certainly worth doing a project to see whether the
porting effort pays off; especially if this done concurrently with working on
the language's 'native' runtime.

~~~
dmpk2k
_but to consistently beat it on all of them is a _lot_ of work._

As long as you aren't native, that is.

Although that's unrelated to the discussion at large.

~~~
pcwalton
Even then it's not that easy. A non-optimizing C compiler will have a hard
time beating the JVM's slew of optimizations.

~~~
erichocean
_A non-optimizing C compiler_

Is there a C programmer on the planet that does production builds with a non-
optimizing compiler? How is your comparison even remotely relevant to the GP?

~~~
bruceboughton
I believe the GP is referring to writing a non-optimising compiler in C. Not
compiling your C code using a non-optimising compiler.

------
rubiquity
I personally have been wanting a way to compile ClojureScript to JavaScript
without using the JVM. I'd rather just use the existing Node/v8 installation
that I have, especially since I don't use the JVM for anything else. I know
this project doesn't do that, I'm just throwing my wants and desires out into
the wild and hoping they come alive.

~~~
chc
Don't forget that ClojureScript macros are written in Clojure. Even if you
rewrote the compiler in ClojureScript, it seems like you'd need the JVM to run
your Clojure macros (unless you were OK with sacrificing some compatibility).

------
matt_heimer
How is this different than [https://avatar-js.java.net/](https://avatar-
js.java.net/) ?

~~~
lanceball
Same idea, different project.

~~~
moondowner
And different technologies (and possibly different ways of implementation
under the hood). Nodyn uses DynJS, this uses Nashorn.

------
chrisfarms
Take it this is Rhino under the hood somewhere, or has someone written a new
js engine?

~~~
mindcrime
[http://dynjs.org/](http://dynjs.org/) is, AFAIK, independent of Rhino.

~~~
qmxtheros
yup, it's independent, you can get more context on why I created dynjs here:
[http://blog.qmx.me/the-release/](http://blog.qmx.me/the-release/)

~~~
sitkack
Is there any plan to implement asm.js and JIT to JVM bytecode directly from
JS?

~~~
lucian1900
After a cursory look through the source, it would appear that it already JITs
to JVM bytecode.

asm.js isn't relevant here at all.

~~~
chrisseaton
Isn't the idea of asm.js that if a program is written according to the spec
you can generate simpler and so hopefully faster code? That applies whether
you're generating bytecode or machine code.

~~~
lucian1900
Sure, but you'd have to generate asm.js in the first place. It's compiler
target that also happens to map to a small subset of JavaScript, you're
unlikely to find writing asm.js by hand useful.

DynJS could _also_ support asm.js in addition to JavaScript, but that has
almost nothing to do with JIT-ing JavaScript applications.

~~~
sitkack
Right. I wasn't thinking of this as the _only_ JIT case, but one that could
generate faster code by not having to do complex type tracing or inference.
Seems like low hanging fruit to detect asm.js and read it directly into a
typed AST.

~~~
lucian1900
Probably, yes.

Although with invokedynamic, the JVM's object system ends up being remarkably
close to that of a dynamic language. This is best seen in JRuby.

------
JosephRedfern
Are there any benchmarks of DynJS vs v8? Presumably it's considerably slower,
but it'd be interesting to see by what order of magnitude...

~~~
lanceball
None published, but your presumption is correct for the time being.

------
bokchoi
Neat, I hadn't come across DynJS yet. It would be nice if the landing page
mentioned how the project is different from Nashorn and Rhino.

------
SeanDav
Not in any way trying to troll here, but other than as an intellectual
exercise, why on earth would one want to develop in Node on the JVM? Surely
Java/Scala/Clojure etc would solve any problem easier and faster than Node on
JVM?

What am I missing?

------
tylerdavis
Nan Pointer Exception

------
moondowner
What's the difference between using Vert.x with DynJS and using Nodyn? Nodyn
is ment to be a drop-in replacement for Node.js right?

------
frik
I am still waiting for Node.js on Mozilla Gecko javascript engine (instead of
V8).

Is someone working on it?

~~~
Kiro
What would the benefit be?

~~~
pritambaral
Apart from "competition"? Mozilla's JS engine has gotten on par with V8.

------
Touche
Any relation to the Node.jar project?

------
waterfowl
Down already?

------
fisherprice
Another product without any problem being solved.

V8 is in many regards better (especially memory footprint and ramp-up time) or
on par.

> clear access to Java directly in your Javascript.

Who needs this when having access to 50K nom packages?

~~~
jamesgeck0
I would venture to guess that interoperability with existing projects and
services is important to some people. Also, there are Java libraries which are
significantly better than their closest corresponding Node package.

~~~
camus2
Why would you code in Javascript on the JVM to begin with if you have existing
projects and libraries written in java ? that's stupid. If the goal is async
IO there is Vert.x and other non blocking servers already. Not even talking
about cases when libs require C++ extensions... Can you code in Java on Nodyn?
no

EDIT : seems to be built upon Vert.x ? you can already code in javascript with
Vert.x

~~~
lanceball
"that's stupid" is a pretty broad statement. There are many reasons why one
may choose to write new software in JS while taking advantage of existing
investment in Java. If it doesn't make sense for you, don't do it. But for
many it may.

As for coding Java on Nodyn, well, yes you can. That's kind of the point in
some ways. You can write Java, package it as a jar and access this from Nodyn.
Nodyn itself does this for the Buffer implementation.

Yes, vert.x already supports JS (I maintain the mod-lang-js, mod-lang-rhino
and mod-lang-dynjs language modules for vert.x). The idea behind Nodyn is to
provide drop-in Node.js compatibility in the Vert.x environment.

