Standards bodies have historically been "exclusive" for all the wrong reasons -- mostly to do with anti-trust law and intellectual property licensing. Part of my work on Chrome has been to lead our standards efforts over the past few years (along with Chris Wilson and Shruthi Sreekanta), and as part of that we've been intently focused on moving design work out of standards committees.

A bug in our collective understanding of standards is that progress "comes from" the W3C or IETF or ECMA ("Standards Development Organizations", or "SDOs"). It's pretty much the opposite: those organizations function as amplifiers. Committees they host might round off sharp edges of existing designs, but it's the participants (from companies or organisations with successful products) that bring the designs and do the design work -- and most of that design work happens outside of the committee.

If it was just a simple misunderstanding, that'd be one thing, but the persistent misconception about where progress comes from creates some large, related problems:

• Once people begin to think that progress happens in committee, people do try to do design work there (ugghhhhh), and sometimes the legitimate political pressure to "become standards compliant" even leads products to implement bad designs
• Because of the legal concerns that give rise to SDOs, the participants in committees are often the wrong group to do design...often wildly so

So the key insight is that we need to separate standardizing an existing solution from designing a new solution to a problem.

This has led to similar processes being put in place across the various forums where we do work. At TC39, this is the Stages process. At W3C/WHATWG, we're now using the Web Incubation Community Group to do design in the open. We're also looking to do design-via-incubation in all the other standards fora we participate in. A common feature amongst these processes is that they're much lighter weight. Anyone (roughly) can participate, and I'd encourage you to check out the various WICG proposals to get involved. That's not an answer about how to get involved at W3C/TC39, but hopefully it answers a related question: "how can I make a difference in the future of the web's evolution without working at Google/Apple/MSFT/etc.?"

There's a last consideration that this brings up: standards work takes money. Even if it's just time, that still takes money, but often it's more than that: travel, SDO membership fees, etc. Travel is frequently necessary for design work, even if it happens in a lighter-weight incubation forum. I don't have any great answers here. Face-to-face time is important. It does yield higher-bandwidth collaboration, and that does mean that folks who can afford to travel to do this work have an advantage. It isn't possible to level this playing field entirely, but I can say that here on the Chrome Standards Team we're aware of the problem. Our best solution thus far has been a willingness to use Google's considerable resources to travel and host meetings closer to those who can't do so as easily.

I care deeply about inclusion in the Standards process, so if you've got other ideas about how we can do better here, I'd love to hear them. Please don't hesitate to reach out. My DMs are open!

Hard to chose! On desktop I love what Opera Neon was exploring for navigation. Haven't used Brave much, but I'm glad they ditched Electron for something more secure; blocking tracking content and replacing it with an alternative way to monetize seems like a good step forward (although I'm not sure about their mechanism).

On mobile, Samsung Internet has been pushing a bunch of things forward that I really love (desktop PWAs via DeX, e.g.).

I know, and respect, many of the authors. As a W3C TAG member, I helped write our Distributed and Syndicated Content Finding (see also the blog post), so some of the points raised there are things I care a great deal about.

Specifically, I think it's important for federation not to break origins and URLs. Apple and Facebook do this implicitly with their news products, which stinks. AMP has too, but they've stayed cloer to the web. I'm hugely excited to see their commitment to the emerging Web Packaging spec to heal the URL problem: amphtml.wordpress.com/2018/01/09/improving-urls-f…

I'm also excited by the changes that Search announced regarding page speed as a ranking signal

Taken together, I think those get us a lot closer to the world we want to be in: faster first-party content delivering better experiences to users.

This is starting to change. The support lines for our more recent hardware offerings are pretty good (we had cause to use them for Frances' Pixel having issues).

Historically, I'd say "optimism". The hope has been that we can learn at scale what problems people have and their solutions, automating answers along the way. Even if it didn't pan out 100%, I still like the dream; talking to another human in a support capacity (and thereby imposing myself and my needs on them) is pretty much my least favourite thing.

Yep! You can drag tabs between windows. For windows with only one tab, create a second, and you'll be able to rip off the first and place it wherever you like. I know folks that have keystrokes set up for this (with extensions, I think?), but I don't do it often enough to bother (or have learned them).

The fact that it's everywhere. As a language, it definitely needs improvement. That's perhaps the odd thing about TC39 members: you don't deal with that sort of pain unless there's something you really think is broken.

Understanding of systems, networks, and CS basics. Beyond that, we're a technology company. Getting things done means writing code and collaborating in big teams. So being able to write good code, take feedback well, and work with others to improve theirs (without being a tool about it) matters a great deal.

Multithreading isn't ever really about the language, it's about the libraries. For JS, that's DOM. SharedArrayBuffer + atomics get us mutable shared memory for some applications, but that doesn't make the rest of the DOM or object model instantly threadable.

It does, however, open up threading as part of our design language. For instance, a few years back, we had a big design argument about some details of Web Audio. There was an incidental part of the design that happened to expose mutable shared memory between threads. Because JS had no way to "explain" that, it had to go. Now that we have SAB (once Spectre mitigations are in place, that is), we'll be able to address those lower-latency use-cases in a coherent way. That's pretty exciting, particularly for VR and AR which need peak performance.

My superlative utterance? "Counterfactual", indubitably.

There aren't many sigil's left, so spending one on this has a high hurdle to clear.

As usual, I'd like to see what larger code samples using this (and competing syntax) would look like. When we designed various Class features, stretching the feature's legs with transpilers taught us a lot about which tradeoffs felt good in the long run.

I feel some guilt about the current state of affairs. A team I led ("Parkour") built an early (the first?) ES.next -> ES.now transpiler -- "Traceur" -- in the ES6 timeframe...so to some extent, we started this fire.

And it is on fire. I see so many traces where the combination of Babel transpilation overhead and poor WebPack foo totally sink the performance of a site.

I'm happy that babel-present-env is now the norm, but I'm sad that we're still playing this game. To some degree I think it would be prudent for most developers to make a hard cut: only support browsers that support ES6 natively and give other users the progressively-enhanced experience (which you were doing, right?). Transpilers should fade away, not get more central to our workflows.

I less kind thoughts for proprietary, non-standards-track forks of HTML and JS (e.g., JSX), but will keep them to myself = )

Apple staffs the WebKit team at a much lower level than other browser engine teams (which is not a critique of the engineers on the team; to a person they're brilliant!) It has gotten so bad that we're starting to re-invest in fixing some of the worst compatibility issues in WebKit...which, as you can imagine, is not where we'd like to be spending our limited resources.

It's hard to say what the intent is, but the effect of Apple's decisions haven't been great for us as a community.

Taking that in reverse order, my advice is to learn the basics. Build some stuff without frameworks or libraries and get in touch with the platform below you. That background will always be valuable. It'll let you weigh frameworks and tradeoffs much more effectively, and will allow you to "punch out" when you realize you need to.

I'm excited that Web Components are (finally!) bringing web development up the stack a bit. There's going to be a fascinating world of interop and modern-assumption-only web development in the next few years. Rob Dodson's Web Components Everywhere gives you a flavour for that

IDK, I mean, we're human. So maybe don't treat fellow humans badly and it'll all be cool?

Nothing about my journey through life has been "efficient"...but I honestly have no idea how I'd have gotten where I am if I hadn't done the same set of things I've done.

I can pretty easily reflect on places where I'd wish I'd learned faster, but that's perhaps different.

In terms of big perspective shifts, I think the questioning I did in my mid-20's (anchored on the question "is what I do for a living good?") could have been done earlier. I left religion, along with many other beliefs, as a result of pulling on that thread and I think I could have done that in my late teens instead. It would have saved me (and a lot of other people) a lot of pain.

Program what? And who's giving out "programmer" badges? There's tons of stuff I can't program and there are many reasons, but they mostly come down to motivation and opportunity.

In general, it won't. WASM is likely to open up use-cases that weren't possible on the web before, however (CAD, some games use-cases, scientific computing, etc.).

I manage my time by acknowledging that I only get 8-10 hours to work in a day. My younger self worked constantly and it was a terrible idea. I did worse work, slowly, and had less impact because I didn't give myself the constraints that gave me perspective. Setting hard limits on work time is something Frances Berriman taught me, and I'm forever grateful for it.

To the extent that I'm successful, it has been luck and perseverance (in that order). Anyone who is even moderately successful and thinks "hard work" got them there is delusional. Nearly everyone works hard...it doesn't distinguish you. What distinguishes you is random chance falling your way. In my case that was parents who had computers & were supportive; also being born white, male, middle-class, and in a family that valued education. Yes, it's important to take the chances you get, but in general I view "how to succeed" stories and advice through the lens of survivorship bias -- and from there, it mostly looks like bunk.

The things I helped develop that contribute most meaningfully to my workflow on the web...um, probably ES6 Classes, Promises, async/await, and Custom Elements.

I'm one of the few people at Google I know who doesn't have a degree of any kind, and for a lot of years that was hard.

One of the things I've come to value over the years is the ability to pierce abstractions (in both directions). The best engineers make the smallest cuts for the biggest impact, and they can do that because they can "see" more of the system. I'm not sure you need a degree (I'm proof that Google hires folks without them), but you do need to be able to wrangle with complexity above and below your "layer". Living your whole career in JavaScript or Java without ever diving down to the layers below will be limiting no matter where you chose to work.

Tried to answer parts of this in another question, but it varies quite a lot -- but safe to say that if I'm at work, I'm in a meeting. Early meetings from home, then commute, then more meetings, then hopefully some make-time (but mostly meetings), and finally commute home by 6 or 6:30.

These days, most of my creative work happens in design documents, github design reviews. That said, there's nothing I like better than a day I can "steal" to go try a new approach, scratch a code itch, or help a partner improve the performance of their site.

100 duck-sized horses, for sure. I probably wouldn't beat them all, but at least I'd be able to get partial credit.