AMA with

Mathias Bynens

I work on V8 at Google and on ECMAScript through TC39. ♥ JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.

February 15th 2018, 7:00 pm

Ask me about:

  • JavaScript
  • HTML
  • CSS
  • HTTP
  • performance
  • security
  • Bash
  • Unicode
  • macOS
  • OSS
  • …more


Shout out


This AMA session is over but you can still ask questions to Mathias Bynens on their Hashnode profile.

Hi Mathias, What, according to you, should every beginner JavaScript programmer know about the V8 Engine?

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.

TC39 has been slowly expanding the standard JavaScript library (thank you!). Do you foresee a day where all the utilities in libraries like Lodash are just part of the built-in library?

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

How Google sees Blockchain? 💵

What is your favourite emoji?

Asking the important questions!

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

Would you rather fight 1 horse-sized duck or 100 duck-sized horses?

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.

The V8 engine is one of the most beautiful pieces of software out there, thanks for making our life easier through it.

I have two questions:

  1. How to get started with compiler design, I've never had the chance to venture into that side of programming.

  2. Do you think JavsScript can be perceived as a compiled language and not an interpreted language? JIT (just-in-time compiler) makes code optimizations (also create compiled versions); interpreted languages can't usually do that.

  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.

What do you see as the biggest challenge in the JavaScript language that isn't addressed by any current proposal?

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!

What are the basic security measures you would take if you were starting a new project in 2018?

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: Hungry for more? Google Gruyere takes it even further:

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:

Have you, as a coder, explored Blockchain technologies? Have you written any smart contracts?

If no, do you intend to invest your time learning and explore more?

Hi Mathias, What measures do you take to improve the performance of your app?

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.

Hi Mathias, do you see web assembly as a threat for V8?

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!

What's the best and worst part about being at Google?

  • 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

Hey Mathias,

Thanks for the AMA. Why is TC39 so slow in adding new JavaScript functionalities?

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.

Which new ECMAScript language proposal are you most excited about? Why?

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.

Hi Mathias, what is your opinion on the Apple's software quality in the last couple years? From time to time I'm getting very angry about bugs and security flaws in macOS. Do you have similar feelings?

How can we get more (non-corp-affiliated) contributors involved in v8 work, and expand the community of owners and reviewers? This seems important both due to the multiple important/popular v8 embedders not owned by Google, and to keep interest and ideas flowing in.

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.

How many genders are out there? 15? 60?

Will TC39 have Observables?

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:

Hi Mathias, Could you explain about the difference between Agnular, typescript, react, node? In total, what is mean stack , or mern stack?

Hi Mathias, Where can a person find the ECMAScript specification explained in a simple manner?

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!

What is your setup?

  • Computer specs
  • Software you use for a regular day

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.

Why did you part away from Opera and what are the key takeaways?

How do you feel about progressive enhancement of web applications concerning JavaScript? Do you think that web apps should have full or mostly-complete functionality when web browsers have their JavaScript turned off? What do you think is a good strategy for progressive enhancement with JavaScript applications? Thanks for the incredible support of new ES features in V8, it proves the web can adapt.

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.

What JS concepts do you think are absolutely necessary for a developer who wants to have his/her expertise in JS?

The cover photo used in this AMA has been taken from this source.