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.

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.

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!

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!

• 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

Do I have to pick one? In that case: BigInt is huge. It’s the first time JavaScript gets a new numeric type, and this opens up entirely new use cases such as using JavaScript to write financial applications (where precision is paramount).

I’m also excited about the upcoming class features. Any proposal that meaningfully expands existing functionality in the language is A-okay in my book.

1. Stanford Engineering’s CS1 course on compilers is available online. I haven’t looked at it myself but have heard good things about it.

2. V8 has an interpreter (Ignition) and an optimizing compiler (TurboFan). Most modern JavaScript engines have a similar setup (maybe with a few extra compilers thrown in there). V8 can create optimized code based on certain assumptions, but when the assumptions become invalid we have to deoptimize.

That’s a very broad question! There’s lots of different aspects to “performance”. In my day-to-day work, I mostly focus on load-time performance. The best advice I can give there is to ship less code :)

Invest time in setting up a robust build pipeline. Consider using a tool like webpack or rollup to minimize the size of your generated JS and CSS bundles. If you transpile JS, use babel-preset-env to avoid over-transpiling — this helps with both load-time and run-time performance.

Rendering performance is another important aspect.

I recommend the Web Fundamentals performance guide.

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).

On January 1st, 2018, I embarked upon a spontaneous three-hour horse ride that changed everything. My white-maned friend’s name was Burro, and he took me on a wonderful tour through the beautiful Ibagué country fields. I had never ridden a horse before, and had such a good experience! It’s an afternoon I’ll never forget.

That night, I vowed to never fight Burro, or any other horse — especially not when they’re duck-sized.

I’m sorry, horse-sized duck. You’re going down.

Asking the important questions!

U+1F618 FACE THROWING A KISS 😘 I like Apple’s rendition in particular.

The cool thing about web app security basics is that they don’t really change over time.

For web app security specifically, I’ll say the following.

Sanitize content in different HTML contexts to avoid XSS. Apply defense-in-depth, and use CSP as an additional layer of security. Use SRI if you load resources from a CDN. Check your server configuration, and make sure you serve each resource with the correct MIME type and headers to disable MIME sniffing where applicable. Avoid cookies, and if you must use them, consider applying the SameSite flag. Never trust any data that you do not fully control (e.g. user input, data fetched from a third party, request header values, etc.). Train yourself to have a security mindset: always assume the worst.

IMHO the best (and most fun!) way to learn about all this, is to try and exploit these bugs yourself. There are perfectly legal ways of doing so.

Try to exploit XSS vulnerabilities: https://xss-game.appspot.com/ Hungry for more? Google Gruyere takes it even further: https://google-gruyere.appspot.com/

I used to play a lot of Security CTFs with my friends from KUL (team Hacknam Style 4 lyfe!). These are online competitions where you get access to similar hacking challenges. Every level contains some kind of vulnerability, and exploiting it gives you access to a secret “flag” you can then submit to score points.

With every single CTF I played, I learned something new. I ended up starting a project to collect my (and later, other people’s) write-ups along with the original challenges. Here are some example write-ups for web challenges:

• github.com/ctfs/write-ups-2014/tree/master/hack-l…
• github.com/ctfs/write-ups-2014/tree/master/hack-l…

Ideally, a beginning programmer knows absolutely nothing about any specific JavaScript engine. The number one thing to focus on is the JavaScript language. Read articles and books; follow interactive tutorials; start hacking on some hobby projects — whatever works best for you. But start with the language as a base, and keep an open mind. Learning about JavaScript engine internals as a beginning JS developer goes against that.

I’ll give you an example. V8 used to have a compilation pipeline called Crankshaft. For technical reasons, it didn’t do a great job of optimizing any code within try-catch blocks. This implementation detail caused some well-meaning developers to avoid try-catch altogether in their code “because otherwise it would be slow”, and instead work around the lack of proper error handling in complicated ways. Last year we shipped a new pipeline with TurboFan, our new optimizing compiler. try-catch can now be optimized in V8. All those hacky workarounds are now moot.

One can definitely gain valuable insights from studying a JavaScript engine. Heck, I’ve been doing this on a daily basis since last June :) But it’s important to recognize that optimizing for any specific engine doesn’t make much sense in the long-term. This applies to the Web platform with its diverse browser landscape, but to Node.js as well.

To optimize for performance across the board, i.e. in various JavaScript engines, learning about language details (e.g. by reading the spec) is far more valuable.

And there’s no reason you can’t do both! If you want to read about V8 internals while also learning something about JavaScript language details and getting performance tips that apply in all JS engines, check out my write-up on Elements Kinds, for example.

TL;DR Don’t jump through hoops trying to avoid a V8 implementation detail you once read about on Hacker News in 2011. Write idiomatic JavaScript code using modern language features. Focus on writing code that makes sense to you. That way, JavaScript engines across the board can focus on making it run fast for you.

Good standards take time.

Longer answer:

1) Writing a good feature proposal is hard. The best new proposals describe a clear use case and discuss multiple possible solutions with their pros/cons. Even just doing the research and putting together such a document be very time-consuming. Later, the proposal also needs formal spec text, Test262 tests, and eventually JS engine and browser implementations. Oh, and ideally there’s a transpiler plugin too. For some TC39 proposals, most of this work is driven by a single person.

2) New functionalities must be formally proposed (or “championed”) at TC39 meetings. There is a staging process, ranging from Stage 0 (the “hey, I’ve got an idea” stage) to Stage 4 (the proposal is shipping and merged into the spec), and each stage advancement requires committee consensus.

3) That’s right! TC39 operates by consensus, meaning anyone on the committee can single-handedly block a proposal from advancing or making it into the spec. This is great, as it sometimes prevents the committee from making mistakes that can’t be undone later, but it can also result in delays.