 This will be an overview of web components and how they've quietly started powering more of the web than you may be aware. First, we'll take a look at the current state of web components adoption in the real world. And then we'll dive into the use cases that are actually driving that real world adoption, including a guest spot from our friends at Salesforce. And finally, I'll give an overview of how you can get started solving some of these same use cases today with web components. All right, so how many people out there are actually using web components today? So that's sort of a trick question, because everyone is actually using web components, whether you know it or not. Because as a user of the web, every one of you probably use them on a daily basis. That's because web components are, statistically speaking, one of the most successful new browser features shipped in recent history. By our count, over 5% of page loads today use a web component in one way or another, putting it in the top handful of major new web platform features shipped in the last five years. Web components can be found on big properties you probably visit on a daily basis like YouTube and GitHub. Web components are prolific across news and publishing sites built on AMP, since AMP is built on web components. And finally, enterprises are finding huge success with web components, which we'll explore more in a moment. But first, what are web components? In modern web development today, pretty much everyone uses components to encapsulate UI functionality. Web components allow us to extend the browser with new components like an image carousel that can be expressed as normal HTML as if they were part of the platform. Web components are low level browser APIs that give us a standard interface for defining new components. Web components have a common way of being created using HTML and standard DOM APIs that every framework uses, and a common way of receiving and sending data using properties and events. But outside of that standard interface, web components don't say anything about how the component is actually implemented or how to build apps out of them. So web components are not one specific framework for building apps, and they don't set out to replace frameworks. They don't tell us how to render or update the guts of a component. They're really not opinionated at all. Web components simply tell the browser when and where to create a component, but not how. Authors can choose functional rendering patterns just like you might in React to build web components, or they can use declarative templates like you might find in Angular or View, for example. As an author, we have total freedom to choose a stack within the component or use no stack at all while still maintaining interoperability. And this is the key difference between web components and proprietary component libraries. Because of their standard interface, web components can work anywhere a built-in element like input or video can. So we can make a custom tab bar component, for example, and use that and markup on an HTML page. But also in all the popular frameworks like React or Angular, because web components can be expressed as real HTML and rendered by frameworks using standard DOM APIs. All of this means that once you've made an investment in creating components, they can be consumed more widely in a more diverse range of applications because they work with virtually any framework, anywhere the web works. And so users of our components aren't locked into any one framework. So that future proofs us from painful migrations when we inevitably need to update our stack since web components are portable across frameworks. So for all of these reasons, web components are actually finding huge success in a variety of different use cases. So let's take a look at those. Web components are the perfect technology for progressively enhancing HTML content because they can already be output as standard HTML by an untold number of CMS systems already out there. And AMP is a great example of how quickly and easily web components slotted into the publishing industry's infrastructure for serving content because AMP components are simply expressed as HTML. Another obviously great fit for web components is in creating design systems. How many of you work with designers that wish they could have one golden implementation of your company's design language, but instead have to contend with many teams building their own component sets on top of React, Angular, and all the other frameworks, each with annoying differences in the components that drive your designers crazy? Web components are the answer, a truly right once run everywhere component system that still gives app teams the freedom to choose the framework of their choice. Companies like ING, Electronic Arts, and the material team here at Google are implementing their company's design language in web components. And finally, web components are also hitting a remarkable stride inside enterprises as a safe, future-proof technology to standardize on. Google has built over 15,000 web components internally, and the number continues to grow. Before a more detailed look at why enterprises are choosing web components, we've invited our friends from Salesforce to share some insight into how they standardize on web components across their developer platform. So I'll hand it over to Karate Patinho, an architect on the UI platform at Salesforce. Thanks, Kevin. What components of Salesforce? About three years ago, we embarked on this journey to try to modernize our UI platform. We decided to use web components. I would like to give you some of the details of this journey. Salesforce as a business is just a set of applications. You have a long list of applications, and many of these applications actually are acquisitions along the way. And when you have an acquisition, you have a application that is running a different stack. Makes it really difficult to share different elements, UI elements through these applications, because it's just very difficult to have the same experience on these applications. That's one of the challenges that we have. Additionally, we not only sell these applications, we sell the platform. And this platform offers the ability to create new applications, similar to those that we offer. This is another challenge, because we want components to be able to be shared across these applications as well. Additionally, we offer what we call the customization aspect of the platform, which allows you to not only customize the applications that we offer, but customize the components inside those applications and even create your own components and even share them with other developers through the app exchange. All these are challenges that we were set to solve. So we ask our developers, what do they want to see in a new platform? And no surprise, most of the things that they wanted are around developer productivity. They want to be more effective at doing what they need to do. They want to use more standards. They don't want to learn the Salesforce way of doing something. They don't want to learn the Salesforce API. They already have knowledge that they want to reuse. They also want a common component model. So if they want to customize different applications in our system, they should be able to use the same process. They want to be able to find people that can help them. Finding a Salesforce developer is very difficult. Finding a web developer is easier. And they want to use the standard tools. They don't want to be forced to use a particular set of tools. They will also be very passionate about what they don't want to see in our platform. They don't want to see breakage changes. They want the platform to continue to be about what compatible. They don't want to be stuck in all technologies. They didn't make a change today. In a year from now, they should be able to come back and use new technology. They don't want to be inside a wall garden where the components that they create and the customizations that they do are only useful inside the Salesforce ecosystem. They want to be able to have components that are portable outside of the Salesforce ecosystem. So we looked into many of the popular frameworks and libraries and we make a decision to use web components. But what was surprising about this is that we discovered that the UI platform happens to share the same constraints and the same features of the web platform itself. We believe what components are natural fit for Salesforce. We have no external dependencies. We're building a platform. And we also understand that different frameworks, they have different objectives. For example, Bible compatibility was a deal breaker for us. We can now force our developers to upgrade to a certain version. And all these popular frameworks and libraries, they all use semantic version. So you need to get everyone onto the same version in order to upgrade. We cannot afford that. Instead, what we create is what we call the line of web components or LWC for Jordan. These are just web components. It's a foundational set of components that we use across these different apps. You can create your own on top of that. Since they are web components, they are interoperable. They are Bible compatible and future proof. We like that from web components. But web components APIs are a very low-level API, as Kevin mentioned. So we create this thin layer around it that we call LWC. This offers a little bit of developer activity enhancement because you will be able to create components faster. Also, in this layer, we actually fill the gaps that the web components APIs have today. For example, accessibility. And on top of that, we offer the design system from Salesforce, which is built in in this layer. You can opt out if you want. Additionally, because these are web components, we can actually extract the structure of all these components. We know the exact API of each of them. And therefore, we can use it in our builders. We can use the metadata to provision the components and preload them. Those are the things that we really like about web components, the ability to understand the shape of it. Finally, Salesforce is now built on web components. We like the ability to have this common component model that we can use across these different applications. We like the performance of it because we don't need to do anything. The browser does the heavy lifting. They are power compatible forever. And we can evolve alongside the web platform. Encapsulation is also another goodie that we get from the web components. And finally, the ability to use those components in different applications and beyond the Salesforce platform. Those are the things that we really like about web components. Let me get back to Kevin. Thanks, Karity. So as you can see, with big enterprises like Google and Salesforce betting on web components, and with the web components API is now natively implemented in the vast majority of users' browsers, you really can start using web components today to solve some of the use cases that we discussed earlier. So if you're building a web app, consider one of the many web components that's out there. Here are just a couple of examples. So the Ionic framework team has an enterprise-grade set of web components that are ready to use. And there are neat sets developed out in the community like the wired elements. These have a really cool hand-drawn effect that are perfect for prototyping applications. And finally, there are great special purpose web components like Model Viewer developed here at Google by the augmented reality team. With just one HTML tag, you can add AR-ready 3D content to any web page using this web component without knowing anything about WebGL or the new XR APIs that power this kind of experience. Again, just by adding an HTML tag. And finally, if you're developing a design system for your company and needed to be consumed in a lot of different stacks or if you're vending a specialized component or library that you want to be used in any environment like we showed with Model Viewer, or if you need to add interactivity to HTML-based content from a CMS, consider authoring your components using web components. You can start building web components today using the native custom element API shipping in the browser. You just make a class that extends HTML element and register it against an HTML tag name with the browser's custom elements API, and the browser will automatically create an instance of your class and call the lifecycle callbacks on it whenever the HTML tag is created. But since web components APIs are pretty low level, there are libraries that can help you get started a lot more quickly. You can check out LidElement, a web component base class developed here at Google that has a great functional rendering experience very similar to React. You define your properties and then write a render method that returns the components internal HTML as a function of data. So if you're a developer coming from React and want a similar developer experience for creating interoperable components, check out LidElement. Finally, since web components are no longer a niche technology but a built-in part of the platform, many other popular libraries also now support outputting interoperable web components. For example, Angular Elements is a first class feature of Angular that lets you use Angular to build web components. And view.js has a very similar capability. And finally, there's a new class of frameworks like Stencil.js, which are purpose-built for building web components. And finally, openwc.org is a great resource maintained by enthusiasts in the community that's a great collection of guides and tips and pointers for using web components. So make sure to check out all the resources linked in the description below. Thanks for watching.