Paul O’Shannessy

blah. blah. blah.

What’s the Deal With V8Monkey & SpiderNode?

tl;dr Neither are being actively worked on and could use some love.


After NodeConf, development of V8Monkey & SpiderNode slowed. We all got a bit burnt out in the weeks preceding NodeConf and took a little break. Shortly after, Shawn left Mozilla to work at Facebook with Rob on [redacted] and the little break became longer. I was in the middle of planning a wedding & helping the (now-)wife with her company. Shawn & Rob were busy with work and some other side projects. Mozilla opened an office in SF in August, so I stopped riding the train down the peninsula with Shawn & Rob as often. Long story short, we lost interest.

In October I pulled current mozilla-central into the V8Monkey tree & tried to update from there. But some core things changed. APIs changed around Typed Arrays in SpiderMonkey. JSScript stopped being a JSObject which broke some of our assumptions with our implementation. I have a patch locally to try to fix those, but they’re incomplete (it immediately segfaults). It’s been 3 months and the JS engine doesn’t idle, so it’s entirely possible the world changed again.

SpiderNode is untouched. But Node has definitely changed - it’s gone from 0.4.x to 0.6.x and works on Windows! It’s now using a newer version of V8, and further, using more V8 APIs that V8Monkey hasn’t ported. It also looks like Buffers got a pretty big overhaul (I started to merge that, but it got messy). There’s surely some other work that needs to be done.

The Future

There has been some mention of the JS team here at Mozilla implementing the V8 API. Not me or somebody doing it in their free time, but a full-time employee. I haven’t seen that happen, but that’s the best possible outcome. Assuming we have 100% compatibility (which is the only target that makes sense), then the path to reviving SpiderNode from there is easy. Basically we’d just need to fix the build system again to compile SpiderMonkey & use that. Brendan has also threatened to unbitrot V8Monkey, but he’s a busy guy, so we’ll see.

If that doesn’t happen, then the future is grim. I don’t have the time or drive to do this myself. If you’re interested in helping out though, keep reading…

Want to help?

Awesome! Get in touch & I can help get you started. I’m more than happy to get that going because I’d like to see these projects live on. Keep in mind that the real work mostly happens in V8Monkey — it’s 100% C++ and you’re implementing one JS engine’s API with another.

SpiderNode at NodeConf 2011

Two weeks ago, I traveled with Shawn and Rob to Portland for the inaugural NodeConf. To summarize: it was a great experience and a well run conference. Other people have done overviews, so I’m not going to go there, but read a few here, here, and here. I’m going to talk about SpiderNode at NodeConf instead.

A Quick Aside on the State of Things

We got SpiderNode running on the train ride shortly before getting on a plane to Portland. Under 24 hours before NodeConf. It didn’t pass all tests (still doesn’t) and we had to hack around Node’s Buffers pretty majorly. Ryan’s classic node_chat ran and that was a great state to be in going into NodeConf. As for other demos, those were written right before the presentation so they were a bit unpolished.

Back to NodeConf

As we’d suspected for a while, Brendan Eich was the “Mozilla Person Secret Talk” listed on the schedule. He talked a little bit about ES.next and SpiderNode, with a couple demos. In typical Brendan fashion, it was a lot of information to get in a short period of time. If you want to see the slides, Brendan has them on his blog.

Overall, I think the reception we got was really positive. People seemed excited. Some viewed it as a way to run Node on architectures that V8 doesn’t support (before we left NodeConf I had an email from somebody telling me he had patches to get SpiderNode building on Solaris/Sparc). Others were just excited that this could open up the doors to making Node faster (more benchmarks to compete on). Other people were excited because they just really want block scoping (let).

Other people weren’t so excited. And that’s fair. But there seemed to be some misconceptions about the project and why we were at NodeConf contributing to what felt a bit like disdain.

Selling You

There were some people who seemed convinced that we were there to sell people on using SpiderNode. I think Brendan made this pretty clear during his talk, but here it is again: we’re not trying to sell you. We don’t think you should use it right now. We’re getting closer, but it might be a little while before we suggest people use it for anything besides experimenting. We don’t pass all of the Node tests and we’re almost certainly not faster at this point.

I think Brendan put it best:

We are not out to make a maintained, competing fork of Node, just a friendly downstream that should go away as soon as possible. We aren’t selling anything to Node users.

Splitting the Community

The Node community is pretty awesome and we really don’t want to split it in anyway. I’m sorry that some of you felt that’s what we were doing. If that was you, I’d love to find out what you meant.

The only angle I can see on this one is that the JavaScript one would write using SpiderMonkey’s JS extensions wouldn’t run on normal (V8) Node. This goes back to the experiment thing. If you’re writing Node modules or code you want to share widely using the JS extensions STOP.

Contributing Back

I didn’t see any comments about this topic, but I wanted to make it clear that we’re most certainly going to be contributing back to Node. We created a repository to start that process now. We’re waiting for somebody to handle this pull request, which should make some uses of Buffer faster.

There will surely be other things that can be upstreamed outside of our use of V8Monkey (and the build system changes required to support that).


I hope this clears some things up for people. Let me know if it doesn’t or you have other concerns about SpiderNode’s existence.