 Hello. Hello and hello. Welcome to the AMA session about the state of the web and Chrome's place in all of that You know what an AMA is, right? TLDR, an AMA is a Q&A, where the AMAMs are VIPs, IMO.HTML Anyway, here to A, all of your Qs are these fine gentlemen Here they are. On my This side is Paul Kinlan I'm a little bit further on is a man I genuinely called Don the first time I met him because I misheard his name But I think I got away with it. It's Dion Alma. So we've been gathering questions before this session But if you're registered on the IO website, you can ask questions now. There'll be a tiny little Q&A button on the page It's about three pixels by three pixels for reasons. I can't explain. If you press that you'll get the form But it does only appear if you're registered on the page Also, any questions we don't get to we will answer after the event All right, before we get started. What do these folks actually do? Paul What is Dion's job title? Oh jeez, look at that. My manager It's a director of developer experience, right? And director of developer relations Hey, that's pretty good. Yeah Director that's that's good. I would get it way more Yeah, yeah, you've got me in the spot. I'm sorry Yeah, deliberately. I think you did really well and Dion. I mean, you know questions coming now But you know, what is Paul's job title? But I think really Because your boss really whatever you say is canonical So I know now I'm tempted to think of some kind of cat herding upon Paul runs the Chrome web dev rail team And we all work together on the team to help developers around the world. So thanks for you. Thanks for tuning in Yeah No, I was gonna say do you remember Eric Bidelman's job title was digital Jetta Sorry, Jay. Yeah. Well, you see your job title on our internal site is just a developer advocate, but come on It's very very humble of you But yeah, these folks lead the developer ecosystem teams and help set the direction of Chrome as well. So Let's dive into the questions. First up What's the biggest gap between PWAs and native apps that we are actively trying to close? Paul you can take that one. Yeah It's actually a really good question and I wish I thought about it more No, I think there's quite a lot of Gaps that we're trying to work on on the one side. There's like this idea of capabilities and install ability And I think we've made some really good progress over that in the last couple of years And then the other side is like just like the experience and performance Angles where you know, a lot of people just say native applications feel a lot better They're easier to kind of create, you know, pull down and swipe some whole bunch of other things And so it's been great to see kind of a number of different API's especially on the kind of CSS site starting to come through That actually just you can start to close that gap. So it's a whole range for me So yeah, yeah, I think it's interesting that, you know, as soon as a user adds You know, you're your great web app your great PWA to the home screen You know from then on they launch it from the home screen They don't care if it was you know built on web tech or anything, right? Like they've got a different expectation and so now, you know, we as web developers need to kind of live up to that expectation And hit the experience bar that you're talking about there, Paul And I think that on the capability side, it's interesting how It's kind of a series of paper cuts in a lot of ways depending on what your experience is, right? So we just talked about in the session before this stack blitz so the file File system API is to be able to you know, when you've got an IDE You want to be able to to load up files from your local file system by itself That's like a small API, but it is meaningful if you're building an editor or a photo editor or something like that And so what are the different use cases that you need to get done? We'd actually love to hear from you what what they are as well so we can prioritize them as part of the Fugu effort Yeah, I agree especially on the in terms of file system API I think that was that's that's one of those APIs that means like oh I don't have to build a native desktop app because that's one of those like final features like your batch encoding Of images or you know dealing with lots of files and yeah that close that gap. Sorry Paul. I interrupt to choose. Yeah No, I know you got loads more to say. I got loads Well, I can I can bother on fray is that I think the thing here as well as I think on you mentioned about the Like the lots of little paper cuts and there's like lots of stuff to do I do think the last we've made a lot of really good progress over the last couple of years in terms I really big capabilities like the file system one that you're talking about There's still a load of like even little things that need to be fixed And like, you know one that reminds me right now is just like even things like splash screen There's still a lot of work that's going on in that kind of space I want you to install it to that home screen and you launch it I think you can still sometimes tell that it's not necessarily in the completely native experience at that point. And so yeah, I think there's a lot that's gone on and There's still a lot to do Yes, okay, let's move on to the next question Here's a recent thing that happened Google Docs moved away from the DOM and use canvas instead This was kind of a pretty big story Is that the way forward? Is the DOM dead now? Should we all be using canvas instead, Dionne? Yeah, so this was fun to see kind of blow up in the last couple of weeks So a little bit of history myself and Ben Galbraith was presented with me earlier Back in the day, he built an online code editor called Bespin That we open source with Mozilla when we joined there And we actually built multiple versions of it at the time some that use DOM, virtual DOM, different techniques And ended up building a canvas version that at the time It won performance-wise Even though it came with all of these different constraints And so for us accessibility popped up then quite a bit too and we ended up having kind of a side DOM It's a handle of accessibility and and I do think it's interesting that the web community is very passionate about accessibility Which I think is important because it allows us to you know build on the reach of the web to get to To help users across the world In a way that makes sense for them, but I think we really the answer shouldn't just be We have to put everything in DOM. There's a lot we can do with DOM to make it better in different ways But I think it's really interesting to see the the AOM work You know in the accessible object model and some of this These new APIs that we're working with allow us to work differently with accessibility And so if you actually played with the version of Google Docs You'll notice that it actually works very similar To the to the current DOM version. That's because they also use a side DOM tactic and put a ton of work in there, so there's Chuck or Shane or Sean who wrote a post it's now. I think like 10 years old That talks about how Google Docs does Their accessibility and I think I think there's just a lot for us to learn here And with you know, Google Sheets itself went to Canvas a little while ago We've got more and more happening with you know, WebGL And the like with Figma and some of these other tools that are out there So I don't think we need to slow them down, but there's still work that we can do in DOM too Yeah, I agree. I think it's a success story in some way in that like we have those low-level APIs now that a site was able to just talk directly to graphics APIs and Create an accessible experience And they were able to bypass lots of layout that the web already has in order to improve performance But I don't think that means that we should all be Doing that in the same way that they you know assembly exists But when you're writing a native app, you don't go straight to assembly You only go there when you really really need that power and I'm hoping that we can add in more levels in between like we've got the DOM we've got the WebGL Canvas I'm really looking for things like layout workloads where you know, what can we do in that space? How can we you know, maybe bypass some of the layout stuff to create the form and layouts by just throwing away lots of features? Yeah, Paul, are you excited about that direction of the web? Yeah, of course I am yeah There's a whole bit like for me the way I was thinking about it was I actually like the competition that you get between the two platforms I when you can't do I think Jake you mentioned a second ago about that this escape hatch And so we've got all these different layers, you know It puts pressure on kind of the browser engineers to actually improve the DOM And you know, I was looking at kind of the hacking news thread and which was actually quite interesting to read and You know people are saying like, you know content editable should be way better But you should be able to do the majority of things like Google Docs just with content edits Editable and I think it's a challenge for us to actually step up and try and resolve for that point And so yeah, it's one of those things of you know, you always get people who want to try and push the boundaries And I think the way that you know people like Google Docs are doing it They're still accessible like the Google IO adventure web app as well There's a lot of work that they were doing to make that very Canvas based application accessible as well And so where in the past things weren't accessible, especially with Canvas You know, we're starting to see kind of like, you know, inroads in now to make it so that you know You can experience these things. Yeah, it puts pressure on so the the rest of the stack to actually improve Yeah, we always get those questions like, you know, I remember when Canvas and SVG landed There was a big like, you know, oh canvas versus SVG which one's going to win And we see the questions now, you know wazen versus JavaScript and You know, we've got Dom versus WebGL Canvas and I guess it's the same answer It's it's like these things aren't competing against each other You can use it at the same time and use them for the things they're best at. All right, let's let's do it Let's do another question. Ah, this is a this is an interesting one How do we balance Privacy and capabilities. So we've got a lot of the you know, new features some Let it come to paper API. It's just like hooking directly into You know the data that's on the user's device. We have late, you know midi serial Bluetooth API This is all just kind of it allows a website to your breakout of its sandbox, but you know with permission of the user How do we balance that out? Do you want to take this one? Sure So, yeah, so I feel like sometimes this Comes across as a black and white kind of situation of just like okay We either need to not add another capability in the for the rest of time to the web To be private or we don't care about privacy and we're just gonna add all of these things and You know, we talked about in there in the privacy sections before like we think this is a false choice and we believe that we can come up with a you know private by default Way of building capabilities for the web Acknowledging all of the different needs the different user needs that are out there And also the developer needs and I think with a lot of what you're seeing with the privacy sandbox I'm like it's trying to take what we have now, which was just a very blunt tool, right? Here's cookies low level name value key value pairs like oh man Like there's a lot you could do with it, but like it's an incredibly blunt instrument and instead Think differently about this and give you the developer the tools to be able to ensure that your users are gonna Have good privacy, so you're not you know scared that by using a particular SDK It may change the behavior and have higher level APIs that that can help you do this So this is a really fertile ground That's why we do in all of the privacy sandbox work in the open Anyone can get involved. It's really important that we do that But at the same time we want to make sure that we push forward in that way and we deliver really rich capabilities that allow anyone To build a kind of on this modern computing platform, right? Like I think about You know a child learning an instrument on the other side of the world and you know back in the original web days You'd be able to like look at a document for that out. You'd be able to see some music But now you can plug in a midi keyboard And get this amazing interactive experience on a low-end device that reaches everyone And I think like that I want to see more of that too. So I really do think that that we can correct this note Yeah, Paul like there's been some APIs that in this space that maybe haven't The other browsers have objected to it in some ways due to Like it may be pushing the bar a bit too far in terms of you know What it can do with things outside of the browser and maybe even outside of the device things like the web bluetooth API Do you think we're getting that balance right at Chrome? Yeah, I do actually I think that the main here is it's good to have that pressure from external groups about queer question in You know, whether the API is actually leaking information that they shouldn't do and I think it's on those to make sure That we get the articulation right especially the spec base And then especially the developer phase and then in explain these features to users as well because you know There's API's that you mentioned things like bluetooth access like the general consensus was oh external like perception Sorry was I don't want this thing to scan everything and just tell me like they report everything around me back to some website And the API never did that from the start at all It just gave you a bit like gave the user a picker To be able to kind of slide the device and then actually connect to it at that point as well And I think it's probably a notice that like sometimes the communication doesn't necessarily go out as well as it should do On that side to explain these features, but it's good to see that you know browser vendors and you know I was in particular as well, you know We're trying to make sure that the user gesture and the prompt and the way that we explain these features to develop like to users Is actually getting a lot clearer as well and that's That's actually quite nice to see on the side Yeah, yeah, I think I agree the We're expanding in those areas like Bluetooth file system But these are all you know behind permission prompts or other bits of user gesture Whereas I know from my work. I'm doing a lot of work with the history API and That sort of stuff right now and I what I see is I see that we're tightening those things like we're we're giving the browser Less abilities where we can so it's interesting that we're sort of tightening it up by default But then sort of expanding it. Yeah, I mean, it's gone through a permission. Yeah, I was actually having a chat with Rowan the other day You know Rowan leads a lot of our kind of privacy sandbox Developations work and like one of the things that we were talking about is the permissions policy and feature policy and content security policy work as well And we had this interest in like interest in discussion that as a web developer You might actually want to disable all the ability for all those APIs from default and then selectively enable them so that you know If a third piece like third party piece of content is then run on your page You know, they don't get access to those APIs And I think that's maybe where the some of the issue comes in in terms of like the richness and expressiveness of the APIs is Things outside of the developers control that they put onto their site You can't trust right at this point and then like do they take data back to the other sites And so we were going down this idea of maybe we should just default deny everything to start off with and then develop it Selectively turns them on. Yes, my application is a webcam based application. You know, like Google Meet or something like that It definitely needs the camera. Okay, I'll just enable that once more feature And then I'll innate like the user can activate it through a gesture in the prompt And so you get a lot more control over that side But that's not the model of the way it like the way that the web is today And it might be a way that we have to think about in the future Yes, okay, we're going to go to a live question. This is this is just half the press So, you know, now we're here prepared for this one. This is from her man. We all know her man She's a man for that Google I over for how's it going? I really like this question actually lately we noticed that Chrome DevTools has moved to TypeScript's What was the the major reason for this and don't we feel that we're losing a vast set of? Open source contributors who don't know TypeScript They only know your regular types Yeah, this one with the end. Do you want to go first? Yeah, sure. Um, so So yeah, this is an interesting. So DevTools is is a really interesting Part of Chrome because it's basically mostly a web app Which you know, sometimes people don't always Relieve and understand because it's kind of baked into Chrome in that way And because we try and dog food You could almost do archaeology on DevTools where you can like look at it over time about oh, that's when we added Observe back in the day. Well that we we ended up moving on from that But here, you know, we got a polyfill for it and you can kind of see over time How the web is evolved? At some point you get to You get to realize how much technical debt that you that you have and so Paul Lewis and team So like now is the time to kind of clean up. We have things like ESM To be able to load modules versus what we had before and we lose using you know closure. It's a massive code base But now for these larger code bases especially but even in general people are really excited about TypeScript And it was just a really good fit For this project being a very rich application very large definitely not trying to Lock out any open source contributors. Hopefully it's still Approachable other than the fact that it is a very complex project So it's hard to walk up to but yeah, I think it we've actually gone from a more weird custom proprietary Kind of world into something that feels more like how you'd be build web upside. What do you think Paul? No, actually, I think you answered exactly what I was going to say as well I do remember speaking to Paul around this and the idea behind it was like 12 years of code That's built in built upon and built upon and built upon and it's you know It was there was different templates in frameworks and different frameworks that they were using to kind of you stamp out the Dom and a whole bunch of other stuff. And so they had they wanted to kind of build bring a little bit more method like Methodology methodology to it, I suppose I'm following you Yeah, it's there's a whole And so they want to kind of be able to bring this so that they can test it they can refactor it They can get more contributions more easily as well without kind of you know having a whole bunch of side effects that you change one little thing in the Dom Explorer and then all of a sudden I get a whole different part of the DevTools breaks as well And so, you know, their choices behind kind of move into the TypeScript. We're just you know more rapid development better testing Improved confidence that you know any changes that they make it gonna actually reduce the potential side effects and impact Yeah, I have a lot of sympathy for the people who are saying like oh, it's no longer JavaScript So it's it's harder to contribute to because oh this happened a lot more a few years ago like I would use a library and Find a bug or want to add a feature to that library like right here We go open source contribution and I'd go to GitHub and coffee script No, I'm out Because I just I just didn't understand it I do think TypeScript is a little bit different because it is a you know It's adding on to JavaScript late. If you don't know any TypeScript is going to be confusing Bits there, but largely it's just going to be the JavaScript you you recognize and like you say I think The way the DevTools team Refactoring in order to to build upon more common practices. I would say the DevTools code base is Getting getting less alien You know even to someone who's not that familiar with All right, let's move on to the next question This is I let's see if you actually know the answer this one because I know I don't so I hope one of you What is the status of manifest v3 for CRX is that but that's Chrome apps is that Chrome apps? Chrome extensions Corrections migration. Yeah It's still being I've been working. I'm not actually sure the timelines to you know, I'm not sure the latest Yeah, we can we can answer that one then the proper follow from the Dory I do know as I can develop relations team There's still a fair amount of work that we have to do as well just kind of you know as we make the kind of You know the industry and all that part of the extensions ecosystem has to move You know, we do want to make sure that it's as easy as possible for you to kind of meet those migrations as well Because it's not always one-to-one compatible between v2 and v3. So Microcosm of the privacy and compatibilities work Right where it's like we're trying to come in here and do things that they give us a stronger foundation Both performance wise and privacy wise and everything else But To make these bigger changes takes takes time and like you say Paul, we don't want to leave behind Too much of the developer community and when I work together to get us all over to v3 Well, right. Okay, next question What improvements will there be to the installation process like add to home screen for PWAs on Chrome? Yeah, there's actually quite a lot of there's been a lot of it or iteration recently as well Because I know that when we first launched kind of the install installation process It was just like this little bar across the bottom and then you'd have to You know, you might actually manage your own install button and the whole bunch of stuff I know that the teams are looking at kind of like in the future What set of APIs that they might be able to offer to kind of give you a little bit of control there Nothing's kind of locked in on that side of things It would definitely I would like information and feedback from the ecosystem about what we need from the kind of installation space I think the biggest piece though is that in the other recently We've actually started to kind of include a lot more metadata Inside the little kind of the bottom sheet that's pipes up from the bottom of Android at the moment And so this gives you kind of description so use a developer who can control what's displayed there And then also there's extra screenshots as well. So if you've got extra information You know about kind of other screens inside your application I just not quite visible from the first page like you've got that information that'll be displayed inside Chrome I believe it's a flag at the moment still as not fully enabled just yet So going going to about flags kind of turn it on and give us a beeper But it's actually really nice to see these kind of changes starting to come in in that space Cool and we'll in the Dory we'll we'll link to some articles about that sort of stuff. All right Let's see if we can get through a few more questions before they Take us off there against our will Okay, here you go. What do you think is more important adding features or improving performance? Yeah, I feel like some developers may feel like all we care about is performance because we we talk about it a lot And I've talked about it over the years Um, but obviously context is everything here right like this is why with with call web vitals Um A key part of it is the set of thresholds Where you know, if you make sure that across the the three main metrics that you hit the thresholds then You know, you've got a solid foundation to to build on that doesn't mean you should stop there And if there's you know room to get better You should definitely put that in that work in but at least there's a base threshold for you And it really cares about what you're building and what makes sense for you Like I worked in e-commerce back in the day As an example and the performance requirements were different at different parts of the funnel Like right at the beginning if your first link in From search is slow The user may hit the back button and go to amazon or someone else Later on in the funnel if they're you know part of checkout And it may not be quite the same quite the same thing right and if you're building a single page app There's a really rich app that sits in the tab That's a different experience than if your you know average session length is you know 1.2 page views So it's really important to kind of take into account what you're doing And and take the time to like we talked about with capabilities The work could do a lot more than I think a lot of us even realize at times And so you know taking the time to to go deep with that and see how what can I do to to add to this experience because Like like that going back to a stack blitz like that. That's just a totally you know New thing that they could add that the drastically changes the the experience and You may have a couple of those that you maybe don't even know about Yeah, it was as well. It's like there are You we can do both for once that there are features that we add which are directly related to improving performance right thinking of things like web assembly Things like you know web gl2 and you know those kind of graphics apis. These are you know directly linked to Giving low level ability to get you closer to the metal On a given mobile device or or laptop. All right, we've got five minutes left So we're going to go in for the for the last question. I'll ask each of you this If there's one thing developers should go away and do Or look at after this session What would it be Paul, do you want to start? Set up a petition to bring web intense back That's what I'm talking about No, I don't remember as web intense those jokes don't work Some people remember it. Some people I'll get a tweet and someone will tell me that they remember it and For the benefit of like the entire audience About 10 years ago. Paul was working on a feature called web intense and it was It didn't it didn't pan out and he's still bitter about it. Yeah. Yeah, I actually love it Actually, it was an interesting space like interesting pouring into kind of Specs and I kind of realized that I don't have the kind of the patience and the mentality to Define specs, right? So I've got a kind of a very strong appreciation of people, you know, like yourself, Jake who are actually kind of You know good in that space Is it what should people do? I I do think like, you know, you'll see a lot of the stuff that we're talking about at IO around performance and the privacy sandbox I would actually go out and check those Those pieces out because there are a lot of changes coming to the platform You know call web vitals is kind of giving you the kind of the metrics that you can use to understand You know how your users experience your site and you know, it It's going to kind of you know affect some changes in the future on that side and then you've got this kind of the privacy sandbox work as well where it's Um, you know, there's a lot of changes coming through and like the same site cookies That was coming through like that was a big change in the ecosystem that we had to kind of work on There's more in that space and we need your feedback and we need you to look at these articles and give us You know, tell us what you think tell it even tell us if it's going to impact you positively negatively What you think we should do instead on the side of things as well So I think there's two things I'd say you go and do call web vitals and privacy sandbox I didn't say you can have two but fair enough you've taken two You made fun of me about web intents, so I'm taking two I mean beyond we don't have space for yours. Yes, we do go on deon. What's your yeah, totally? Yeah, so once you've made sure you hit the call web vital threshold then We've got code labs on the fugo apis I recommend checking out so you can see what are any potential missing things there, but I really want to get to the piece I'm you know most excited about which is You know check out eunus talk on the new responsive I really feel like css is going through a massive revolution, right? We had this with On the java script side and we continue to but it feels like now css is really Doing exciting things and so check out container queries all of the goodness is coming in through css there learn css Is a new course that we put up on on web.dev, but I really enjoyed going through I think you'd enjoy too DevTools has a whole bunch of support for these features now It's like finally I can just go into my flex box and just actually see What the way space between spacer it's like boom right here. I can just play with it loads and loads of new features coming It's I especially you know hearing some of our container queries. We wanted that for so long But we are absolutely out of time So thank you very much to paul and to don it's deon. I know it's deon now But thank you to everyone who has joined us for this session The questions we didn't get to we will get to we'll answer it in the dory. Thank you very much And goodbye Thanks, everyone. Appreciate it. See you in the adventure