The State of JavaScript - Brendan Eich

Howdy, Bryan. A few comments.

First, it's not all about _moi_. As with any mature language with multiple implementations, there is a committee, Ecma TC39. It has reps from all the bigs plus PayPal (Doug Crockford) and Yahoo!. We avoid design by committee, instead focusing on paving the cowpaths and in a few cases working with champions -- single innovators or RPG's "resonant dyads" _a la_ ken&dmr -- to do focused design. The best example in my view is the Proxy design by Mark Miller and Tom Van Cutsem, followed by Modules by Dave Herman and Sam Tobin-Hochstadt.

We have a few goals, including minimizing kernel semantics and extending syntax for usability only where we have experience and positive user-testing results (e.g., destructuring, let, generators, classes as prototypal sugar a la CoffeeScript).

In this light, we aren't dumping new semantics into ES6. If you count fairly, we are filling the big semantic gaps in ES5 (AKA JS as we know it). For instance, where is client-side synchronous "require" without the ES6 module system? No fair that Node's require is sync (against all sound doctrine!). Sync XHR is from the jank-devil, and we cannot do sync require as an API client side.

Second, as others have noted, V8 was stealth'ed for two years (I learned of it in 2006 but Google withheld, see https://brendaneich.com/2011/06/new-javascript-engine-module...) and then unleashed just as Apple and Mozilla got their JIT acts together. At the time some said V8 was 3x faster, but the actual ratio on stupid benchmarks was more like 1.3x at first.

V8 is an amazing piece of work, but it did not contribute to the language evolution that my "very brief history" slide diagrammed. It certainly contributed by being the fastest, but until after 2010, that was the extent of its influence, for several specific reasons.

For the first few years as open source, V8 foreswore diverging from JavaScriptCore (the first WebKit engine, Apple's fork of KJS from KHTML, which V8 in some ways forked WebKit to replace) on any new ES5 or ES6 proposals, to try to keep on (or get back on, in view of the fork) Apple's good side. Fat chance!

Even now, V8 still keeps prototyped ES6 implementations hidden behind a flag. I expect this flag to be lifted before ES6 is ratified.

Another thing that hurt: Google has moved V8 to Munich because the Aarhus team wanted to do Dart, Google explicitly chose to invest in Dart over JS, and the no-remote-teammates rule hurt. IMHO the Munich team is quite strong but only ~10 people. This limits its effectiveness compared to Chakra (~60 heads?) and even SpiderMonkey (~12, more with interns).

Finally, whoever thinks I disrespect V8 clearly does not listen to my talks. The video will be up, give it a view when it's live if you have time. There is no disrespect from me toward V8 or the team that built it. I do mention it favorably in all talks, including Strange Loop (if my memory serves).

Lars Bak did the Strange Loop first night closing keynote, which my insane schedule prevented me from attending. He and I have had no meetings since that one in 2006, although he met with some Mozilla colleagues in 2009. I bear no bad feelings, although Lars did tell a gratuitous whopper around 3:50 in this talk: http://www.youtube.com/watch?v=T2TJYBmDZHI (see my blog cited above for what happened with Mozilla being "offered" V8 in 2006 -- Google reneged). He is the best VM hacker I know of. (Mike Pall is another superhacker of note.)

I hope this sheds some light. I respect V8 while noting that, as with anything human, it and the technical/product/open-source/standards politics around it show some significant flaws. That is inevitable.

Mozilla has flaws too, but they tend to be different in kind. For example, we do open from the start and try to partner even against long odds (e.g., Tamarin/ES4). I'm not bragging, because I think that can be a mistake. I've learned from V8 and modified Mozilla strategies accordingly.

So, hats off to V8!

Saw dherman's comment just now, he and you are right that there is a spectrum of TCP, and if you use a subset of JS to write expression-bodied => functions, you get the refactoring property that people associate with TCP.

Work with say Khronos group to establish an OpenCPU standard with a source code and possibly intermediate representation.

Socialize amongst CPU vendors, and interest platform makers in the mobile and desktop space.

Watch it absorbed by web standards.

He meant server-side JS was relatively non-existent before node.js, he even listed alternate server-side JS impls that did use server-side JS, nothing of which is anywhere close to the phenomenon that node.js is now.

You are still being free with accusations of spreading misinformation and other evils. If you want to have a real exchange, cool it! Just try to imagine how a hardball from me casting aspersions on you for suspected bad or unfair (to Mozilla; "fair" to Google) motives might feel.

Thanks for the PNaCl pointer. My comment was based on LLVM bitcode having machine word size dependencies. This was an issue a while ago. I should have checked to see if it remained one.

This correction doesn't alter the general unreadiness of PNaCl for the web, on several fronts. Pepper is one, but PNaCl performance lagging NaCl is another. The Chrome Web Store features games ported via NaCl, for performance -- not PNaCl, which would be significantly slower. On this basis alone, it's premature for you to push PNaCl ahead of Google.

> This is a far more reasonable and compelling story.

Well, gee, thanks a ton! :-|

I've been telling this story clearly since Fluent in May. That you chose not to hear it and instead flung accusations and told sob-stories about big bad Mozilla is your doing, not mine.

Here's a final clue: all browser vendors, definitely including Chrome, make the rule (not an argument) "no one gets to the machine except through our VM(s) and GC(s)" -- outside of a few dying plugins, which are even source-licensed and co-released.

And that brings back my final point: NaCl is for safer plugins, which are OS-specific anyway. The likeliest evolution of SFI or CFI enforcing compilers and runtimes as plugin hosts is via the OS, not the browser. Write a letter to Microsoft and Apple, not to Mozilla!