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.

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.

I’ve sort of been working on this thing…

Several weeks ago I was curious about why there was no implementation of Node.js using the SpiderMonkey JavaScript engine (the one we use in Firefox). So I tweeted about it and several people said they wanted such a thing and would help work on it.

After some poking around the source, we realized that Node was tied pretty closely to V8, and there really wouldn’t be any way to use SpiderMonkey without ripping Node apart and rebuilding it. Not only would that suck now, but it would likely suck long into the future as Node gets updated. This port would fall behind and nobody wants that.

V8Monkey

So we decided that we would implement the V8 API on top of SpiderMonkey. That way we can just plug our work into Node, and it would “just work”. We’ve been chugging along on this project and have made some great progress. Thanks to John Ford we even have an automated build system running all of our tests on every checkin.

The JS team at Mozilla is also really interested in just having this API around. It has potential for other projects like this, but also raises awareness of API differences and might help push forward changes to the SpiderMonkey API. We’ve already pushed for additions to the SpiderMonkey API (for example, there was previously no exposed API to check ==, only ===). There have also been discussions about turning the SpiderMonkey API into a C++ API (not just C).

It also turns out that we’re not the first people to go down this track. There’s a team at Yahoo! who is very interested in Node and even did a very similar project. They even put the code out there to prove it and it’s been a helpful reference for us. They stopped short to get Node mostly running, while our goal is a bit more ambitious and implement the whole V8 API.

SpiderNode

SpiderNode is what we’re calling our fork of Node. Once we have our V8 binding working, we’ll shift our work over here and focus on integrating SpiderMonkey into the Node build system. Ideally we’d love to get this upstreamed and give Node developers a choice.

We think V8 is great and the fact that Node has become so widely used is a testament to that. But we also think there’s room for competition here. Browser based competition is old-hat. Let’s move this battle to the servers :)

With some hackery from John, we now have a way to build SpiderNode. As of Tuesday node.cc compiles (OMG AWESOME) but that’s it.

Can You Help?

Absolutely. The code for both v8monkey and SpiderNode are on GitHub for now. We have a “hacking” wiki page there, as well as a general TODO page.

We also chat a lot on IRC: #spidernode on irc.mozilla.org.

It’s Not Just Me

That’s for damn sure. Rob Arnold and Shawn Wilsher have been doing most of the heavy lifting. Rob has done some work on SpiderMonkey in a past life and is really good at this sort of language stuff. Shawn is also really smart and definitely no stranger to using SpiderMonkey. This project would be nowhere without these guys. John Ford set up a buildbot for us, which has been incredibly helpful for catching all the tests I break. Having a build engineer helping out has been really great.

Brendan Eich (you may have heard of him) said he’s going to start contributing. My intern Mehdi Mulani submitted a couple patches early on and others have stepped up and are working on patches right now.

My Experience So Far

Honestly, this is the first large scale C/C++ project I’ve worked on. I took 1/2 a semester of C my freshman year in college (over 6 years ago) and I’ve written some random pieces of C++ at Mozilla. Mostly though, I write JavaScript and before that Ruby & PHP - a lot of scripting languages. It’s a drastic change from what I’m used to and it’s taken me a while to get comfortable. Luckily I’m working with friends who have helped teach me as I go. Learning C++ while making one JavaScript engine work on top of another has been a real sink or swim experience.

It’s been fun though. I really needed something entirely different from Firefox for a little while and this has fit the bill perfectly.

Expect to see more from me and others in the coming days & weeks. And hey, perhaps you’ll see one of us at NodeConf.