 Here's a summary of how web install is different from bookmarks. Web install offers users access to web from familiar discovery and launch services for their device. So install web apps can be standalone. That means they can be separate from the browser. It also means that they can be integrated into the native task switcher. This can be a more familiar way for users to interact with apps, or it might be more suitable to certain types of tasks than tabs. Web install integrates the web apps with the device services that expect an installed app. The important thing to remember when you're asking a user to install a PWA is that with an installed app, you're telling the user that it is an experience that is meant for the device that the user is using, and that means that you need to live up to those expectations of what you design, you're going to have unhappy users. But, of course, who are these users? Who is going to benefit from this extra power? We're the first ones to admit that it won't be everybody. The power of the web has always been that it is ephemeral. Users can move seamlessly between experiences, and so you shouldn't expect all your users to install. And to that end, there is a bit of an install funnel. This is the same as native apps or e-commerce conversions. Most strategies for optimization apply here as well. You don't want to push the user to convert too soon, or they'll leave your site running. You should only promote installed users who are frequent users or who will actually benefit from your services. The web is super powerful in its own right today. You can build a hyper-local video chat app with WebRTC, geolocation, and push messaging. You can make that app installable. You can add video effects with Wassum, and you can even bring it into new realities with WebGL and WebVR. But there's still gaps in what we can solve with the web today. In the worst case, this means that developers are not building for the web at all, or they're relegating it to a second-class experience. For those that do want to build for the web but need the capabilities of native, they're forced to bundle web apps in native wrappers. This often results in developers effectively shipping their own custom browsers to users, exploding the size of their web apps and forcing them to take on the security and maintenance burden of both keeping the browser and their native wrapper up to date. Social apps on mobile devices have been hard because they need to be tightly integrated in order to be loved by their users. Quinn thinks for themselves, our users want to start a journal entry from anywhere on their device, and they want to be able to share those entries to other social accounts. They also want to collaborate on entries with their friends, so they need to be able to invite them to do so easily. Until recently, these capabilities would seem to roll out building a web app. They just simply didn't exist. Both WebShare and the new WebShare Target V2 and Contacts APIs, that calculus has changed, and Quinn can build a progressive web app instead of a native app. Go try it yourself. On your Android device, go to FuguJournal.web.app, add it to your home screen, and try out everything you've seen, inviting friends, adding content, and sharing it out. While the Contacts API isn't fully launched yet, I've enabled an origin trial on FuguJournal so you can see how it works without a special version of Chrome or toggling any Chrome flags. And again, you can try this out yourself. On your computer, go to fuguedit.web.app, install it, and try to open the files and folders and save them as you normally would. Go to webwewant.fyi to let us know what you'd like to see added to the web platform to help you bridge the native app gap. The first feature that I wanna talk about is WebAssembly threads. Threads are a key part of practically all CPUs, and utilizing them fully and effectively has been one of the great challenges for the web until now. SIMD stands for Single Instruction Multiple Data, and while this may not be a term that most web developers are familiar with, it's an absolutely key part of modern CPU architectures. The Google research team looked at a bunch of their models and found that in general, SIMD had offered a 3x improvement on overall speed. And our benchmarking backs up this visually noticeable difference. When using both threads and SIMD together, common tasks in OpenCV can be improved by around 15x. We want to not only be able to start in a synchronous task, but also wait for you to finish, raise the results back and continue the execution afterwards. This is where I think if I come soon. I won't go too much into implementation details here, but what it does is compile the WebAssembly module in such a way that it can suspend the execution remember the state, and later resume from the exact same point when another synchronous task has finished its execution.