NodeConf is a blast, and Mozilla had a 30 minute slot. Here’s the slideshare.net link.
SpiderNode and V8Monkey are on github, of course. Paul O’Shannessy already blogged a few weeks ago.
To avoid confusion, here’s the cheat-sheet:
- V8Monkey is SpiderMonkey with V8’s API around it. We are not done emulating the full V8 API.
- Because we haven’t managed to perfectly emulate the full V8 API, the few language-level extensions (e.g.,
Error.captureStackTrace), and the V8 build system, SpiderNode is a clone of Node with V8Monkey integrated and (in a few cases we want to get rid of) hacked in place of V8.
This slide should speak for itself.
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.
We are trying to improve SpiderMonkey’s API, test Harmony JS language features in the Node setting, and have fun learning about the new JS server side.
These four slides are straight from my JSConf.us 2011 talk. I went fast since a lot of NodeConf attendees were at JSConf, but a good number of hands did not go up when I asked who attended both conferences.
yield conquers the nested function spaghetti monster.
Generators are winning, and they are worth playing with and investigating in SpiderNode and of course Firefox and other SpiderMonkey embeddings (also in Rhino). They are not the last word on the “anti-function-nesting” topic, for sure. I’m pretty sure there is no “last word”.
Thanks to Rob Arnold for this demo and the next one, and of course to Dave Herman for TaskJS. Thanks too to Shawn Wilsher for the encouragement at the last minute 😉.
This is an even shorter demo. I switched to a terminal window, fired up $ ./node helloworld.js, loaded https://127.0.0.1:10337/ into a fresh Firefox window, and pressed reload repeatedly to show the counter incrementing.
Node really did break the mold when it comes to ease of writing server code that you can get running super-fast, using JS and lots of the client-side knowledge you may already have.
One more time: thanks to @robarnold, @sdwilsh, @zpao, the awesome @john_h_ford who did our build automation, and of course my partner in crime for much mad science at Mozilla, @andreasgal.
Join us on IRC and the mailing list, we have a lot of work still to do, and we’re having a ton of fun.
/be
“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.”
*That’s* what I needed to see a lot sooner. As a huge fan of Node, hearing about this project and seeing the fork was a bit concerning; it felt to me, (as well as a few of my hacking friends) that this was a competing effort. My fault for not reading more on it.
Node is stabilizing at a rapid pace, thanks mostly to the contributions of a huge number of extremely talented folks. It’s a minor (or perhaps invalid) concern, I suppose, but I’d hate to see Node progress slowed… but then again, as has been pointed out, Yahoo did the same thing. But my #1 concern is a splintering of the community.
Thanks for posting this, and correcting a poor assumption and impression on my part.
As an aside, do you forsee any features being fed back into Node? Do you see Mozilla creating a SpiderMonkey-based CommonJS implementation based on this research?
Clint: I said that (“no maintained fork”, “not selling”) out loud and in several ways during the talk…
We have SpiderMonkey CommonJS embeddings. Wes Garland’s GPSEE (https://code.google.com/p/gpsee/) is a noteworthy example.
I ended up (thanks to @mikeal) joining the panel at the end of NodeConf, which was good because @ryah and I had a dialog about what he’s looking for in certain APIs (strings, to avoid copying or flattening). See
https://twitter.com/#!/ls_n/status/66357876138061825
https://twitter.com/#!/lancefisher/status/66302805492768769
/be
Maybe I don’t fully understand how this mixes with Garland’s GPSEE.
I thought GPSEE was quite obsoleted by SpiderNode, because when buiding Node.js on top of SpiderMonkey you are getting a CommonJS implementation without writing again all the bindings, like GPSEE does.
Am I getting something wrong ?
Sorry, Brendan… just to be clear, I didn’t attend the talk, nor NodeConf, (sold out to quickly). The SpiderNode project was brought to my attention via a colleague and I viewed the source on GitHub. I wasn’t aware of the NodeConf talk until you brought it to my attention, which clarified things quite a bit… and I’m glad that was reiterated during the presentation.
It will be interesting to see the fruit borne through this codebase, and I’m glad there is input coming from all sides.
@JMDESP:
CommonJS is much more than a ‘require’ statement and module system, and GPSEE is much more than just CommonJS.
Node and GPSEE likewise have very different goals. Node is oriented in large part toward writing web-server-type applications, with evented I/O and callback-heavy JS.
GPSEE is more oriented toward system-ish tasks, say in the Perl, shell-script, etc space. We do things like expose POSIX and SVID APIs, have Curses routines, etc. We also have support for modules written in C (or C++), as well as blended modules (part C, part JS). Of course, our C modules use the Mozilla JSAPI.
We are also more interested in and committed to CommonJS than Node.JS appears to be. We implement a later version of the Modules specification, and prototype draft specs. We also ship with implementations of several ratified CommonJS specs — System, Binary/B, and fs-base — with more on the way as CommonJS evolves.
Of course, to say that either environment can’t perform task X is almost certainly wrong; they are both flexible, general purpose programming environments.
Incidentally, while it has not been done yet, it should be possible to build SpiderNode with GPSEE underpinnings. This is because GPSEE is written, first and foremost, as a JSAPI-augmenting library (extra work would need to be done to handle the require-symbol collision, but that seems straightforward).