 I'm going to introduce the panel while they're getting settled and everything, but come on out. Darren Fisher, VP of Engineering for Chrome. And by the way, some of these may or may not be true. Probably most of them are true. But Parisa Tabriz, her business card reads Security Princess, which I am most jealous of. By the way, I always have been. Grace Kloba, lead of the mobile browsing team. Tautran, my co-presenter from this morning, fellow cocktail aficionado and head of global product partnerships for the web. We are both looking forward to the nitro cocktail system, by the way, by this point. Tal Oppenheimer, product manager on Chrome for Android, who makes sure Chrome and web works well around the world. Matt McNulty, who leads the developer experience team for Chrome, has had to field complaints about me spilling coffee on one of his reports already today. Alex Kamarovsky, who is one of my two favorite Alexes. And they're actually not interchangeable, see if I say that for Alex Russell or not. But Alex Kamarovsky is the group product manager for the web platform team in Chrome. And finally, Alex Russell, also one of my two favorite Alexes. This one's an engineer in the Chrome team. And he and I actually have shared this enduring mission in making the web a first class platform. We're super excited about where we are today. We worked together longer than we've both been at Google, which is actually saying something, because I think we both feel like we've been at Google longer than average, at the very least at this point. And we first met when I worked on the Internet Explorer team, and he was working on Dojo Toolkit. And he kept asking me really pointed hard questions. But he was always like, you were always so nice about me asking you hard questions. And I was like, so were you about asking them in a nice way. I had to give some credit for that. So we are using Slido for the questions. And I won't promise to take all the questions in order. But if you think of things, whatever, file them there. We actually are live moderating them during the panel. And we may pick them up and ask them. So let's go to Slido. And like I said, I won't promise to take these in order. In fact, I actually want to start with a different question, which is, where can I get the dino sweater that Mariko is wearing? And so I kind of want Mariko to answer that question, if she's OK. The answer is, you can. It's my hunnit. Not only the sweater, I also have a beanie. And the all-her- Which I gifted to Alex Paso last Christmas. Thank you for bringing this out. And they're, oh, fine. You get to put it on now, of course. So if you want to get this, I do have a pattern if you want to knit it by yourself. And also, I gave one extra one to one of the Chrome engineers. So you should talk to engineers and find out who has one and be nice to them and get one of them. OK, so I have to credit the number of votes for this question. So I think we're going to start with, does Google see AMP as a long-term solution or a temporary patch for the web's performance problems? Is the goal a fast web regardless of implementation or is the goal AMP? Anyone? Well, we don't have the AMP team here to speak to this, but I think we can sort of talk about how we've sort of, we've been working with the AMP team a lot on AMP. And for sure, we share the goal of making the web work a lot better, especially the mobile web. And performance is absolutely a big part of the motivation for AMP. The way I look at it is that the second part of the question there is the goal of fast web. Absolutely, the goal is a fast web. And AMP is definitely an enabler there. We've seen people have a lot of success at building fast experiences. And again, I think this point was made today a couple of times, at least, that AMP is really a built-with-web component that's built with web technologies. It's in many ways giving people a lot of guidance on how to create a really fast experience. But there's nothing that keeps you from creating a great experience without AMP as well. And I think you've seen a lot of content today. And you'll see more tomorrow that can help you do that. And I want to weigh in here. And the long-term solution is a fast web. That's really what the long-term solution is going to be. And when we talk to a lot of developers and partners, it's really about making sure that your performance is great, making sure that you're taking care of the overall user experience. And if folks want to use AMP, if they want to hand-tune their own site, I think it's really up to them. And I think we really want to just make sure that we provide the right set of tools and features and give developers and partners a lot of options. Cool. Let's go to the next question. Why was there not a PWA summit this year? An interesting one. I mean, we do this. Who was supposed to plan it? Chris, is that you? I forget. Chris. Oh, no, I'm not a panelist. Come on, man. I just asked a question. I mean, I think really, because I am in the developer relations team, this is a conscious choice that it's not just about PWAs. And like we talked about in our talk this morning, this is really just the modern web. And PWAs are kind of just a way of capturing that at a point. And the whole focus on installability, it's super important for users to have a quick entry. But the web is more than that, too. And what you need to do, I think, is probably more than that. And I think of it the same way as the thing of Ajax back in the day, a responsible web design. And at a certain, at the beginning, it's like, oh, it's a thing that means something. And over time, it just becomes, well, duh. I feel like we're starting to get to that point, which is really cool to see. OK. Next. How is it taking a second to update? Sorry, new tool that we're trying this year. Is it a PWA? It actually ranks really highly in Lighthouse, but not a progressive web app. We are going to fix that, though, so it's fine. All right. Is it missing a manifest or a service worker not running on HTC? Manifest, manifest. We don't need to debug it on Steam. We can run Lighthouse on it if we see. You know, it's not that hard to create a manifest. I understand this. I'm not going to create them personally for everyone. Tried to make it easy for people. I did point out as moderator before the panel that I don't actually report in the same org, so none of these people can get me fired. And someone on the panel said, well, not directly. So anyhow. Next question. In August, Mozilla and Facebook submitted a JavaScript binary AST proposal to ECMA TC39, reducing JS parse times by 70% to 90%. Is the Chrome team interested in supporting a binary AST? So I guess I'll take this one. So we work very closely with the performance team at Facebook who have done an incredible job at telling us what we do wrong, which has been really outstanding, and helping us find places to improve. Binary AST is one way to maybe cut down on the initial parse time of loading large JavaScript applications, which of course Facebook is one of. There are other ways that we can improve the loading times for applications that people use a lot, like putting the code that they're using frequently inside the service worker cache. We've seen large gains from that already, and we're very excited about being more aggressive about that. The binary AST proposal has a lot of long-term consequences, not all of which we think we understand entirely, and so we're trying to figure out the right way to think about improving parse time. We're not sure that that's it, but we are interested in improving our performance in that area. But yeah, service worker cache, your JavaScript. Do that. All right, these are bouncing around a little. All right. Well, let's ask another fun one. So add to home screen in progressive web apps. It's been great for creating native-like user experiences. When can we expect to have this functionality on desktop operating systems? I think we actually had Owen spoke earlier today about this. So this is something that actually you can do. You've been able to do it for a while. You can, it's kind of buried, but you can add an icon to a site on your home screen around your desktop, I guess it's called, desktop. And to be honest, it's one of the things, it's cool about PWAs is that in general, if you built these things in a responsive way, they just kind of work on desktop. But it's not as clear about like what exactly the user mental model should be in that context. On mobile, it's just, it launches full screen. It just sort of takes over the whole app. But as Owen announced earlier today in one of the talks, this is an area that we're actively investing in and we're hoping to bring something that will target the space the next end month. I don't know. I think it's going to be a little bit of a burden for it in Chrome flags. Yeah. So what would you recommend using nowadays, sorry, would you recommend nowadays using ES6 directly or transpiling to ES5? Who are your users? I mean if you've got an entirely ES6-compatible user base, please by all means, it'll save you bytes on the wire. It'll save you a lot of hassle, especially if you're using web components Custom Elements V1 does integrate with the native class syntax and it's difficult to do that otherwise. Otherwise, you know, transpile. Look at your user base. In 2013, the Chrome team forked WebKit to build the Blink engine. Chrome now has a ton of nifty features not available on Safari, but developers hesitate to adopt those features because they don't work in Safari. How would today's web developers be better and worse off without the Blink fork? Wow. That's a really interesting one, huh? I really haven't thought, I guess, about the kind of factual what would have happened. And I want to hear better and worse, by the way, because I think I can think of both. Stick to the chat. I'm sure you can. One thing I will say is I'm very proud of the way the Blink community has sort of evolved over the years. We had our most recent Blink on in Tokyo just a few weeks ago and it was huge. We had a ton of people there. We were maxing out the space. And so it's been really cool to see lots of other companies come in and participate and build off of Chromium and participate in Blink as well. I think ultimately we have goals of really pushing the web as far as we can and as quickly as we can and working with other browser vendors and specification bodies to decide how to build these things. And it's allowed us, I think, to move differently than maybe it would have been had we still been sharing a code base, per se. But I'm not sure, I don't know. I mean, one of the things you get out of competition is competition. That's something that we value heavily. And one of the things that's difficult about sharing an open source code base is that in order to get code landed, everyone has to agree through a single governance system what should land. Having separate code bases lets us take a different view of what's most important and we compete on different axes. And it's easier for us to compete with the Safari team in a more full on way which benefits everyone. So when we may go deliver features that improve performance in one aspect, they'll work on features that improve performance in another. And then we have to go figure out which is most important. And that is a great outcome, I think. One extra, okay, sorry. I was gonna say that one of the things that you might think is worse is that you might think that because there's two that there's gonna be more incompatibilities between the two. Well, one of the things that informed our decision to fork in the first place was that we realized we were actually already forked. We if deft the heck out of WebKit and we were shipping features that Apple didn't feel comfortable shipping it because of this very idea that we actually wanted to really push and try to bring some nifty features to developers, we already were shipping things they weren't shipping. And so it's kind of like we recognize what reality was and we realized we should just optimize for that reality. And so that's really where we were at that point in time. We thought, yes, we should just fork. One thing that I think is worse is we talk a lot of these kinds of events about the big flashing new features that you can use as developers, but in our day-to-day lives, a lot of it is what random little edge cases work differently in different browsers. And when we used to be part of one code base, one change there where work make that behavior of those sort of edge cases similar across to different browsers. And so actually we invest quite a bit in this. We don't just invest in the cool flashy features that we can talk about on stage here. We also have a bunch of folks we call this a predictability effort that focus on cross browser testing through web platform tests. And we also have folks that land changes to other open source rendering engines to help fix some of those low like those issues that cause a lot of annoyance day-to-day. And that's one thing that requires active effort now that didn't back, wouldn't have if we hadn't gone in separate ways. I think on the same vein, there's a question about if there's an interest in having team, several teams of very smart people who work on several rendering engines at the same time, like should we just cross pollinate between those browsers or should we just build one single browser that everyone ends up using the engine from? Should we have one JavaScript engine, right? I mean, as a former web developer, I can say with confidence that hell is other browsers, right, like it's very much the case that your favorite browser is your favorite browser and compatibility with anything else sucks, right? It's just always going to be hard to get that. And that's one of the unfortunate aspects of competition. But the benefit is that it means that there isn't a monoculture. If one browser engine starts to get stagnant and they don't continue to lead, then it's possible for someone else to come in and do a better job. And that's a huge and valuable thing that we've seen play out multiple times as long as I've been working on the web. Chris, you might have some insight into that. No comment. But in seriousness, I have actually a sociological background and a lot of times we miss this, but this is one of the few examples where you have competitors who are also sort of cooperating. They're working together on standards or shipping, things are mostly interoperable and they can compete on which features to offer and how to implement them. And that kind of competition while still being interoperable is pretty special about the web. And I think it's pretty fundamental. I also want to add one point. It's like with multiple kind of vendors working on it, it's increasing diversity. It's like a group, different people having different opinions. What is the more important versus a single voice? And some of the work going on in Keco right now is really interesting. A lot of really interesting approaches and layout that it's just great to see different engines in different aspects. So, sorry, just lost a question here. So I think there's a lot of questions that sort of center around this topic of Google seems to have somewhat of an identity crisis. On the one hand, there's a large push for progressive web apps in emerging markets. And on the other hand, there's things like instant apps. Why does Google continue to march forward with Android rather than doubling down when the core business is inherently web-based? And I'm totally throwing them under the bus on this one. Anybody here from the Android team want to talk about it? Aw. I think you can transition from just the point of competition to some extent and recognizing there's different needs and developers want different things. And that's actually not necessarily a bad thing. And you don't want to say like this is the only way and we're only gonna do this. I think I sympathize with the point of hearing kind of a lot of different options for how to create content. And that may be not having like a holistic narrative. But I also think that one of Google's strengths is actually not just sticking to one thing and like continuing to invest in what makes sense for this environment and seeding like new ideas. I think meeting developers where they are. I know Tal, you've talked a lot about this when you reach out to developers. Yeah, I was gonna say as well the question itself somewhat answered parts of it. It highlighted that progressive web apps do resonate particularly well in various countries that have different constraints. And so the reality is is that different technologies can work better depending on who your users are and who you're targeting and whether you're really aiming to have a lot of users from a lot of different areas or if you're really focused in on one particular set of users and how do you best match those. And so some technologies of progressive web apps work really well for those and other aspects that Android and native provides works better for other use cases. Obviously, we're gonna trump it. Yeah. Awesome benefits of progressive web apps but I also think it's not a bad thing for like the world to have options. Yeah, and I mean the user's experience is surrounded by stuff too, right? Like Chrome OS I've always thought was awesome because it's really just the web but it does have a user experience and users get used to those consistent ways of interacting with their system and they're different when you change different devices. So I'm gonna have to go with my friend Jason Grigsby's question of why does Google highlight AMP in search results instead of progressive web apps? When will Google search have ambient banjing for PDA? Or for PWA? Never for PDA. Never for PDA. Never again. And keeping in mind, because I'm on a channel, Darren, he's sitting right next to me. The search team isn't here, so. We can say anything? We can say anything. Yeah, like whatever you say, I think they have to do, right? That's how this works. I think if you get more, if you get 76 votes, then we must legally do it, I think is what happens for it, 75 votes. I'm gonna watch that number roll up as you say this. I'm pretty sure Parisa's pillow is a spokesperson for the search team, right? What? You don't want a panel of Chrome managers to be answering this question? Because we have no idea. I don't know if there's anything for us to say. But if you think about it, so when we talk about Progressive of Us, we talk about building best in class, building really great mobile web experiences, right? And what is Search really great at doing? It's helping you find great web experiences. And so Search already points you to PWAs, already points you to websites. So, and Search is very motivated to help you find the best sites, right? And we're motivated to help you build the best sites. So I feel like there's a lot of alignment there. And we talk about PWAs, we're not so much saying it's a different thing, it's the mobile web. It's the mobile web sites built well. And that's what we're here to try to help you accomplish. Okay, so on a similar vein though, what's up with Google launching so many Chrome-only sites? What's up with that? What's up with that? We shouldn't be doing that. Are we doing? There was one last week I saw that was bouncing around on Twitter that we actually, every time we see one of those, we dive in like, oh crap, let me chase down the CL internally that led to it, reach out to the teams. I tried to catch them beforehand, obviously. I think this one was actually a, it was someone using a very old version of Firefox. Or it was Firefox on Linux, which was incorrectly blacklisted. And ultimately, we try to make the case for lots of other teams, a very large company about the benefits of progressive enhancement where possible, allowing developer or users to access those sites, even if they aren't fully sure it's tested. But. And to be clear, we, I mean, everyone up here on this stage, generally really, really dislikes it when a Google property does this. So we're some of the people that actually object the most to it. And in fact, the whole concept around progressive enhancement is really twofold. One is, you know, there's a path forward for a developer to create an experience that can brace new features when it's available. And that allows them to create an experiment with new APIs and create experiences that are better for that set of users who happen to have the browser with those features. But it also tells developers of the other browsers that haven't implemented those features that that's actually a feature worth building because like developers want to use it. So it's all really works well when you kind of go down that progressive enhancement path. And in general, you know, when it's possible to do that, that's where I think with Google, that's mostly where the focus is. I think there's been just a few incidents recently where people have that motivate this question. And like we were saying, the last one was actually kind of a bug. Because it, anyways, I should probably stop talking, but... There are ways to do this better than not. So for instance, you could give users a link to let them continue to try it anyway. There are ways to communicate that you're expanding your browser support in the future. There are ways to, you know, say, hey, here's why. And those are things that we're advocating for internally. So come to us, you know, we'll advocate to the other teams on your behalf. That's a service we provide. Absolutely. And I will say, I don't think the Chrome team has ever made any Chrome-only web services. At least not every... Well, let's not open that can. Yeah. But definitely treat the Chrome team as your helpers in this. There's a lot of discussion around offline capabilities. I actually chose this question because this is one that I've thought about too. You know, that's great to have offline capabilities, but how much storage can a web page really respectfully expect to have locally? Like, there's likely an expectation from the user that you're not gonna take a huge amount of space, store a bunch of stuff on their phone. How does this work when you have media apps like the ones we were talking about this morning? So we've changed this a lot recently. For the better. Yeah. Well, depends on who you are. We think that because it's not... The contract we give about developers isn't the same as a native app gets, right? A native app gets as much storage as is available on the disk without a lot of limits up until the OS says you're cut off. We are the ones cutting sites off. So we impose tighter limits. Historically, they've been very, very low. I think the number that's still kicking around in some people's mind is 50 megabytes or five megabytes. Those are pathologically low limits if you're trying to build anything serious. And so instead we've shifted our implementation to look at the amount of total free space on the device and we've expanded the amount that Chrome is allowed to take quite a lot because you might be using Chrome as the primary reason that you're on the device. So it's sort of comical that we would only take 15% of the total space. We've fixed that. So now you'll see quite a bit more space available if you use the quota APIs to interrogate it. But we also are trying to ensure that the sites that you engage most heavily with are the things that are kept or the things that you have more storage space allocated for. So think of it like a big pool and we'll throw the things out that you don't use frequently. So if your site engagement score is high, you're much less likely to get evicted. But the amount of space that a site gets is now largely unlimited. And this is one of the places where the web has an amazing ephemeral model where users don't have to be afraid to tap any link to go somewhere and that's huge, it's foundational. But it means that some of these questions are very different. When does a user expect to have more storage saved? And so there's things like if the user is added to home screen, we're more likely to save, allow that thing to save more content because the user would like to expect that thing to be able to save more things offline. But ultimately it's about giving the developer ability to understand what's going on and have better control over it. Cool. So now for another fun one. Fun is in quotes here in case you're wondering. Why aren't progressive web apps installable from Google Play? What's your definition of fun? I have a very twisted sense of fun. I think there's a lot to this question, right? And so you can sort of break it down into a couple different axes. Like one thing is that there already are, right? You can put a website in a web view. And so I think the question is probably asking something different. So we announced a trusted web activity today which allows you to actually launch an activity of a component of your application that is powered by Chrome and I think it was explained that the reason for doing that is that you can actually share the cookie jar with Chrome and take advantage of Chrome's ability to help users fill out forms and so on. Those kinds of things are in stark contrast to the experience you get when you just wrap a website with a web view. As users have to go through the login steps and all that kind of stuff where you have to go and do a lot of work to plumb all of that in to the web page. So what we're doing with trusted web activities is making that work better. And so we sort of see that it's important that the developer is there in control of the thing that they are ultimately uploading to the store so they generate and it became. We're giving them tools that allow them to leverage the web and particularly their investments in PWAs to help them build a great application that a user would find through the Play Store. Cool, so one final question I think and this one I actually want each of you to answer. So at Chrome Dev Summit 2027 on the leadership panel when asked what you're most proud of with Chrome in the last 10 years what do you think your answer will be? What do you think the best thing that we're going to do in the next 10 years will be? I'm going to start over there actually because I've heard Darren think about it the longest. He's the most likely to get me fired. The thing I would be most proud of is the way the investments we're making now have enabled the web to survive the next form factor change. We didn't necessarily predict mobile. We saw it coming from some distance off but we've now I think started to respond adequately with progressive web apps as a way to help the web survive in mobile and thrive and make a great product market fit with users in emerging markets. And I think if we do our jobs right we will have done that for whatever the next form factor is too. I think a lot of it is understanding the value of this competition between rendering engines and allowing that as sort of an engine underlying this thing. I think it's much easier as someone was saying in here of like, why can't everyone just work in the same rendering engine together? And I think that one of the things I'm most proud of is that we understand and can help harness that competition in a way that's really helpful and healthy for the ecosystem long term. You know, having started in a very different browser environment during the browser wars V1 even before that I have to say we've come a long way already. And I agree though, I think we'll do even better in the future. I think I'd like to be proud of that we kept the user first, that we were like a particularly noble and good steward for the user. And yeah, we kept them first. Yes, building off of that for me it would be all users and not just the ones that look like us or have the background that we've had with the internet, with browsers, et cetera. And so making sure that it really is for everyone. So I'm gonna expand Chrome just a little bit for just thinking about the web. And so it would be amazing if you look back 10 years and I'm able to publish content or sell a pair of shoes. And all I have to do is build once and it works everywhere. And I don't have to worry about so many different form factors and that it will be accommodating across whatever comes next. So for me as because I'm leading the Chrome mobile so looking at the Chrome from desktop to mobile. And moving forward another 10 years, I imagine there's going to be another new platform. So I want to see Chrome continue from desktop to mobile to this new platform and always there. Yeah. Yeah, I'm pretty excited about the cross-platform Chrome story and making that just easy access content across. But since you already said that, I think so. You can't just say me too. Me too, but also or and also. HTTPS. That's it. All right. Oh no, you have to go in order. Yeah, you have to go in order. Can't take hours ahead of you. Yeah, so yeah, HTTPS was what I was going to say. And because Darren took that, I also look forward to a more secure and auditable PKI because that's actually one of the dependencies of secure HTTPS. And I think we've made a ton of progress the past couple of years to make it easier and cheaper and more affordable, but spending some time on having confidence in that piece of it. And other cool security primitives that are coming to the web platform that I think we've learned a lot in native applications offer development with sandboxing and other defense in depth that it's cool to see these coming to the web platform and seeing those adopted. So. Yeah, 2027. So that means I would have, if I was. Yeah, well, no. Okay, sorry. But I have to say that if I was up here at that time talking about it, that would have been 21 years working on Chrome. And I would just be damn proud of the team that got us there. And I would know that we did something awesome. Awesome. Even more awesome. All right, I think that's all the time we have. So thank you very much. Thanks to the panelists.