 Hi everyone. I'm PJ. I'm a product manager on the Chrome Web Platform team. This session is on next-level web applications, and while the capabilities I'm going to describe are most applicable to desktop screens, let me emphasize that powerful web apps work everywhere, on phones and on TVs, too. I love the phrase, one web, many screens. You can build powerful applications for any device using web technologies. With a good responsive layout, you could share the same code base amongst all of them. Compare that to the alternative, a minimum of three, if not five or more code bases, and it's clear why we see more and more developers are choosing the web for their applications. To understand how transformational this moment is for the web, let's start with a little internet history. Gmail is a market-leading email client, but when it launched in 2004, there were many incumbent products. There were already dozens of popular clients and virtually all internet users, had an email account and a client. If you've worked at a startup, you know that a new product typically has to be at least 10 times better than the incumbents to win market leader status. So, what was Gmail's secret sauce? Well, what made Gmail different was being a web-based client which meant reach and universal access. There was no software to install. All users needed was a web browser, and by 2004, most computers had one. This made user acquisition trivial. All anyone had to do was have a link. There was one more requirement, though, and it was a critical web capability that started landing in browsers just a few years before Gmail launched. For those of you who have been developing web software for a while, you might remember this new capability called Ajax. Ajax transformed the web as an application's platform. Before Ajax, server requests could only take place with a page refresh, so client interactivity without reloading the page was basically impossible. Imagine you had to hit refresh every time you wanted to check for a new email. Gmail would never have succeeded. Ajax was transformational, and in addition to enabling Gmail, within a couple of years, we started to see applications like Rightly that formed the foundations of G Suite. I think we're now on the cusp of another transformational moment. I broke these APIs into three rough categories, environment access, application flow control, and engagement. With these APIs, web apps can load and save files from the user's file system, trivially use tabs in standalone windows. Developers can automate the focus of the user flow between standalone windows, tabs, and the browser. They can also place windows across multiple screens and give users the option of running the software on application startup. Finally, with notification triggers, we unlock new types of applications such as alarm clocks and calendars that need robust assurances about the timing of when notifications are displayed. Quick word of caution. The timelines given here in this table are rough estimates. You could always get the latest info on the Fugu API tracker at the URL in the center right of the slide. Before we get into the specifics of the APIs, let's hear an example of what's now possible on the web. Hi, I'm Alex, co-founder and CEO of ClipChamp. ClipChamp is the world's first and only completely in-browser video editing platform. We've taken what's arguably one of the most complex and complicated application categories and got it to work purely based on web technologies, including a computationally very intense video export process. Google Chrome's always been our platform of choice. One of the features that we've adopted very early was progressive web apps. And we can already see now that users who have installed our PWA retain three times as well as the average user. Some of the new features that are going to be landing to Chrome in progressive web apps, such as native file system and font access, will make the app indistinguishable from any other app that they might have installed on another operating system. We're incredibly excited to see these features in the wild, and our users adopting them at scale. Thanks so much, Alex and ClipChamp team. For all the developers out there watching this, you might want to stand in front of a mirror and say completely in-browser video editing platform three times to fully believe it. Let's get into more details on these APIs. Many of them aren't in stable yet, so you might need Canary or another dev channel version of Chrome, and you might need to activate some flags. I've specified the flags needed where appropriate. Let's say that you want to create an application that opens CSV files. Your manifest would look something like this. We're declaring in this section that when a user double clicks on a MIME type text CSV file with a .csv extension, you can see the accept member there, the action is handled by the apps slash open CSV route. Now, here's an example of receiving a file handle. To access launched files, a site should specify a consumer for a launch queue object attached to the window. Launches are queued until they're handled by this consumer, which is invoked exactly once for each launch. With this approach, you can ensure every launch is handled. Your application can then choose to handle these files however you'd like. We've got so much to cover today, I better speed things up, so it's time for a double whammy. These two capabilities make sense to run through together, because display override will help us with tabbed application mode. First, I'm going to show you what tabbed application mode looks like. Hey, look at that. Easy tabs in a standalone window. This is groundbreaking for many productivity apps, where it's common to have more than one file open at the same time, but you want those all associated inside of the same window. Here's how you use the new display override member in a manifest file. Notice that we start with the widely supported display mode standalone. The display override member is ignored by browsers that don't have support for it, so the app can continue to fall back to display standalone on unsupported browsers. Display override takes a list of display modes which are tried in order, falling back to the next one each time if it's not available. You might be wondering what link capturing and URL handlers are all about. Link capturing and URL handlers let you control what happens to the user journey once your app is installed and in standalone or tabbed browsing mode. For example, should clicks from the browser that are inside of the Sculpture web application open in the browser tab, or in an existing standalone window if one exists. Maybe they should open a new standalone window, or maybe they should open a tabbed in a tabbed window. All of these are possible, and unfortunately, we'll only have time to scratch the surface on what this API can do. Here's a sample manifest that has link capturing in it. The capture links member is specified in this instance as existing client event. That is, when a link is clicked leading into this PWA scope, the user agent finds an existing PWA window, and if more than one exists, the user agent chooses arbitrarily and it fires a launch event in that Windows top-level context containing the launched URL. We can see in the defined URL handlers that you can see how origins are specified for handling, in this case with a wildcard. The permission for the app to handle URLs for these origins is verified by the browser through a web app origin association file posted at each handled origin. The Window Placement API enables complex productivity apps that require multiple window layouts across multiple screens. For example, apps in presentation, finance, medical, creativity, or gaming apps. There's a lot to this API, far more than we can deep dive into today, but I'm going to show you a couple of highlights. The highlighted code here returns metadata including how many screens the user has connected and the coordinate system of those screens. This snippet opens a new window on the device's internal or primary screen. Here's how you'd request full screen on an external screen like a TV or projector. This is how you know if the user's screen setup has changed. For example, if a new monitor was plugged in or one was removed. I love demoing this feature because it's so easy to use. You'll want to be using Canary and enable the appropriate fly. One way to use this is to simply let users opt into the experience with the install prompt. We're still working on the exact user experience for this, so some of the UI may change before it hits stable. The other way to use this API is programmatically, and you can specify the mode as being either windowed or minimized. For example, some types of applications might want to start in a minimized state. Let's take a chat app, for example. Notification triggers allow notifications to be shown when certain conditions are being met. The trigger can be time-based, location-based, or otherwise. For today, we're going to focus on time-based triggers. You might be asking yourself, why not just use regular notifications for this? Well, the reason is that the pushed API is not reliable for triggering notifications that need to go off at a very specific time. So for applications like calendars, alarm clocks, and so on, you need something that has higher accuracy and timeliness. Just a quick note, this API is currently in origin trial, and we're welcoming developers to try it out and give us feedback. The APIs I showed in this presentation aren't the only ones to get excited about. Check out the Digital Goods API, local fonts, the badging APIs. If you want to know about a few more exciting capabilities coming to the web platform, well, that was a whirlwind. Thanks so much for joining, and please keep those questions coming on Twitter.