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!

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.

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

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.

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

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

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: https://amphtml.wordpress.com/2018/01/09/improving-urls-for-amp-pages/ 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.

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

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.

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.