 Hey, folks. So the web benefits from a healthy relationship between browser vendors and web developers. And framework authors and their users are often at the forefront of trying to find a healthy balance between DX and UX. So today we thought we'd bring along a few folks from frameworks, libraries, and their users to have a chat about what a better future could look like. So joining us on the stage, we first of all have Andrew Clark from React. Andrew. Next up, we've got Jason Miller from React. We have Steve Orbel from the Polymer team. Rob Wormald from Angular. Tracy Lee from this.javascript and RxJS. Chatti Tala from Glimmer and Ember. Sean Larkin representing VueJS and Webpack. Malta Ubel, the tech lead of AMP. And finally, Alex Russell from the Chrome team, lover of frameworks. All right, let's sit down. So thank you to everyone that managed to get their questions in today. We have a very special prize for the best question, courtesy of Alex. The very best question today gets a very average Moto G4 phone. That's going to stay over here for now. Awesome. So let's get into it. The very first question that came in was, which features, if any, would make your life as a framework author or user easier if they were added to the JavaScript language or web platform more broadly? Jason, do you want to start us off? Sure. So there's been some stuff going around recently about a proposal called Dom Change List. And I think one of the end games of this spec is basically a way to serialize a set of mutations to the DOM. One of the end results of this would be we can start to run more application code in a web worker. Web workers have existed for a really long time and are strangely underused in our community. So it's a primitive that, whether it's polyfill, they're implemented in browsers. Once we've got some of these things in place, we can start to offload a lot of work off of the main thread and reduce jank on mobile. So that's a huge thing that I'm hopeful for. What do you think it is about web workers that have stopped them from getting as much traction as they could? They're scary. Also, by default, when you construct a worker, you have to give it a URL. And it's pretty easy to get a blob URL for an inline string, but it's not the default behavior. So there's a tasklet API that might be proposed to solve that. That would be another huge feature. A framework shipping could instantiate a worker with some code in it, and that wouldn't be a weird thing. That would be expected. OK, so web workers, Rob on the Angular side did you have any opinions about that? I know that Angular is historically been trying to invest in web workers. Yeah, I would second the DOM changeless API. It would be amazing for us. I think we could put it in tomorrow, and it would be ready to go. So that'd be a big one. And I think observables would be the other big one that we'd like to see. Angular developers, using a ton of that, they seem to really enjoy it. It would be nice to not have to ship that code and not pay for those bytes. And I think it opens up a lot of interesting things on APIs like intersection observer, mutation observer. I look at those and go, those are perfect for the sort of thing we're talking about. So those would be the big two for me. Is there something specific other than having to solve this problem in user lands that shipping observables in a browser would bring? I could probably talk for an hour about that. I think for me that, to me, it's kind of the same thing that we went through from callbacks to promises. When you get a type and you get a thing, you can pass around and treat like a real thing, I feel like we need the same thing for events, right? And that's more or less what an observable is for me, is that get a handle on the thing, be able to pass around, treat like an object. And it really changes how you think about doing complex event things, drag and drop, all these really highfalutin animation stuff we all want to do, this interaction stuff, I think becomes much easier when you have a primitive for handling really what's delivering you. Chad, I was curious. What, from the glimmer and ember side, do you feel is missing? So again, the changeless stuff. We actually have a strawman implementation of this in the glimmer VM. A lot of the work that we're doing on the glimmer side is instead of compiling a template, like how a vast majority of these frameworks authors projects do, what we are trying to do is compile templates directly into a byte code format. And so the changeless proposal is more kind of aligned with that, because the whole idea is that you would build up all of the operations that you need to manipulate the DOM. That's a typed array, you can transfer that across different workers and everything like that and then apply it on the main thread. So yeah, I think the changeless or something like the changeless would be, I think, great. OK, so we've got changeless. I think we have consensus. Can we just ship that now? I think we have consensus. You can do changeless plus worker DOM. There you go. Change list and worker DOM. Alex, do you have any opinions on changeless? No. You're taking bug reports here. Like we're too serious to scribble down that you want them. Tracy, we saw observables were mentioned. I know that in the RXJS community, observables are a big thing there as well. Do you have any takes on, are observables something browser vendors for seriously taking a look at baking in? Yeah, I totally think so. I mean, I know there is the TCF 39 observable spec happening, and hopefully that moves somewhere. And just earlier, Rob was talking about, hopefully, how are you guys going to champion that? I think we made it. We're looking at it. So hopefully that lands soon. Observables in the browser. But I think if we're able to sort of start getting those types of things to happen that are sort of more native, then what's going to happen is, I think, hopefully, the ability for people to use RXJS and the learning curve is a little bit less daunting. Awesome. Malta, so I was curious from the AMP side. Are there other capabilities you feel are missing? So what I would like to say, because I already mentioned workers, for what browser vendors could do is hear us. We all talk about workers. The developer experience in DevTools isn't great yet. So if you could invest in the future and say, maybe in a year people actually use workers, but then have the DevTools already be good, that would be amazing. I also have something, AMP doesn't really need it, but I think everyone kind of wants this, which is just really good weekmaps. So they launched a feature called weekmap. That's not actually what you usually would consider this. So just having a cache that you can put stuff in, and maybe it's still there, but not considered by a garbage collection. If you build something like Relay or even Redux, I think everyone kind of wants this, and it's not been coming. And that's really sad. OK, I saw Alex grinning at this. So Steve, I was curious, do you feel that there are any capabilities missing from the platform that would benefit folks that are writing applications using web components or Polymer? Yeah, I mean, I think I definitely second the JavaScript APIs that are mentioned. And I mean, I'm thinking a little bit more about the DOM here and just say, there's tons of cool stuff that we run into when rendering that I think would be nice to add to the platform, specifically stuff like a lot of the stuff that the native elements can do, that we can't do in custom element land, there's cool stuff that the dialog element can do, that we can't do, render stuff on top of other things, input element, of course, can do, infinities stuff would be awesome to deconstruct that and really add that to our toolkit so that we can use that as developers. And anything from the React side? Yeah, things that the browser can do that frameworks can do, APIs that expose that, I think, are always exciting to us. Our current favorite browser API is Request.oclback. That is, we use that everywhere. That's kind of core to how we're thinking about, basically what our goal is with React right now is, did everyone enjoy that image async feature that you all talked about? What if you could make any component async and just make any of your components stop locking the main thread? So scheduling primitives, like Request.oclback, there's a really cool proposal, I think the what, WG, I always get the different things confused, but there's a really cool proposal called asyncapend, which I think is a very interesting problem space. This basically lets you build up this tree of DOM, whether you're using React or whatever, if you could manually create this, and asynchronously append it into the DOM, you get a promise that says once all of the layout and everything that's been done by the browser. And then once the promise resolves, you can decide when you wanna actually commit that change or actually flush the changes. It's really cool reading that document because it's kind of just a description of what we're trying to do with React as well. But that's the type of thing that React can't do or a framework can't do, unless we reimplement layout, which maybe we will, but realistically for now, we can't do that, so those are the kinds of APIs that we get really excited about. So we saw some convergence on DOM change list. Is asyncapend something that any other frameworks, we think lots of knotting and fingers and Alex is also happy about this, great. Okay, we've got some convergence on this, that's great. Let's move on to another question. So folks are wondering what criteria should you use if you're trying to select a JavaScript, library, or framework to build a new application today? And given that he's just written a blog post about performance budgets, I was curious on Alex's take on this, and then everybody else's. No, read his post. You might get a different answer depending on who you ask today. I work on Chrome, I used to work on frameworks and working on a browser means you represent the user. And so I wind up representing the user's interest in a lot of these conversations. And the way I see people constructing applications today is incredibly well suited to the computers and networks that we were building and using about five years ago, six years ago, right? Networked computers that were had reasonable and good stable latency, fast pipes, copious CPU, relatively small screens compared to the amount that you've had to paint. So that's not the world we live in today. Mobile is much, much, much, much, much, much, much, much, much harder than any of that ever was. The latency on the networks is terrible. The pipes are smaller and variable. And so we've been working with lots of partners for a lot of years and I think the way I would think about this is frameworks take some amount of your headroom. How much headroom do you have is the next obvious question. And I think you have, if you're going to be building a framework-based site, you've got about 130 kilobytes on the wire, jeez it. So when you're selecting a framework, I think one of your primary questions should be how much of that 130K that you need to stuff all of your styles, all of your critical JavaScript, all of your data, all of your markup, templates, application logic, everything has to go in that 130 kilobytes. How much of that is your framework taking? Is a question you should ask. So one thing I was curious, Andrew, about this. You're staring at us now. Yeah, just looking at you. Right next to me. One thing I was curious about from the React site, so we obviously see a lot of applications being started today that are targeted to mobile using React and they're making a bunch of ecosystem choices about using Redux, et cetera. Do you think that folks understand the costs of the ecosystem pieces they're using when it comes to trying to target mobile? And is this an area that need- Do I think people understand this problem? Probably depends who you talk to. One downside, I guess, of the React ecosystem historically relative to the way maybe Ember or Vue, I think Vue does a good job with this, is that we have resisted the frameworks, like I like to put frameworks and libraries in the title, we've resisted the frameworks label for a long time because React was designed to fit into the architecture of Facebook from four years ago, five years ago. So in the beginning, we never built React apps as single-page applications. We were building little tiny views all over a larger server-rendered app. So the first people that built server-rendered applications were way out ahead of us, so we never provide our own router, we never provide our own solution for data fetching. So I think to the extent that people don't care about this enough, maybe in the React big system, I think that's kind of a consequence of that. In the future, I think with things like Create React app and really cool projects like Next.js and Gatsby that are starting to give a more framework-y, holistic approach to how you're supposed to do service workers or server-side rendering, which I think is really exciting, untapped area still, or data fetching or whatever, I think that's gonna be a really exciting and important area in the next year or so. So one thing that you touched on was things like Next.js being a good place to maybe, so you see that as being a good place for us to try defining perhaps well-lit paths for people that are trying to deliver applications on mobile. What was the word you said, well-lit? Well-lit paths. Okay, I don't know what that is. An opinionated path for folks that aren't- Well-lit, is that what you said? Well-lit, yes. Like a cow path, okay, yes. Where are you walking? I respond to animal metaphors. Yeah, I think that we have resisted taking super-strong opinions on things, especially because the infrastructure we use at Facebook is not, we don't really use Webpack even though we think Webpack is really great. So we've resisted giving too many opinions, but what I can see is it's shifting more in that direction. There are a lot of things like server-side rendering, streaming server-side rendering, data fetching of data management, code delivery, like Sam was talking about earlier. There's a lot of these things that are really the same problem space or overlapping problem space that we don't have a great way of pushing our solution or our vision of what that should be because we don't control a framework-y framework. So that's why Next and stuff really excites me in the React space because they are offering a little bit more of this and I think we will maybe start to dip our toe even further than create React up in the future. That's awesome. Jason, so React is in a similar spot with respect to technically being a library. What is your take on this? Yeah, so I'd say if you're making a technology decision about how you are going to structure your applications, if you're picking something important like your view renderer, but what you want to know is, when I'm finished this and I ship my version one, how large is it going to be? If you're picking a library, you probably need to look at what the rest of the options you have are in that library space. So if you're going with React, you need to say, okay, how large is a common router? Do I have a decent selection there for the various CLI tools or server-side rendering tools like Next? What is the end result of those kind of ecosystem approaches? Because at the end of the day, if you end up going with Next, the size of React may not even have that much of an effect on your bundle. It's more the size of Next that you want to be concerned with. And so even if you're not doing server-side rendering or Next or Gatsby or whatever, look at the common CLI tool, look at the boilerplate you're going to use and see if there's a metric you can derive from that. Not just the library. Yeah, cool. Let's switch up topics. Let's talk about interop. So framework interop, web component interop has been an interesting hot topic in the community for a while. Tracy, I was curious, what's your take on this with respect to like, is it important for frameworks to interop together? Like if you've got teams that are working in React and Vue and React, et cetera, is that important as a thing for end developers? I think you look at a lot of large companies who just do JavaScript. So a lot of companies try to say, okay, I'm just gonna go the Ember route. I'm just gonna go the React route. I'm just gonna go this route. But then you have a lot of people who just have sort of disparate teams who try to say, okay, I have this Angular app. What's the, you know, what's this, what's the library I'm gonna build with all these components? And do I stick React in Angular or what do I do there? So I guess it would be nice. I mean, I think it'd be nicer for some developers. And I think that there are a lot of solutions, especially in the corporate world, that people have sort of stuck together. It'd be nice if those were sort of more forward or maybe you guys can come up with solutions to do that or maybe Webpack can solve all the problems right now. Well, since Tracy put you on the spot, Sean, what is your take on framework interop? You know, I think one is the biggest, so okay, I'll speak from experience what we do at Microsoft. So we have over 98 products that ship in production that use Webpack, but no single one is the same. And one of the biggest initiatives that has taken a significant amount of time is trying to unify some sort of component library or system. I think some of the biggest debt that companies struggle with and even one like Microsoft is that we have to be able to move fast, add features, but then as platforms change or features are added or new frameworks crop up, we want to be able to take advantage of these technologies but in a way that can still be agnostic and provide interop between teams. So like, I have my own opinions and I think view is really gonna blaze the trail in terms of how we might see kind of a generic statically analyzed kind of Rosetta Stone for lots of different frameworks to consume components and Jason and I have worked on it a couple of times. So he's already has a loader powered by Webpack that's already taking a view component and importing it into a Preact project and it works. So I mean, there is a huge amount of opportunity space for lots of people to explore. So Jason, I was actually curious. You from the Preact side of view point of you've kind of been interested in web components support. I think that Preact's been doing a decent job of looking at interop. You've also been again working with Sean on ideas around how can we take inspiration from things like the HTML imports approach that libraries that Polymer have really been using and bring into their frameworks. Could you talk a little bit about your opinions on what the future direction of that might look like? Sure. So for me, a part of the part of the win here is we essentially have a compiler model, right? The web is obviously a target we write code for but it's also a target we compile code for, not just with WebAssembly and these types of things but even just compiling to JavaScript. But if we take a look at the way that we're using these compilers and we try to model our input after existing specifications, like if you have a compiler that takes in something that is essentially a serialized web component, an HTML file with JavaScript, CSS, and a template in it, that's an understandable independent layer. You don't need to know how whatever the framework that renders it after compilation works, you could just sort of know how web components works and if the framework adequately implements slots, then if you know how web component slot works, then you know how this file works. I think that Sean had mentioned Rosetta Stone. I think that's a good analogy for this. If we could start to converge at least a little bit on what a component looks like across all of these different technologies, what is the substrate that they're all built on? So we could start to kind of cross-compile between them. You could write a user interface components library with beautiful CSS and encapsulation and some behaviors and then compile it to whatever framework you're currently using and it won't matter. 10 years from now you could compile it to something else. So Steve, I'm curious about your take on this. There's the cross-compilation idea and then there's just having everything work magically at runtime. What is your take on the shape of this problem? Sure, I mean, as you guys probably know, web components are kind of designed to solve this problem. So a little bit that makes me slightly sad that everybody is not just gravitating towards it. On the other hand, I think the technology is evolving. It's taken a long time and I think it's getting there and hopefully we will evolve it still and make it a satisfying answer to this issue. I think one of the places that Polymer has seen a lot of adoption actually is in big corporations where they just have this polyglot of different stuff and they just need a technology that works without wherever the DOM is going to work and this is really where web components shine. And I think this is something where, as now, this is kind of the year of the web components specs being implemented widely. I hope there will be more interest among the other frameworks here. And I think there's, I want to give a shout out to Taylor did in his talk earlier too to the custom elements everywhere that Rob Dodson has done, which is I think that we took a little bit for granted the fact that, hey, we're the platform, everybody's just gonna work with us. And I think it's like to a lot of different approaches, this is sort of a scary concept that now an element in the platform can be anything, it can be whatever. And I think this is partly incredibly powerful because it's sort of this democratic process of the cream of the crop can rise. And, but at the same time, it's also like, but I think it could do anything, it's kind of scary, do I really want to use that? And this is where I think the approach between custom elements everywhere is really interesting because it kind of is this idea that the framework authors and the community of developers making these custom elements really have to meet in the middle and establish best practices such that it makes sense to use these things all together and we can all benefit. So hopefully that happens. Rob, so Angular has been investing in trying to improve their interop with custom elements and components in general for the last while. What's your take on this? So I kind of feel like the Rosetta zone that Sean was talking about, I think that's what a custom element is. I think that that is, and I don't think this group of people would agree on many things, right? Completely against the group, but I do think that we've all more or less landed on this idea that there are events and there are props or property, whatever you wanna call them, right? We all have kind of an API that if you squint, it's more or less the same. So to maybe make your year a little bit better, today a little bit better, I can say that our team has decided that we've always consumed web components. That was a day one decision in Angular. I talked to enough big companies, I'm sure companies that Palmer in, that have these very disparate ecosystems have a dozen different frameworks. I think it's very sad as a web developer that everybody has to rewrite the date picker in every framework that exists, right? If I do one thing as somebody who works on the web now, we can just write one date picker that's awesome and then use it everywhere. I'll just quit, right? So from our perspective, Angular is a framework, as you said, we do try to solve a lot of these problems. And so for us, I think our bread and butter is these big applications that everybody likes to build, but for me it would be great if Angular components could be spit out as web components, right? It's a thing that you look at and it's a no brainer. And so six weeks ago, we started really looking into this. I've been complaining about it for 18 months. I said to Alex Russell when I joined Google that we're gonna make this happen and finally it's happening. So you'll be able to write an Angular component and spit it out as a custom element. And I think that the most important thing about that, the kind of crux to all of this custom element stuff, is that nobody has to know anything about how the component was implemented to make it work because everybody in this room already knows how the DOM works, right? And if that becomes the common API we'll talk to, it doesn't really matter what happens inside of the component, right? We can all have this Rosetta Stone, and we can all talk and we can write one date picker and everybody can be happy, right? So on that note, it sounds like there's some interesting convergence on the Rosetta Stone idea. I'm curious from the React perspective, what's React's take on web components? Yes, we have a slightly different take. Web components are really cool. I think they definitely solve the encapsulation problem and they solve the consumption problem where you should be able to consume a component. You shouldn't have to learn 15 different ways to consume a component. And surely you can wrap any React app in a web component. It's not that hard. The question is whether or not we should replace like React components as a primitive for building your application with just writing a bunch of web components. And on that note, we're not as convinced because we use, I could be wrong, but I think another selling point for web components is that perhaps it obviates the need for a virtual DOM or for us to have to manage our own like parallel and memory representations of your view. And on that part, web components don't solve that for us. So, because we use our internal instances not just for encapsulation, but we use it for memoization. We use it for computing changes. We use it for scheduling. That's the big one. I don't know if you all have heard of this recent effort we had to rewrite React, but we're moving in a direction with React 16 and going forward where we're gonna have async by default rendering. And what this means is we need to be able to do, well, we're gonna do all of our rendering work inside of request.oclback basically. And in order to do that, you need like this double pass kind of rendering system where you have two phases. One you have async render phase where you do most of your expensive work. It's all in request.oclback or maybe in the future it's on a web worker or whatever. And then you have a synchronization phase where once you can compute all of your mutations into a DOM changeless maybe, you can synchronously flush all of them all at once. And that's the type of architecture which we're really excited about. There's a lot of cool features that you can build on top of this, but it's not really possible without implementing your own data structures. So we're like thumbs up on web components, but we don't think it replaces the need to have our own data structures. Alex, do you have any takes on this? Yeah, I mean, so full disclosure. Demetri Klaskov, Alex Comeroskin, I started the project at Google that sort of started the web components effort. We're sorry. Apologize, catch me later, buy you a beer. I don't think web components actually have any bearing on whether or not you should have a virtual DOM. Virtual DOM becomes an implementation detail about how your component decides to handle getters, setters, attribute setting and all the stuff. Web components as an implementation give you a surface area that everybody knows, as Rob said, so you can just reuse the date picker from wherever. And then how you wanna handle that question about how a state gets handled inside of your component is now up to you. It doesn't do any global coordination. So I think this is one of these places where web components disaggregate a bunch of things that frameworks used to do. Frameworks have traditionally taken a bunch of different responsibilities between ensuring compatibility across the DOM, giving you a component model in the first place, making sure that those component updates are coordinated in various places, doing data distribution and event handling. And web components sort of disentangle a couple of those and leave you with a few of those problems. They don't solve everything. So a few of those still have to happen. And it's interesting to see how the various frameworks have sort of reorienting themselves now that web components are kind of a thing. So yeah, I think I've seen lots of people, Skate.js is doing this great work where they're using virtual DOM inside of custom elements, which is super cool. They may be using Preact internally, which is not removing a virtual DOM, but it does leave that global coordination question open. Cool, and sorry, I was just gonna say just a sentence on the interrupt thing, just to go back a little bit. I'm gonna sound like a broken record, but the thing that we've found that's interesting about interrupt is this coordination problem. At Facebook, we use React everywhere, but the other framework that we use is server-side rendering. And if you think about it, we have this system called BigPipe. The thing about both of these are asynchronous systems and it becomes a really interesting problem, how to coordinate two asynchronous renderers so that things are popping in on the screen at different times. Okay, and circling back to Malta, AMP is one of the largest consumers of custom elements. I'm kind of curious on your take about interrupt. So I just had this conversation with the product manager saying, hey, we did a date picker in AMP, and I'm like, oh my God, not again. But what we ended up doing was taking the Airbnb React date picker, using it with Preact, so it's not actually like 60 kilobytes and putting it in the custom element, and because it works fine, like AMP does Airbnb date picker. And that is like, I'm worried or worried about the people who put all these massive frameworks in these little encapsulated things. I think we need to understand that just because something is great on the interrupt level and we don't have to make a new date picker, doesn't mean we don't need an implication framework. Now, on the other hand, like AMP right now doesn't actually allow you to write code in any other framework, so interrupt is a bit awkward, but I think what our goal is in the long term that you could just use React to render this stuff that you want to change in AMP document at runtime, like I think the current state is not what we want this to be. That's just the thing we could implement in fall 2015. Nice. Switching gears up a bit, we are running a little bit over, but we're just going to take one or two final questions. What impact is WebAssembly going to have, if any, on JavaScript frameworks and libraries? Chad, do you have any takes on this? So I think WebAssembly is kind of interesting. There are certain things, I really like to talk today, basically. It's not a replacement for JavaScript, but there's in places where you need the performance, I think it will play a larger part. Maybe not everyday developers writing it, but framework authors may opt into writing a little bit of C code to maybe eke out a little bit of more performance. This is like some things that we're experimenting with, with glimmers in very high critical performance scenarios, we want to try to eke out as much as possible. Eke out enough performance as possible. Awesome. Jason, did you have any other takes on WebAssembly? Just something that came, I'm like a total WebAssembly new, but something that came up over lunch, you laugh, that's true. I know the API, it's about it. Also, I wouldn't trust myself to write native code. One interesting area that I touched on was for something like a polyfill for a really performance critical feature, having the ability to write at least parts of the polyfill in WebAssembly could be really compelling. We were talking about DOM change list if there's diff computations or something that needs to happen in there or the creation of that array buffer. If that's better done in C and WebAssembly's available, why wouldn't you do it? It seems like it could be powerful there. So our final question is not strictly going to do with APIs, but we had a question around, what can we as a group do to improve diversity in open source? Which I think is a really important topic and something that I personally love to see us make some traction on. Tracy, I was interested in your take on this. I think there's a lot of really great programs out, like I'm a Google developer group organizer and there's a women tech makers initiative that happens. And it's a really great way to sort of bring women developers together and give them a safe space to learn. I think if you talk to women across, women and just everybody in general, but I focus on women because I'm a female. If you talk to women in general, everybody has varying ideas of acceptance and inclusion and what it should be and what it shouldn't be. So I think not really forcing your opinions on women, but just giving them a way for them to contribute the way they want to. I think it's just also encouragement in general. I think in our industry, we have this diversity problem and a lot of companies are looking for these senior developers where when you actually look at our industry, you see a lot of junior female developers coming in. And what we need to do is sort of somehow figure out a way that we're able to encourage these junior developers so that we can build senior developers. And I think that's the biggest problem right now. That's the biggest disconnect we have. I agree with that, Sean. You also, this is a problem that you have some thoughts on. Yeah, I mean, like if it wasn't for open source, I wouldn't be here. I'd still be like in tech support or, you know, like just to, you know, doing whatever. And so it's like, and thanks to, you know, a little bit of my privilege, why does this have to be a unique story for just, you know, myself? Like we should be able to not only elevate the opportunities for every single person to be able to receive the same blessings that many of us have just by being involved and passionate about something. And so one of the things that we're, you know, that we've seen is that we have specific outreaches for Webpack, not only that span gender or race, but even just countries. Like we have an initiative called Webpack Africa that we're starting and a gentleman named Prosper, if you haven't met him, raise your hand maybe. He's back there somewhere. He's helping lead that organization and their goal was we need to prepare people for the web for the next billion people. And so it's like, that means that we could have the opportunity to elevate somebody to a whole new life opportunity for the next million contributions or developers. And so like we want to find as many ways possible to essentially elevate or provide more opportunity so that these success stories don't have to be unique. They don't have to be rare. On that note, we're out of time. Please join me in giving a hand to all of our panelists who are very kind enough to take time out to come here today.