On Fri, May 11, 2012 at 11:23 AM, Stewart Mckinney <[email protected]>wrote:
> 1) Pretty tight. The abstraction layer between v8 and node isn't thick > enough or generalized enough, from what I can tell. To be fair, writing an > abstraction layer between multiple JS engines is very difficult (I am doing > such now for a different project, non-web related). JSC and v8, for > instance, have *very* different ideas of how to do things. From what I > understand, as well, SpiderMonkey has really limited support for passing > arbitrary information (void *) in callback functions, which is part of the > magic of v8. Indeed, the SpiderNode project was trying to solve this by adding the V8 API to SpiderMonkey so it could be used as a drop-in replacement. Also binary node addons use V8 APIs directly. > > 2) Wondering what "runtime API" compatibility means. If it means > "SpiderMonkey will have a similar class structure to v8, with a very > similar callback pattern, then abstraction layers for node are possible and > you could run it off SpiderMonkey. But looking at SpiderMonkey's API, thats > doubtful. If it means "SpiderMonkey's JS environment will have a completely > congruous API to the v8 JS environment", then that doesn't really make it > easier to run node on SpiderMonkey, because a significant abstraction layer > would need to be built and some re-organization done before it node's > Buffer/Parser classes could work through the layer on both engines, both of > which are pretty key to node. However, restructuring for SpiderMonkey would > probably make building on top of JSC pretty easy, as its kind of "in the > middle" between SM and v8. > > I'm working on re-implementing node using libuv + spidermonkey using the native smjs APIs (github.com/creationix/luvmonkey). As far as I can tell, this will be possible, but most the C++ in node will have to be re-written. I should be able to reuse a good bit of the js though. Node has a non-trivial amount of it's standard library written as js modules. LuvMonkey is still quite early, but the end goal is to be API compatable. Meaning anything using node public JS APIs will be able to run in LuvMonkey too. Binary addons won't be portable since they include v8.h and I don't care to bridge that. > On Fri, May 11, 2012 at 1:00 AM, dhruvbird <[email protected]> wrote: > >> I was wondering - how tightly coupled is node to v8 actually? I mean I >> have heard that mozilla is making their runtime API compatible with >> that of the v8 API, so is it possible to just plug it in instead of >> v8? I remember seeing a project called SpiderNode doing so a while >> ago. >> >> Regards, >> -Dhruv. >> >> On May 10, 7:51 am, Erik Dubbelboer <[email protected]> wrote: >> > They actually use Rhino <http://www.mozilla.org/rhino/doc.html> >> instead of >> > V8. >> > >> > >> > >> > >> > >> > >> > >> > On Thursday, May 10, 2012 3:56:26 AM UTC+2, Matt Sergeant wrote: >> > >> > > No. >> > >> > > Though I imagine Isaacs is wondering where the file read performance >> > > difference is. My gut feeling is that Java maybe uses mmap under the >> hood, >> > > or some other performance trick. It would be much more obvious if >> there >> > > were strace output. There's also other probable wins, like using a >> newer V8 >> > > that optimises non-VM functions (see recent thread about >> threads-a-gogo >> > > being faster even with just one thread). >> > >> > > On Wed, May 9, 2012 at 9:32 PM, Node42 <[email protected]> wrote: >> > >> > >> <a href=" >> > >> >> http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-simple.. >> .">Benchmark >> > >> </a> >> > >> > >> <a href="http://news.ycombinator.com/item?id=3948727";>Hacker News >> > >> Discussion</a> >> > >> > >> <a href="http://news.ycombinator.com/item?id=3927891";>Hacker News >> > >> Discussion 2</a> >> > >> > >> <a href="http://vertx.io/";>Vert.x</a> >> > >> > >> <a href="http://www.infoq.com/news/2012/05/vertx";>InforQ article</a> >> > >> > >> <a href=" >> > >> >> http://fbflex.wordpress.com/2012/05/02/running-vert-x-applications-on.. >> .">Running >> > >> Vert.x Applications on Heroku</a> >> > >> > >> -- >> > >> Job Board:http://jobs.nodejs.org/ >> > >> Posting guidelines: >> > >>https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> > >> You received this message because you are subscribed to the Google >> > >> Groups "nodejs" group. >> > >> To post to this group, send email to [email protected] >> > >> To unsubscribe from this group, send email to >> > >> [email protected] >> > >> For more options, visit this group at >> > >>http://groups.google.com/group/nodejs?hl=en?hl=en >> >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
