I agree this is an important topic. One of the things I’ve been working on since joining the team is creating or updating our documentation to reflect our best development processes. There’s a technical side to this, of course, but the non-technical aspects are much harder to communicate. A small example: at Google, there’s a culture of pinging unresponsive reviewers after a few days. It’s how we roll! However, this is not documented anywhere, and new external contributors might not feel comfortable repeatedly asking for reviews. Review latency can be frustrating and reduce development velocity. We are specifically working on this issue within V8’s coding culture. There’s definitely room for improvement, and I’d love to hear your thoughts on this as well. It makes me happy to see we’re receiving an increasing number of patches from external contributors, including Igalia, Groupon, and individual contributors like Peter Wong, Kevin Gibbons, Anna Henningsen, Choongwoo Han, Taketoshi Aono, Ben Coe, and others.

Reading specification text is definitely non-trivial. The amazing Timothy Gu has been working on an introductory document to help get started with reading the ECMAScript spec . I highly recommend it!

Best: the colleagues Worst: the perks in the MUC office (mostly the music room) that cause me to stick around the office for way too long

WebAssembly is implemented as part of V8. No threat there :) I don’t see WebAssembly as a threat to JavaScript either; I believe they are orthogonal. I’m excited about the new use cases that WebAssembly brings to the web platform — native apps in the browser!

It depends on the web app. If it’s a website that offers content without much interactivity, like a blog, it makes sense for that content to be accessible even without CSS or JavaScript. Lots of JS apps do this successfully through server-side rendering. The situation is entirely different for highly interactive tools such as SVGOMG . I don’t think anyone reasonably expects those to work without JavaScript. In general, IMHO progressive enhancement makes a lot of sense.

The Observables proposal for ECMAScript has repeatedly failed to advance at TC39. Some committee members believe it’s not a great fit as a language feature at the JavaScript level. There is now an effort to standardize Observables at the DOM level: https://github.com/whatwg/dom/issues/544

I use a MacBook Pro most of the time. As for software: I spend most of my time in a browser (Chrome) or a terminal ( dotfiles ). I consider websites and especially PWAs to be software as well, so here are some tabs I have open most of the time: Gmail, Google Calendar, IRCCloud, Google Docs, GitHub, Twitter.

The biggest challenge of evolving the JavaScript language is the backwards compatibility requirement. It’s also its greatest strength. JavaScript is so widely deployed on the Web, it’s hard to make any kind of backwards-incompatible change to the language. Even purely additive changes, such as the introduction of a new String or Array method, can sometimes end up causing breakage on websites (often in weird an unexpected ways). As a browser engineer, Breaking the Web is the worst thing that can happen. On the other hand, this means we can all write JavaScript programs today that will likely still behave the same way 20 years from now. That’s amazing!

By default, features that can be implemented in what the committee calls “userland code” don’t have a strong case to be included in the language. Exceptions can be made when implementing the feature natively would yield significant benefits compared to what’s possible in userland code: deep platform integration (e.g. Promises) performance or efficiency benefits in terms of load time, run time, or memory usage (e.g. RegExp Unicode property escapes, Intl features) some features are impossible to implement in userland (e.g. WeakMap ) So far, this has always been discussed on a per-proposal basis. Bradley Farias and Daniel Ehrenberg are currently leading an effort to codify the TC39 committee’s goals on new proposals in general, which would help answer future-facing questions such as “should new library features be in built-in modules?”. Part of the TC39 committee’s role is to act as a gatekeeper for the JavaScript language. The goal is not to maximize the number of features in the language, but rather to ensure that JavaScript continues to be an attractive language that’s as internally consistent as possible (within the constraints of backwards compatibility).

Asking the important questions! U+1F618 FACE THROWING A KISS 😘 I like Apple’s rendition in particular.