Node.js Advisory Board(joyent.com)
joyent.com
Node.js Advisory Board
https://www.joyent.com/blog/node-js-advisory-board
19 comments
Joyent's response to the recently launched Node Forward (https://github.com/node-forward) initiative, I'm guessing.
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...
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.
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.
You did have luvmonkey¹, and spidernode².
1: https://github.com/creationix/luvmonkey
2: https://github.com/zpao/spidernode
1: https://github.com/creationix/luvmonkey
2: https://github.com/zpao/spidernode
> It seems like a full blown node/npm running on the jvm would be useful...
sounds almost like http://openjdk.java.net/projects/nashorn/
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.
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.
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
https://github.com/joyent/libuv
http://vertx.io/ aims to be very similar in architecture if I recall correctly.
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.
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.
[deleted]
There isn't really except somebody has to do it, TJ had mentioned that as an idea for something post 1.0.0
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!
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!