 Hi, everybody. My name is Mike. And I'm Ziling. I'm a software engineer at YouTube. I work on features and cool new tech. And I also work at YouTube. And I work on web architecture and infrastructure. So we're going to talk about how we use Polymer at YouTube. But before that, let's talk about just YouTube, just for a second. So I know it's kind of an obvious question. What is YouTube? You can ask anyone. And the person will say, well, it's where you go and you watch videos. And it's a popular website. And everybody are using that. Kind of makes sense. But so we know that YouTube is popular. But how popular? We went to Alexa to check. And apparently, we're number two. And unsurprisingly, it means that we have a lot of users. We actually have 1.5 billion logged in users that are using our website every month. And not all of these users are desktop users. And actually, some of these users are never using desktop at all. But still, desktop is one of the largest and one of the fastest growing platforms that we have. Unsurprisingly, people come and watch a lot of videos. How much? One billion hours a day. And again, this is across all platforms. But what is a billion hours? Well, it is 140,000 years. It's not 114, which would be a time before the ice cream cone was invented or an MQ. It actually enough time in one day to go back all the way to the Stone Age. So every time you talk about anything that we do, you have to add that we are one of the largest at doing that, be it just pushing bytes through the inner tube, or maybe image hosting, or a social network, or even a search engine. So hopefully, you get the idea. We're kind of a really big website. So our motto is, broadcast yourself. And that means being inclusive. So we right now offer ourselves in 80 different languages, and this continues to grow. Additionally, we're accessible. And we consider it a first class citizen. That means even if we're building a website from scratch, it has to be accessible from day one. Also, we have to deal with all kind of weird browsers. We have a lot of extensions that are specifically targeting YouTube. And while we're dealing with this crazy world that's happening outside of us, we do the main thing that we want to do on YouTube. We serve our videos. And we do it pretty efficiently, thanks to all the amazing job of many engineers that spent a lot of their time making sure that we do it really fast. Actually, it takes us less than two seconds worldwide to start video playback. In Denmark, that's 1.5 seconds on the median. Way to go, Denmark. Anyway, YouTube is a very huge and a complex project. And by no means it is a monolithic website. We have dozens of internal and external mini websites that fulfill different roles within the YouTube ecosystem. And also, YouTube is, I think, 12 years old right now, which means that we have over a decade of engineering decisions. We have over a decade of codes that we have. I mean, we rewrite the code from time to time, but still we're talking about more than a decade. So we found this post on Reddit that we want to share with you. I'm fairly certain that in the eight years, since Google bought YouTube, that very little of the original code remains. This guy has a lot of faith in us. So the thing is, when you spend 12 years working on something, you end up optimizing that product. And despite having this very large code base, despite working on it for so long, it is a very highly efficient platform because a lot of clever engineers spend their time working on this platform. Yet, we realize that this platform has limitations. And at some point, these limitations became too obvious for us. We were hitting some of the performance limitations that we were unable to overcome with the stacks that we had. And we were hitting some of the engineering problems that were unable to move as fast as we wanted to do. So we started to think, how can we make things better? How can we move forward? And what will be the next thing that powers the YouTube? So what did we have? What was our starting point? We have a server-side rendered application. And we always render on server-side. This happens even when you go through pages. And when we do an Ajax navigation, all the magic still happens on the back end. We built a lot of homebrew frameworks. They're not real frameworks. It's more like tools that we build for our products. We do have homebrew frameworks for JavaScript. We do have them for styling. We do have them for layout. So basically, we build things that fit our needs at specific time frame. And the thing is, we're looking for something that would be a little bit more modern than what we had before. And we had a couple of goals. We had a couple of restrictions of what we wanted. We have a couple of requirements from the framework that is going to we use a framework or a library. We wanted a lightweight framework, and both in terms of the size that it will add to what we have and in terms of the footprint on our ecosystem. We wanted something flexible. We didn't want a framework that would force us to do things. We have a lot of unique challenges. We have a lot of unique business reasons to do things some specific way. So we didn't want the code to be in our way. We knew that component model is what we really, really want. There are a lot of benefits of using components. And you can look at these benefits from different angles. There are benefits of organizing your code as a component just because everything is very localized. There are benefits of deploying and building application as a set of components because by doing that, you create clear boundaries. And then if the framework can provide you with encapsulation that happens on the clients, that's even better. So we wanted components. We wanted to iterate fast. And at some point, we realized that what we had was good enough that way our engineers work is not efficient. We want to be faster. We want to build new cool features. And when new engineers join our team, we want them to be able to get up to speed faster. We don't want them to spend a lot of time learning. Also, we didn't want to stay with a stagnant technology. And we wanted to do as few infrastructure work as possible. It's always very beneficial when you have a team of specialists working on the platform that you build your application on top of. So we wanted to be able to work with the platform and build relationships and feedback loops that are beneficial to everyone. After all, YouTube.com runs on the web platform. And the health and growth of that platform is good for YouTube. Also, this is kind of a big surprise. But we had a very direct and simple order from our president to make YouTube great again. And that is a real tweet. We don't know why, but that was pretty obvious. And we did. Anyway, back to reality, we had a lot of requirements, a lot of features, a lot of processes at our website. We do things specific way because YouTube is an existing product. It's been live for a long time. We had to make sure that whatever we do next will help us to transition into a new world, not break it. And we looked at Polymer. We actually looked at many different frameworks. And now, because we are here at the Polymer conference and we're talking about YouTube at Polymer, it kind of makes sense. We picked Polymer. It wasn't that obvious when we just started because Polymer was actually not the first choice on the list. But as we went through this list, as we checked the check boxes, we realized that other frameworks, while great and sometimes fulfilling a lot of the check boxes that we had, not necessarily give us the flexibility and the full picture that we wanted. And also the Polymer at the time was just metering enough. It was going from 0.5 to 0.8, I believe. So it took some time for us to get used to the idea that we're going to use Polymer potentially. And just going and rewriting YouTube in Polymer, that would be too crazy, even for us. We didn't want to do something that big. So we wanted to try something smaller. We started with some tiny experiments, some tiny internal tools. And then after that, we launched YouTube gaming. This happened about a year ago. It's a variation of YouTube that's focused on videos and live streams of games. Afterwards, we launched YouTube TV. This is recent in the last few months. YouTube TV focuses on TV streaming and DVR. These two are both complex projects with a large user base, but they're not on the scale of YouTube.com. Also known as one of the largest Polymer deployments in the world, because again, YouTube, we do everything at this crazy scale. And building all these amazing websites gave us an opportunity to learn. It gave us an opportunity to polish our infrastructure, develop best practices. And at some point, we finally realized that maybe it's now the time to do what we planned all along right from the beginning. And we announced that we're launching or we're building YouTube on Polymer during the last Polymer Summit. And we're actually launching YouTube on Polymer. And I don't have an exact date, but we're this close to doing this. We're excited about that. And this is going to be the largest Polymer deployment in the world, obviously, because this is YouTube and we do everything at scale. I mean, we're pretty confident it's going to be the largest one. I really hope. Some of you may have already seen articles or have even tried it. The important thing is YouTube is available for Optin right now. Yep. You just go to youtube.com. There is a big button right in the middle of the screen. You press it. You get the new experience. And also, please, there are a lot of articles on the internet talking about how you can edit cookies, and everything will be great. Everything will not be great. Don't do this. It's not the right way. Just go to youtube.com slash new. So what is it made of? Well, the site is 100% Polymer. And by that, I mean, from the app tag down, you can inspect the site. And you can see all the components right there. We have about 400 components that are just YouTube specific. More than 1,000 components across all the code bases. And we are happy that we can share a lot of our components across different projects. So let's talk a little bit more about how we use Polymer at YouTube. But before I go into that, let's take a small step back. And let me explain to you that we have this thing called, it's our Universal Data API. And it kind of shapes all the applications that we build. Keep in mind that YouTube runs on everything. Also, following a very sophisticated naming process, we internally called it InnerTube. So here's a small set of apps that run on this Universal Data API. And we're not just talking about web. We also have apps on iOS, Android, game consoles, TVs, and of course, different verticals. We have apps for kids, apps for creators, apps for TV, apps that replace your TV, that run on TVs, and everything. And all of these run on this Universal Data API. So what does it look like? Well, what we ended up with is a presentational API, which is an API that structurally kind of defines how your page structure will be based on the data response in JSON. And we found that this structure maps really well to web components. As each web component receives data, that data defines the children that that web component will render underneath it. And then in that component, it takes a subset of the data, some subtree, and passes it down to the child. This continues until you hit a leaf node. And while doing this, we realized that what we do is render a lot of lists. In fact, YouTube's a bunch of lists. You may think that we serve video, but from a web framework side of view, what we do is draw lists over and over. And these lists are super dynamic. The machine learned, they're experimented on, they're ranked in their massage. And every single time that you come to YouTube, these lists are re-ranked, re-experimented on, and it's going to change. Also, if you're a list fan, I told you so moments. So this is a standard YouTube channel page. There's some obvious lists here if you think about it. But I'm going to highlight just a few to make it a little bit more obvious. There's menus, they've got navigation bars, search results, subscriptions, horizontal shelf video lists, lists of horizontal shelf video lists, and again, these change. They're dynamic, and every time you come to the site, we've got to redo it. Also, we had to stop at some point, and this is not all the lists we have, but the screenshot became too crowded to actually show all of them. So because this is so important, we spent some time and optimized our list rendering. We do some of the basic stuff that's pretty well-known now, DOM diffing, efficient reuse of the DOM, but we also do other things like signal-based deferral. That means that we can block some of the content rendering until we get a specific signal, and to name a few, we can wait for the content in the viewport to appear, or we can wait for the video to start playback. As well as doing that, we also do lazy and budgeted rendering. To explain that, I have kind of a simplified view of how the render thread works. People think you play video, you know, you go fetch some video bytes, you give it to the browser and video plays, but YouTube's not that simple. We do adaptive bit rate, we use dash, that means you have to use the media source extensions, which means the render thread kind of looks a little bit more like this. This is still a simplified view, but you got to fetch the audio bytes, the video bytes, you got to initialize the video API, you got to append those bytes, and then at some point, video starts playing. And so you can see that the render thread is actually fairly busy handling asynchronous events, and then you introduce UI code. UI code can take a lot of render thread time, and so in this case, you get these squiggly lines. And what those curved lines mean is that we're not able to receive an event on the render thread as fast as we'd like it to be. So how do we solve this? Well, with the scheduling system that we have with lazy rendering and budgeting, we try to break up our tasks, our UI code into small chunks and fit it in between the time that these events come back. Also, we're cheating a little bit on screenshot because this screenshot, well, there are no user interactions here and our users tend to do all kinds of weird stuff like typing or scrolling or sometimes resizing the page. And while that obviously can affect the performance, splitting our UI into smaller tasks allowed us to have as high FPS as possible in these cases. Also, I mentioned scheduling. We have a global scheduler on the YouTube website and also deals with priorities. This is very important because not every single piece of code and not every single piece of UI is of the same importance. So let's say you come to the YouTube watch page. The most important thing for us is that video. This is the thing that we want to prioritize over all other elements on the page. But following that, we have things like the watch next. This generates a lot of watch time on YouTube, so we want to render this next and we do this in a lazy budgeted format. Some things then are actually extremely deferrable like my comment here. Also, we know that YouTube comments doesn't have the best reputation, but they're kind of still important. They've gotten a lot better. Basically, list rendering, it's a foundation of performance at YouTube. So let's talk about the development process. How does it look from inside for an engineer working for Google? Well, the cool thing about having components is that as long as you can render this component, as long as you can create it separately from the rest of your application, you can bypass a lot of issues that we had before. And again, YouTube is very large, bringing up the development environment to work with YouTube, take time, and take resources, and being able to just take one component and then test it separately or create a demo or feed it with some data to put it into a specific state is critical for development process. So this is an example of a component and the image on the left is what the engineer created. This is components that consist of some other components, but the pictures in the center and on the right is the two special flavors that are created automatically unless the engineer wants to change them in some way. And the middle screenshot is the dark mode. Also, I will highly recommend trying it on the new YouTube. And the right image is the RTL, so right to left version of the website. And all of these versions of the component are being tested, screen-shotted separately. So you can see here, there's some changes on this component. It's not very obvious just looking at it, but once we add screenshot dipping, we can tell that things have shifted down, some padding has changed. This is a level of testing that has never been possible at YouTube before, but we've really embraced it and it's a core part of how we develop now. In addition to that, we took this granular component and testing approach and took it a little bit further and we created something called Storybook. And what Storybook is, is a way for you to interact with the component during development. We have here a Storybook for something called the video list cell. And on the left of that Storybook, or the component, is a list of stories that have been generated. This is either a fixture that we saved before or some data that was automatically generated. And this allows you to kick up a Storybook and then click on any of these stories and you can see your component rendered in that state. This is pretty much one of the best ways to interact with the component during development. But moving further, we integrated Storybook into our internal Polymer catalog, which is another way for you to bring up a component without needing to type anything in the command line. You can search for a component and bring it up in any time in its commit history because we've integrated this with our version control system. You can browse the documentation, you can bring up the Storybook, run unit tests, and look at the API and all that stuff. Also, all of these tools are Polymer projects. So welcome to the component inception because the Polymer dashboard is a component or a set of components rendering a Storybook which is a set of components, rendering a component which renders a lot of lists. So what's the state of Polymer at YouTube? We've mentioned that we have over 400 components on YouTube.com and over 1,000 components across our properties. So we have a data model that maps really well the web components. We have a highly optimized list rendering system and we have a suite of component level testing and debug tools. But there are a few things that we're still trying to bring up to date. Which probably not a big surprise from a website that just dropped IE9 support. So we're still on Polymer 1.x. We got a lot of stuff to migrate and we're moving to hybrid elements which have made it a very easy migration path. We're really excited about Polymer 2. It has a lot of increased flexibility and extensibility that we're looking forward to. And we're still on Shady DOM. So YouTube's a little bit more conservative when using these really cutting edge APIs. So we're still reliant on polyfills but we're really excited about Shadow DOM and we're moving our tools and our infrastructure to support this in the future. So to wrap it up, we feel like we're building for the future. We finally have modern tools and we're working with a web platform and we help push the web forward. The site is now faster to iterate on and we have much better test coverage than we ever had before. And while this is partially thanks to the major rewrite, Polymer played a major role helping us organize our internal workflow. Overall, the site is faster. That's up to 15% faster depending on the page. And developers are happier. We finally share components across our projects and we're using a standard stack instead of developing everything by ourselves. And we can't wait to start shipping all these cool new features after we launch. Thank you. Thank you everybody. Thank you.