 Hey, everybody, I'm Pete, developer advocate on the Chrome team. Welcome to the AMA for Fugu and Progressive Web Apps. Today, I've got a great group of people here who are going to be answering your questions about Fugu, our latest web capabilities, and Progressive Web Apps. So when you take a look on the website, if you see a little place where you can click, you can add your questions in, you need to be logged in. We've got a couple of great questions already. But I'd like to introduce the panel that I have with me today who are going to help answer your questions. So Andre, would you introduce yourself? Sure, Pete. So I'm Adrebandaja. I'm a developer relations engineer at Google working for Chrome and the web and with Progressive Web Apps. Penny? Hi, everyone. I'm Penny, a product manager on the Chrome Web platform. I work on advanced web apps, Progressive Web Apps permissions, and notifications. Awesome, thanks. And Adriana? Hi. I'm Adriana Jara. I work in the same team as Pete and Andre, and also with Penny as a developer relations engineer, and I work on Progressive Web Apps and also Wordbox. Awesome. Thanks very much. All right. So let's jump into our questions. We've got a bunch of really great ones. And this one, I think, is a really cool question. And I'm going to ask it to everybody, but Eric wants to know what recently implemented capability you most excited about? So I can start. All right. So the one I'm most excited about is Web Serial. So I'm enthusiast for IoT stuff, and I've been playing around with Arduinos and Raspberry Pi Picos, and Web Serial allows me to just connect and get my browser to talk to all those devices over USB, and that's really great. Penny? We have to go next. We have a file handling and file type association, the ability to, say, create a photo editor where if you double click a JPEG or ping and have that open up your Progressive Web App, I think that's a super powerful feature, unlocks a whole new class of applications for developers. Yeah. That's a good point. Adriana? Yeah. I really like the synergy that is with several of these features, like the fight handling and file system access that Penny mentioned, and also like the window control overlay that lets you make the app feel more like a platform-specific app, and also the ability to add share codes and the shared target API so that basically you can do all these capabilities on the web seamlessly. Yeah. That's a good one. And I will say, Penny, you stole my answer or my favorite one. It's the file handling, just that whole collection, because it does open a new class of apps that we can build on the web that we haven't been able to do before. In the past, you had to download a file each time you changed it, and you had to give it the file name and all that kind of stuff, but now you can say, great, I want to save this as the same file and hit Control S and have it just save. You can open directories. You can register a web app as a handler for a specific file type. So I think there's a lot of cool stuff there. All right. So let's go to our next question from Hassan. Given that there are a lot of capabilities that could be implemented, how does Chrome decide which ones to prioritize? I'll take this one. There's a few different ways that we look at this. We like to look at the impact of shipping something. So that's both. So how many developers are going to use this particular API? As well as what is it going to unlock for users? Is this going to be something that's really powerful that's going to improve the lies or open up a whole new class of applications that will improve the lives of users? That's going to be taken into consideration. We really need community feedback in order to do this. So we need to hear from developers, whether that's on Twitter or any of our other feedback channels to know which features to prioritize. It's not something that we can do in a vacuum. So it is very much feedback-driven. And if you want to leave us feedback, either forms like this one or Twitter are both great places to reach out and get in touch with us. Yeah. All right. Cool. Yeah. I just want to mention that in the fugu-tracker.web.app, we have all the plans of the APIs that we are planning, and each one has a link to the bug and specs that you can leave feedback on. Yeah. That's a good point. So you can go to go to go.gle slash fugu API tracker. Or if you're on it, can you say the other URL again? Fugu-tracker.web.app. All right. And so you can see there all the APIs that we're currently working on, what's coming next, and all that kind of stuff. Cool. All right. Well, let's go to our next question. This is a live question from Zach, who asked this just, or Zach, just asked this a little while ago. A lot of, let me try that again. A lot of native apps show lists of recently opened files for users to resume working on. I know the new FilePicker API is still undergoing some changes, but what is the plan for it to allow experiences like that in the final API? So I can take this one. For now, the idea is yes, that this is going to work. And the way it would be done is you can save the five handlers and offer the users the option to continue editing in the future. And there are also plans to save the permissions that the user gave the app to modify those files. Cool. So essentially it's giving developers the same techniques that they have on platform apps to be able to do, right? Wait a second. Okay. Cool. All right. Let's go for our next question. And the next question is from artistess. I'm mispronouncing that. Sorry, sorry. With the existing capabilities, oh, sorry. I read the wrong question. We're going to that one next. This one is another one from Zachary. In the past, a web app could use APIs like register protocol handler. These days, those sorts of things get rolled into the web app manifest, making them unable to be requested independently of a full PWA installation. How does it get decided which one should be requestable without a PWA installation? I can answer that from the perspective of principles that we try to adopt. And that is wherever possible, we'd like to make things work on the open web in a tab without requiring installation. And the exceptions to that tend to be where a certain capability doesn't make sense when running in a tab. I'll give you an example like the badging API. If there's no surface to badge, there's no icon in a launching page. It doesn't make a lot of sense to offer this API in a tab, whereas we are going to offer that to an installed PWA. So generally speaking, we try not to give special privileges to install PWA's. There are places here and there where that's an inevitable outcome because they are just very slightly different. What are some of those ones that are just because you're installed? So there's the one that I called out already. There's the badging API. We also flag installed apps as important sites. And that means that we release storage typically on websites. So persistent storage access is also a capability that's given to install PWAs. Cool. Another good example is the Shortcuts API. The one that you get to long press the icon on the home screen. Then you get additional actions that dip link into your web app. That's one that only makes sense when the icon is on the screen. So whenever the application is installed. Yeah. And there's also a shared tag of API. You have to be installed to be able to receive what other apps are sharing from the platform. Can you remind me what does the web share target do again? The web share target allows developers to register their app to handle certain types of files. So for example, if you want to share a picture with Twitter, for example, Twitter can sign up to be able to handle that type of file. Cool. Okay. Yeah. So that I can then share something from like one app that I've already got installed on my device to the Twitter PWA or whatever other PWA that has done that. Cool. All right. Okay. So I'm going to try this again. I'm probably going to mispronounce it again. So I apologize. All right. These, I totally butchered it. I apologize. With the existing capabilities, can a PWA communicate with desktop applications using local resources of the system? Who wants to take this one? So I'm wondering if by local resources, we mean like things like the file system itself? If that's the case, the file system API would give you access to that. Yeah. Yeah. And as we just mentioned, like the shared target API and the web share API allow the apps that are installed in the desktop to interact between themselves. Okay. And I think like realistically, that's probably the main way right now is, Andre, is there any way to do it within trusted web activities? If you've got an Android app. So a trusted web activity, depending on how you use it, if you write some Android code along with it, then yes, you can communicate with the underlying operating system. Okay. You can intent back and forth between other Android activities and the trusted web activity. Yeah. But on desktop progressive web apps right now, there's not really any other way. Though I think it is something that we've looked at. So I would definitely say go to that Fugu API tracker and take a look and see. I believe it's listed in there. And it's, we definitely would love to hear from you about what your use case for that is. Likewise, I mean, the, an approach that you could take would certainly be to just set up a, you know, a network connection between your web app and a server. And then that server and the other desktop app that's running on the user's environment. I'd love to hear more about your specific use case. This isn't one that's come up in the past for me. So if you want to share more with us, I'd love to hear more. Awesome. All right. So our next question is from Jordan. Jordan wants to know how does the origin, origin trial program relate to Chrome's capabilities efforts? So I can take that. Oh yeah. Go for it, Andre. Okay. Yeah. So the origin trial is a way for a developer to test an API before it's, it's, it's completely ready. So it's usually, it usually starts even before the, the specification for the API is done and you get early access to it. Then you get to test that API and you get, you also get to get to give feedback on the API to the developers or to the authors of this pack. That means that you can influence this back and making, for instance, to make the, the ergonomics of the API better. That's what you use in the future. Danny, you want to add something? Yeah. I think the main thing here is that there is a, one of the things that distinguishes an order trial from say something that's in stable is that there may be a blackout period at the end of the origin trial. That means there could be a couple of weeks where that API is not accessible. So while you can use the origin trial to enable capability of stable clients to get access to that feature on your origin, you can't, you shouldn't depend on that feature. So for example, if you were, we're using that API for critical functionality, you wouldn't want to wait until it comes out of origin trial before implementing it. Yeah. Great point. I'll just add that origin trials are not exclusive to the web capabilities technologies, but we do it as a wider program at Google. So we receive feedback from other areas as well. Yeah. That's a good point. I think the thing for me about origin trials is there a great way to experiment with new stuff and make a difference. Like if you're trying to use something and it just doesn't work or doesn't solve the scenario that you're trying to use it for, let us know. This is the time where we can actually make changes. We've had a number of APIs that have gone through origin trial where we've said, oh, this didn't work. And we've gone back to the drawing board. So our next question is from Faith. Faith wants to know what types of frameworks and architectures can be used to build a progressive web app? Are there any types of architectures that lend themselves particularly well? So I'm really curious on this one. I want to hear from both Adriana and Penny because you've both built progressive web apps in the real world. Penny, you want to go first? Sure. I guess I would start by saying that we've made progressive web apps our framework agnostic. So you should be able to build a progressive web app with pretty much any framework or no framework at all. I think when it comes to considering frameworks, you want to just look at what is going to be the right tool for the job that you're looking to do? Is it also going to be a single page app in addition to a PWA or not? And what is the JavaScript size of that framework? How much are you adding to the payload? Hopefully more about core web vitals and core web vitals are a set of quantitative measures of performance. And basically how good is the quality of experience for users who are visiting your site? And if you're adding an 800K or a one megabyte JavaScript framework to your first page view, that's definitely going to impact your core web vitals scores and create a worse experience for your first time visitors. So you just want to take this into consideration. So there's no one framework that I would advocate for. I would just say look at what's going to be the right one for the problem you're trying to solve. And also take performance into consideration. Awesome. Thanks. Adriana. Yeah. I agree with Penny that the PWA is a pattern that is framework agnostic. The one thing when we were building our PWA workbooks, we were not able to use workbooks. And that is something that I would recommend to consider it to someone that is building a PWA from scratch. Because one of the most important parts of the PWA or that can give you most advantages of these capabilities is the service worker. But sometimes if you don't implement the service worker correctly, it can also sort of backfire. And with workbooks, we have been trying to encapsulate and present these patterns that repeat when people are creating a PWA and making sure that the developers are getting the capabilities that they want. And they have a good management of cash. And as Penny said, it can help you do better performance and use of your resources. Yeah. I just wanted to add something that a question that actually came earlier today came up earlier today in the IU adventure, which is you don't have to build an SBA to build a PWA. Like those are separate things. Some people opt to do it because it's easier to do transitions. But you can totally do server-side rendered PWA. That's possible. And if you're interested in transitions, you may want to also check the shared elements transitions proposal spec that's coming up in the future. That's also really cool. Yeah. That one looks pretty neat. Okay. So follow-up question. Favorite framework that you've used recently for building an app? I can go like I am a fan of lead. They just re-branded from lead element and lead HTML. That's how we built our PWA back in the day. And I really liked it because it is really extensible and it really allows you to create like your components. And then from those components, you create your page. You can reuse it. And I really like the data management that they do. Cool. Penny, how are you? I feel like React framework. So I give a shout out to Next.js. Okay. So I've been building a vanilla stuff. All right. All of it works. It's one of the great things about the web. All right. So AJ has our, sorry, Daniel has our next question. Daniel wants to know will it ever be possible to install a PWA from the OS's command line versus from the browser so that they can be installed more like desktop applications? I think that that's a really interesting feature request. It is something that we've been considering. There's a few things that we need to deliver before that would be ready. One of which is packaging such that it works the way that a user would expect. So it would either like chain load a web browser, if a web browser that is compatible isn't installed. It would also need to package up a static version of that app to distribute with the installer such that it would run if it was double clicked and installed for the first time offline. Those are not small pieces of infrastructure to build out, but it is something that we're considering. We'd love to hear from you more. Why are you interested in distributing this way? This is a question that comes up frequently. How useful is this functionality really? That's quite a lot of work to build out. You can already install from the browser. I'd love to understand more of why you'd like to distribute your PWA that way. We can see, we can explore when in our roadmap this is going to land. Awesome. We will, you can find us on Twitter. You can find us there. We've got a couple of group chats that you can come join us at the group chat. And give us more information or pick our brains a little bit more there. So AJ has the next question. AJ wants to know, what's something about project Fugu that you're most excited about, either already implemented or already coming? Now we kind of touched on this one at the beginning. Let's talk about what is coming that you're most excited about? I'm going to go first this time because I didn't go first last time and everybody stole mine. I'm going to say the font access APIs which gives websites, web apps, access to the fonts that you've got installed on your computer. Really critical for things like design apps or like editing apps where you might have a special font that is unique to your company or maybe that you bought on your computer that you want to use for a particular design. So that's mine. I'm going to call out two features that I think are exciting. The first of which is just more user friendly install UI. You might be seeing this in experiment already on mobile. We're going to be launching this on desktop soon in the future. And so what you're going to be seeing there is just screenshots from the manifest, more description about what the user is going to be looking at. And so what you're going to be seeing is just a few things that you might want to expect from installing your app. I think this is going to be so important for improving user understanding of what a PWA is, how they get one, and what, you know, setting their expectations about what will happen after they click that install button. This will be really helpful in facilitating more PWA adoption from users. The other one that I'm pretty excited about is run on OS login. So this is something where it's very, very narrow set of apps that this is applicable to. Like I'm running this already in a beta version of Chrome. Things like my corporate chat app, things like my calendar. I want these things to start whenever I restart my computer. It's great that they just look and feel and behave like any other application and that I can get them to run when I start my machine. Yep, that's a great one. Adriana? Penny stole mine about the new install experience. I really like that we are guiding our users a little bit more and there are also like helpful tips in the browser itself. So I'm really excited about that one. And also in the seamlessly apps acting in your platform, I really like the declarative link API that you can associate apps. And just with like a double click or click, your file will be open with the PWA if it is associated to handle it. Yeah. So I'll go with the new install API too. Especially because the implementation like is so easy. I just have to add a couple of new reference to screenshots in your web manifest. And the UI is so much better. Yeah, that's a good one. We've got an article up on web.dev and on developers.chrome.com about the specific details that you need to do that. So you can go check those out. It's pretty easy to do. Add a couple screen shots and you're good to go. All right. So our next question is from Anshil. Anshil wants to know what should our motivation behind promoting our PWA instead of native apps to our users? And is there any major advantage of using the PWA over native other than size? I can go. All right. Actually, when I joined the team, that was like the question that I had in my head. Like why am I doing this and why are people doing this thing? And what I found out here from developers is that they really, really like having a single code base that they can share among platforms that allows them to experiment and have journeys for users between mobile desktop and basically wherever the user goes, they can continue their journey. And that's what I have found. It's what people like more about PWA's. And that's why I would advertise them and guide people. As we say, like from the Google side, we are helping users understand better PWA's with the new install API and hints. But I totally also recommend developers to building some experience help for the users in PWA's. And if you want to add anything? I think one thing I would add is you do get this cross platform capability with PWA's that's very difficult to replicate. So when I think about the superpowers of the web, one of those is that universality principle that you can write it once. And if you do a good responsive layout, this thing is going to work on a TV, a monitor, on a phone, on a tablet. And then you're just maintaining this one code base. So I think it's very powerful for teams, especially small teams, that may not have the resources to build specialized versions of their software for every different form factor. Yeah. Yeah, that's a really good one. All right. So I think this will probably be our last question. We're coming up close to the end. So this is a question from Deirdre. What reasons do you see for promoting general web apps into becoming progressive web apps? And I think... Go ahead, Adriana. No, you go ahead. So I think for me, the thing that is most exciting is that look, as a developer, I can write this once. I can create an experience that is ephemeral or installed and used all the time. I don't have to think about, oh, what's this install flow that the user is going to go to? Do they have to go to the store to get it? Do they have to go to here or wherever? They can just go get it. And it's going to work for them no matter what device, whether they're on a Chrome OS, Chromebook, whether they're on an iPhone, whether they're on an Android phone, whether they're on whatever. It just works. And that, to me, is super powerful. Yeah. You are basically giving your users choice. There are users that want to run their apps on a tab. And that's perfect for them. But there are also users that really like to have like that. Easy access, sharing things with the file system, having shortcuts, easy access to other resources. And that would be a motivator to have an app that can be also installed instead of a standalone web app that only works in tabs. Yeah. Go ahead, Eldar. Yeah. And beyond installability, even if you decide that your app shouldn't be installable, if you do implement it repeatedly, you can use the service worker and use several features from progressive web apps that will make your application more powerful. You could use things like Web Serial. You could make your application work offline for these cases where it makes sense for it to work offline. You could use things like push notifications to engage your user. So even if it's not installable, you can still take advantage of several features. Yeah. That's a great point. All right. So with that, we got to start wrapping up. I want to turn it over to the folks on the panel. Is there anything that you want to add that you think is super cool about working on progressive web apps and capabilities 10 seconds each? Maybe more than 10 seconds, but not all. Andre. So I like the idea that you can rationalize resources and instead of using your resources to build three different apps for different operating systems, you can put all of them in a single app and build an even better experience in that way. Penny. I think the accessibility of progressive web apps is something I find super exciting. It runs on such a huge variety of devices and a large number of those, very low end system requirements. So that means that almost anyone anywhere can use your application. I think that's a really exciting reason to develop a progressive web app. Yep. Adriana. We are in the middle of building these APIs. Right now, it's the opportunity to decide how we wanted to work and how to make a smooth experience for developers and for users. So please share your feedback to make it better for everyone with us. We are listening. That's absolutely a phenomenal answer. I'm just going to say everybody, thank you because I can add to that. Thank you so much for joining us. Have a great I.O. and be sure to join us in I.O. Adventure. Thank you very much.