Live data from Hacker News

Node.js on mozilla spidermonkey

blog.zpao.com

11–17 of 17 posts

Re: Node.js on mozilla spidermonkey

#11
post #6

Are people doing this just for fun or are there advantages in switching to Spidermonkey?

I don't know if this is their motivation for it, but SpiderMonkey implements many useful non-standard features, including generators and iterators. JS 1.5: https://developer.mozilla.org/en/JavaScript/New_in_JavaScrip... JS 1.6: https://developer.mozilla.org/en/JavaScript/New_in_JavaScrip... JS 1.7: https://developer.mozilla.org/en/JavaScript/New_in_JavaScrip... JS 1.8: https://developer.mozilla.org/en/JavaScript/New_…

Those features are a lot of the reason for it, yes. As a cool example of what can be done with generators, check out my colleague Dave Herman's task.js library: https://github.com/dherman/taskjs

That library gives you coroutine-style I/O on top of node.js primitives, which is, as far as I can tell, the #1 feature people have been asking for all along in Node. It only works if node.js implements coroutines (which Ryan has so far refused to do) or if the language implements generators (which you get with SpiderMonkey).

Re: Node.js on mozilla spidermonkey

#12
post #5

I always wondered why Node.js is based on V8 in the first place; to my (limited) experience, SpiderMonkey's API is both simpler in use and better documented. Was it a speed thing in Node's early days? Cool move, nevertheless. Sounds like a pain to maintain, though.

SpiderMonkey used to be very slow. Wikipedia says Node.js was released in 2010, I'm not sure when development started, but if it was when V8 was significantly faster, it seems like an obvious choice.

http://arewefastyet.com/old-awfy.php

Re: Node.js on mozilla spidermonkey

#13

Are people doing this just for fun or are there advantages in switching to Spidermonkey?

V8 is a single-threaded VM and I don't see that changing any time soon, it's very much married to Chrome's per-process model. SpiderMonkey doesn't have that drawback, it supports threads just fine. These guys have their work cut out for them if they want to support the V8 API from within SM. It's a well designed API but large and fast moving. Still, an interesting project. I'm going to watch it, maybe submit a few pa…

V8 supported multiple threads since long ago using a big VM lock approach (v8::Locker). Since 3.2.4 it's possible to run independent V8 code in parallel using the new v8::Isolates API: http://code.google.com/p/v8/source/browse/trunk/include/v8.h...

Re: Node.js on mozilla spidermonkey

#14

Are people doing this just for fun or are there advantages in switching to Spidermonkey?

V8 is a single-threaded VM and I don't see that changing any time soon, it's very much married to Chrome's per-process model. SpiderMonkey doesn't have that drawback, it supports threads just fine. These guys have their work cut out for them if they want to support the V8 API from within SM. It's a well designed API but large and fast moving. Still, an interesting project. I'm going to watch it, maybe submit a few pa…

I think Mozilla is also making SpiderMonkey threading model more strict. https://developer.mozilla.org/en/JS_THREADSAFE says:

JS_THREADSAFE is now permanently on.

We have recently made major changes to this feature. Until recently, sharing objects among threads would mostly work, although scripts could easily make it crash. We have now completely removed that feature. Each thread that uses the JavaScript engine must essentially operate in a totally separate region of memory.

------

So both VMs provide essentially the same multithreading capabilities.

Re: Node.js on mozilla spidermonkey

#15
post #5

I always wondered why Node.js is based on V8 in the first place; to my (limited) experience, SpiderMonkey's API is both simpler in use and better documented. Was it a speed thing in Node's early days? Cool move, nevertheless. Sounds like a pain to maintain, though.

I'm willing to bet speed was a factor, but the other thing Ryan noted was the API difference. The article on the Register about SpiderNode (http://www.theregister.co.uk/2011/04/20/mozilla_moves_node_d...) mentions that:

> Dahl originally set out to build Node atop Mozilla's SpiderMonkey – the JavaScript engine included with Firefox browser – but this effort didn't last long. After about two days, he switched to Google's V8. "V8 is just a nice, clean library," Dahl told us earlier this year. "It's compact and extracted away from Chrome. It's distributed as its own package, and it's easy to build and it's got a nice header file with nice documentation. It's kind of constrained. It doesn't have dependencies on other things. It seemed much more modern than the Mozilla stuff."

I mostly agree about the clean API. It's compartmentalized and makes more sense to me overall. Documentation though...

As for maintenance, I'm really hoping it won't be too bad. Once V8Monkey is standing, it shouldn't be terrible to keep up. And so long as Node doesn't start using new or modified APIs, then SpiderNode should be fine.

Re: Node.js on mozilla spidermonkey

#16

Are people doing this just for fun or are there advantages in switching to Spidermonkey?

V8 is a single-threaded VM and I don't see that changing any time soon, it's very much married to Chrome's per-process model. SpiderMonkey doesn't have that drawback, it supports threads just fine. These guys have their work cut out for them if they want to support the V8 API from within SM. It's a well designed API but large and fast moving. Still, an interesting project. I'm going to watch it, maybe submit a few pa…

If you're interested in helping out, best thing to do is stop by the IRC channel and see what we need the most help with (or if you want to start more simple, we can point you at that too). We've been moving pretty quickly in the week since that went up.

Re: Node.js on mozilla spidermonkey

#17
post #16

Earlier quoted context omitted.

V8 is a single-threaded VM and I don't see that changing any time soon, it's very much married to Chrome's per-process model. SpiderMonkey doesn't have that drawback, it supports threads just fine. These guys have their work cut out for them if they want to support the V8 API from within SM. It's a well designed API but large and fast moving. Still, an interesting project. I'm going to watch it, maybe submit a few pa…

If you're interested in helping out, best thing to do is stop by the IRC channel and see what we need the most help with (or if you want to start more simple, we can point you at that too). We've been moving pretty quickly in the week since that went up.

http://www.realseocompany.com/ http://www.realseocompany.com/local-seo-company/ http://www.realseocompany.com/our-services/ http://www.realseocompany.com/our-services/seo-marketing/ http://www.realseocompany.com/seo-marketing-services/
Post reply on HN