Mozilla’s NodeConf Presentation

NodeConf is a blast, and Mozilla had a 30 minute slot. Here’s the 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 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 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.


My JSConf.US Presentation

@jashkenas was kind enough to let me join him for his session. Here is the slideshare link. I’ll comment on the individual slides below.


Jeremy’s talk was entitled “CoffeeScript as a JS/next”, and I was interested in giving an update on Ecma TC39 Harmony progress, so when Jeremy and I met and caught up during the first day of JSConf, we quickly agreed on a joint session with about 15 minutes in the first half for my stuff.


JS developers sometimes seem afraid of the future, specifically of what browser vendors and Ecma TC39 might do to them! Here I used some inspiring quotes and a practical, three-step process outline to encourage everyone at JSConf to have courage and make their direct wishes known, as best they can. By acting (using CoffeeScript, for example) as well as writing (es-discuss at

Browser competition is hot, browser vendors crave developers as fans and supporters. This should give JS hackers great power, if they can speak coherently, as individuals and as a group. But it’s important for developers to speak clearly, since TC39 members often listen to their own peers on the committee and in their respective companies more than to the JS community writ large.

Of course “the community” does not speak with one voice. Communities do evolve leaders, and leaders are often necessarily articulate. Also, effective communities produce artifacts such as PrototypeJS and jQuery, which speak in their own ways.

Why does the community matter? One good reason is this: communities facing harsh survival tests (as JS’s has) reward merit better than committees operating under competitive and time pressures.

@andrewdupont observed, in his barn-burner of a talk near the end of JSConf day one, how recent JS standards started as community-project library methods. Often enough, these de facto standards also started out as rough and real, i.e., far from perfect — just as JS did. They had to be user-tested and iterated upon until winning.

I reiterated this point in my talk. TC39 should avoid inventing where it can pave the cowpaths.


The Harmony goals (slightly reworded here to fit on the slide, and for clarity) indeed talk about codifying de facto standards.

The “complex applications” and “libraries” bits suggest programming in the large, implying modules and other Harmony proposals. The “code generators targeting the new edition” verbiage directly invokes CoffeeScript and the many other JS code-generators out there today.

An important point about the Harmony process: you don’t have to wait three years for a finished standard before browsers start supporting prototype implementations of solid proposals. We aim to do how implementors have done HTML5 and the Web API standards — continuous early implementation and rolling standardization. Thus, Proxies in FF4, WeakMaps in Nightly (FF6) releases, etc.


This slide (which builds bullet by bullet in Keynote) is as concise a summary as I could make of the bulk of what is already very likely in the next ECMA-262 Edition, according to the Harmony Proposals wiki page.

We have invested over the years in most of these proposals, not only on TC39 but in SpiderMonkey (with Norris Boyd, Steve Yegge, et al. matching in Rhino), in order to test implementability and usability. Firefox and other Mozilla XUL apps and add-ons make great use of let, generators, and more. We will keep adjusting our prototype implementations to match the emerging spec.

Now it looks like other browsers will start to implement Harmony proposals. This effort complements the adoption of de facto standard library functions. Some problems can’t be solved in the current language by writing library code. We need language evolution at both syntactic (user interface) and semantic (deep meaning) layers.


David Flanagan’s talk, which was first up on JSConf day one, covered typed arrays and array buffers a bit. During the Q&A I mentioned the Harmony binary data proposal from @littlecalculist.

The binary data proposal embraces and extends the fine work of WebGL typed arrays. Sometimes someone paves the cowpath into an expressway, which grows into a superhighway. JS has a lot of bits to move these days.


I’ve been talking about better function syntax for a while. function is too long (I wish I’d used fn in 1995 and preempted this issue).

TC39 has had several proposals or variations. Meanwhile, CoffeeScript has emerged and taken off. In arrow function syntax I’ve synthesized all the winning ideas, without goring anyone’s ox. This slide conveys the main points of the proposal.

The # syntax from Harmony of My Dreams evolves in this proposal to be an orthogonal prefix, for freezing and joining (fusing identity up to the nearest relevant closure). See records and tuples for analogous hash meaning.


Here I go out on a limb in listing some strawman proposals not yet in Harmony. Some of these will make, some probably won’t (there will be an

At this point in my talk, I advocated strongly for standardizing prototypal inheritance a la CoffeeScript’s class, super, and @ syntactic sugar.

TC39 is tempted to “do more”, which means invent (not by committee but by champions, single members or sub-groups working on a particular area). I believe we will not achieve consensus soon, and possibly go wrong, if we overreach.

We could renounce classes in order to remain future-proof, but JS developers are crying out for sweet and (more important) foolproof syntax to make prototype-based single-inheritance class-like abstractions. We should pave this cowpath now.

(Some at the conference tweeted against “classes” thinking this was another turn-JS-into-Java thing, but counter-tweeting made it clear that it’s purely prototypal. What’s in a name? It is hard to beat “class”, IMHO.)

Oh, and paren-free still wins. Where it is not simply a relaxation of JS’s over-bracketed C-based grammar, it gives for-in in loops, comprehensions, and generator expressions not only lighter syntax (and only paren-free syntax!) — it gives better semantics.

Generally, paren-free for-in provides the iteration protocol hook for custom iterators, definitely including generators (the easiest way to write an iterator).

Specifically, paren-free for-in reforms array iteration to be over values, not keys. This is pure win (ignoring migration, see next paragraph), as far as I can tell.

Forbidding parenthesized for-in heads makes a migration “early error”, a tax for a common good: lighter syntax with much better semantics.


JS developers and implementors on TC39 must learn from one another and “meet in the middle”. The Harmony goals are good. But developers may do only what can be done in library code, or reach for CoffeeScript or another language on top of JS. And TC39 may over-invent.

The better way is a dialog between JS developers, especially natural leaders among them such as @jashkenas, and TC39 members.

This won’t involve “scientific polling”. There’s no substitute for nice judgment and (ultimately) sound language design theory and practice. But the experts must also learn from the users, who’ve moved mountains on their own over the last ten years. And users, meaning JS developers, should step up to this dialog and away from fear and passivity.


After our talk, with some fun stage misdirection, Alex Russell and Peter Hallam of Google introduced Traceur, Google’s Harmony-ish transpiler. This is a good development on the whole. I’m happy to see it as a way to test proposals. However, I need to register some misgivings that go beyond “style point deductions”:

  • The slides are Chrome-only. Come on, it’s not 1997. I’m using and HTML/PNG. There’s no excuse.
  • Some of the extensions are neither Harmony nor Strawman. (In particular for (i : o) was rejected. So was __iterator__.) I hope this can be updated, but if Traceur turns out to support (over the long run, ignoring short-term committee jitter) other than what has been pitched and vetted by TC39, that would be several kinds of wrong.
  • Dion’s post was up last night [UPDATE: not pre-arranged, Dion is just very fast even when he’s not actually at JSConf. Sorry, D], yet it says “” without qualification. My posts, and other TC39ers as far as I know, have been careful to say “experimental”, “proposed”, “possible”, “dark horse”, etc. I personally try to assess odds of inclusion in based on the Harmony/Strawman process. No such nuance from Dion.
  • Narcissus on github is where Mozilla and several academic partners have been working on prototypes. We’re not as well-staffed as Google, but we’ve done this work in the open and I’ve talked about it since last year. Meanwhile, Traceur was done as “delayed open source”, with the wow-effect JSConf unveiling.
  • Ok, to each his own. But the after-show cajoling by Alex to me, along the lines of “come work on our transpiler with us”, left a bad taste. I say: Open-source early, tell your TC39 colleagues your plans and intentions, invite others to join you. Don’t seed the googlecode project with all-Google-employee committers, work for months in relative secrecy, and then go open.

This reminds me of how V8 was developed (I have a few saved emails from 2006… V8 released as open source with Chrome in 2008).

Again, it’s Google’s prerogative to do whatever it wants with its staff and code. But this pattern of secret-first/open-later development is on a slippery slope toward openwashing. That aside, with Traceur it seems “forkish” in TC39 social-cohesion terms.

Another point: a transpiler (syntax only or mostly) or true compiler/runtime targeting JS (new semantics too) is ultimately not enough. Harmony proposals need to be implemented in several engines, ideally including V8, before a new standard edition is ratified. No word on this at JSConf, but I hear good things from others at Google, so I’ll leave this one on a positive note.

Really, I’m not out to break TC39 and Harmony over this. Indeed we haven’t heard anything from Microsoft about what they’re hoping for in Harmony; we have not seen anything like an open source transpiler. So good for Google. But some things about how this came out don’t sit right, enough so that I’m writing publicly.


Jeremy is a star, and I want to thank him again for letting me share his slot. He made a number of excellent points, some intentionally “dialectically sharp”, all encouraging JS developers to use and even implement “better languages” built on top of JS.

The sharpest point in my mind was “JavaScript is too important to be left to the experts.” This is obviously true for several definitions of “experts”, but expertise matters too or we wouldn’t have Jison, the parser-generator used by CoffeeScript, based on Bison and Yacc before it.

Jeremy was dialectically sharp to encourage developers to throw stuff up and see what sticks. Seeing what sticks with a programming language in part depends on user-testing, usability, human factors that are not reduced to science — that is, part of language design is art. He even encouraged people to “cheat when you get stuck”, words I try to live by (after the example of Cadet Kirk).

Now, not everyone is a @WilliamShatner, or a @jashkenas. Many will get stuck, cheat, fail, and cry in despair. Not to be discouraging!

Expertise, even formal methods and people who know them, can help. Zaach‘s Jison is one example. TC39’s generally pragmatic collection of experts, including Dave Herman, Allen Wirfs-Brock, Mark Miller, Sam Tobin-Hochstadt and others, also constitute a valuable resource for the community.

What Jeremy and I tried to advocate, which I believe is happening before our eyes, is a connecting of the circle, from JS as I created it, though its fearless communities and their leaders, back to browser vendors and experts on TC39 — and around again.

We are not just advocating a language on top of JS that you use to avoid JS (GWT, Haxe, Objective-J, etc.). We are advocating that you all help build a better JS on JS, which then becomes standardized as

This is important work. I haven’t seen anything like it at this scale, with multiple interoperating implementations. It happens with single-open-source-as-spec languages (Perl, Python, Ruby). With transpilers, better libraries, and de facto, prompt (but not premature) standardization, it can happen with JS, too.