The State of JavaScript - Brendan Eich

Video coming (conferences like Strange Loop are good about this but you had to be there to get the full effect), plus see https://brendaneich.com/2012/10/harmony-of-dreams-come-true/ for a companion blog post that focuses on some of the slides.

> The presentation focused on what it perceived as missing features: structs (seriously?), classes, modules, syntactic sugar, macros, etc.

The nature of a widely-used technology is that you can't remove features, you can only add. And yet adding features causes an increase in complexity. So what to do? The answer is to add features judiciously: prefer general features that cover a wide array of use cases and can provide better ways to do things that the existing features don't do or don't do well. (But also avoid over-general features that destroy important invariants -- for example, just say no to call/cc or threads.)

> But the huge gaping holes in Javascript are not missing features. They are fundamental errors in the language. Things like ==, numbers as strings, eval, incorrect definitions of false, semicolon insertion, and -- heaven help us all -- improper lexical scoping.

ES6 -- and potentially down the road, macros -- are paving paths to fix many of these problems you mention, and other important problems besides (e.g., callback hell). Lexical scoping is partially improved with ES5's "use strict" and further improved with ES6 modules. Block scoping finally exists thanks to `let`. ES6's module loaders allow translation hooks to enable dialects or alternative languages to be run in-browser (which you can do with preprocessing and build steps and directly, but using them in-language streamlines the "shift-reloadability" development experience). Module loaders also provide a saner eval, which allows you to completely sandbox the evaluated code. Macros could even allow rebinding operators like `==` to have cleaned-up semantics. We intend to try this out with sweet.js, building something like "restrict mode" (http://restrictmode.org) as a module you can import.

Dave

Though the expression version of => comes pretty close to TCP.

Dave

There is a wide gap between fully embracing a technology and spreading misinformation about it. I respect Mozilla's decision not to integrate NaCl, to argue that it's premature to talk about doing so while it's underspecified and coupled to Chromium, and to set criteria that it must meet before it will be on the table for further discussion. I can understand concerns about cost and governance and an unwillingness to jump on what is perceived as a "Google treadmill." None of my comment was about any of that.

What I can't understand is the fundamentalist reaction to the very idea of native code, the ignoring/dismissing of serious work to solve the problem of portability, the liberal use of words like "never" and "non-starter," spread of FUD by invoking inaccurate comparisons like ActiveX (vis a vis its security model) and DLL Hell, and the spreading of misinformation. For example, PNaCl is not, and as far as I can tell never has been, dependent on machine word size. The link you cited doesn't apply because it is arguing against a different approach than what PNaCl actually does.

PNaCl works by defining a little-endian ILP32 machine as the target and fixing all important characteristics of this machine independently of the characteristics of the underlying CPU. This abstract machine's characteristics are defined in such a way that they can efficiently be translated to native code on any modern CPU. This is all covered in the introductory doc: http://src.chromium.org/viewvc/native_client/data/site/pnacl...

> a cross-browser approach targeting JS VMs, which are already there and getting fast enough with typed array memory models to compete with PNaCl? (We aim to demonstrate this.)

This is a far more reasonable and compelling story. By all means talk up your stuff and argue that you can win in the free market of ideas. I'm not arguing that I or anybody else should be able to dictate to developers what technology they use; on the contrary it is the Mozilla argument of "no one gets to the machine except through our VM and our GC" that paternalistically ties developers' hands and limits their options.

> Is it just me or does the proposed ES6-standard smell of heavy feature creep?

I've been on TC39 for years and the vast majority of what we do is cut.

> we get classes _and_ modules _and_ typed objects.

Classes are syntactic sugar for one of the most common dynamic patterns in JavaScript: object factories. Modules are static collections of code. Very different things, especially in a dynamic language like JS. Typed objects are not even remotely related; they're a low-level API for efficiently working with structured binary data.

> same with macros and codegens.

As Yehuda says, macros are not part of ES6 but rather an experiment at http://sweetjs.org to consider for future editions. I don't know what you mean by "codegens." Brendan's slides weren't talking about a feature, but rather an existing usage pattern that we need to serve in additional to human code-writers.

ES6 actually does a remarkable job covering many use cases with small modifications that smoothly integrate with the existing language. You might want to try experimenting with some of these features, many of which are implemented partly or completely in SpiderMonkey (as Brendan's latest blog post details). Most of the features are small improvements to paper cuts, and as everyone I've ever spoken to who's written SpiderMonkey-specific JavaScript attests (for example, in the Firefox front-end or in addons), they make your life so much nicer. I'm particularly thinking of let and destructuring, and I suspect parameter defaults and rest-arguments will be hugely popular as well. The few bigger features, especially modules and generators, are for addressing the most important gaps in JS.

Dave