19 comments

[ 3.3 ms ] story [ 47.5 ms ] thread
node is tied to v8 correct? if so, why? are there technical reasons that node cannot be made to work on spidermonkey or rhino, or is it that v8 has supplied underlying tech that node depends on and the same would have to be done in the other engines? It seems like a full blown node/npm running on the jvm would be useful...
libuv is the other major piece of Node, it'd probably need to be ported to the JVM in some fashion. I don't think there's any real technical limitations preventing a JVM based Node-esque platform, just no one's taken it on.

https://github.com/joyent/libuv

The full blown node running on the JVM is called http://vertx.io/
if you search for vert.x on HN you see a ton of comments and activity about it 2-3 years ago but it seems to be largely ignored in the last year or so. It seems it has lost whatever popularity it once had - do you think thats a fair assessment? The idea seems nice - a polygot application framework sounds like the ideal way to use the right tool for the job.
> It seems it has lost whatever popularity it once had

Popularity is always a problematic metric for platform evaluation, because the programming community generally has a very short attention span. I would attribute the lack of marketing to the previous license fight, work towards platform stability of version 2.x, and work on the upcoming version 3.0.

> a polygot application framework sounds like the ideal way to use the right tool for the job.

Vert.x is not completely polyglot. It supports many languages, but they all must compile to JVM byte code to work within the platform's event-loop/thread-pool management. So, the Javascript must run on Rhino or Nashorn, the Ruby must run in JRuby, the Python must run in Jython, etc.

(comment deleted)
native modules (written in C rather than javascript) can be rather intimate with v8. Sure, they could be intimate with another js engine but they would need to be updated.
> It seems like a full blown node/npm running on the jvm would be useful...

sounds almost like http://openjdk.java.net/projects/nashorn/

Nashorn is a JavaScript interpreter which would make it a competitor to V8 or SpiderMonkey. Node is a framework that is tightly tied to the V8 implementation. Untying node from V8 would let it run on Nashorn or any other JavaScript interpreter.
There isn't really except somebody has to do it, TJ had mentioned that as an idea for something post 1.0.0
Node is a bridge from v8 to libuv with some additional boilerplate. npm runs on top of node for package management.

Even if this were less coupled, there are binary modules within npm that are also coupled with node and v8 in order to build against.

There were some spidermonkey experiments with node, that could run against it, but the modules in npm, specifically platform specific modules (ranging from bson to sqlite and beyond) that are tethered beyond javascript (v8 specific) that wouldn't work.

I don't know that it would bring that much to the table... one could do a bridge similar to what EdgeJS does with node and .Net that could work. It wouldn't be Rhino/Nashorn specifically, but might be worthwhile.

Gotta keep control over that ™ I guess?
(comment deleted)
If I could roll my eyes any harder I might throw an exception.

Trademarking node, who do they think they are, Oracle?

I'm not a fan of Joyent at all. I wish they would go away. The whole trademarking the Node logo makes me not want to do any node anything forever!

Then I lift my head up in shame as I type more javascript... a tear falls and twinkles in the monitor light.

One day the Javascript fairy will come and make all my wishes come true.

I'm a real boy!