 to get to present to Ember Kampf in spite of the circumstances, not getting to actually be there. Still really glad that the show has gone on. I'm Nicole Sullivan. I am Chrome's PM of the Frameworks, and I'm here to talk a little bit about Chrome and Frameworks collaborating. Now, this was always going to be a talk about collaboration, but with everything going on in the world right now, I didn't feel right to talk about collaboration between Chrome and Frameworks without pulling in the larger context. Now, I want to give you a content warning. I am going to talk about COVID-19 a little bit, so if that's not something you want to hear about, probably want to turn off the video. Difficult times call us to pull together even more. For example, in China, they built a hospital in 10 days to accommodate folks with coronavirus. Let's see them do it. I find it incredible the number of cranes they have operating all at the same time. I, in a former life, was a carpenter, but I was never on a job site with more than one crane. You can see it looks like they're also building the pods that it's made of off-site so that they aren't taking up space there to build the pods as well. It's a very, very efficient way to build, very smart. And obviously, they're keeping the job site going day and night. It's an incredible amount of activity happening and how relatively coordinated it is. The roof tiles are pretty interesting as well. As a former carpenter, really impressed. I was never that good. So another example of collaboration is the Wuhan Medical Workers who worked tirelessly to heal their patients. This is the medical staff celebrating the closing of one of the temporary hospitals. Recently, China reported just 11 new cases and so they don't need temporary hospitals anymore. One thing I think is that we need to heal our institutions if we're going to face the challenges in front of us. This applies to the web as well as to the world. Now, those things that I showed you are big things. Building a hospital in 10 days is enormous, but I've also seen a lot of small kindnesses too. There are so many beautiful things that people have done. I tweeted this yesterday. Is it just me or are people being decidedly kinder to each other right now? I believe healing begins with kindness and the virus calls on us to be more collaborative, more caring and to look out for one another. Chris Martin of Coldplay said, it feels like right after 9-11 there's some kind of solidarity. He did an Instagram concert for fans stuck at home due to the crisis. I'll let Laura Bonanti, a Broadway actress with five, Tony nominations speak for herself about the kindness that she did in her own words. Well, this is all insane. Very few people are at work. Most of my stuff is getting canceled because I'm in the business of being around a lot of people as most of us are. And this may seem silly, but I know that a lot of high schools were going to have their musicals and those musicals got canceled. And that is a bummer because I know for so many of us, I know for me, my high school musical was like a lifesaver. So if you would like to sing a song that you are not going to get to sing now and tag me, I wanna see you. I wanna hear it. Stay safe, everybody. So that's her reaching out to high school students who missed out on their opportunity to participate in their high school musical. Another person, Max Barnett, who is an Oakland author right near me, realized how hard it is for parents to work whose kids are out of school, basically indefinitely. And he decided to do something about it. Every day at 12 p.m., he's reading one of his books. Oliver Jeffers offered to read one book a day until it's safe to go outside. And this is an example of his beautiful illustrations as well as this other illustration that he did, reminding us that when it comes to a virus, we're all only as safe as the least among us. He's right, now more than ever, we should think we and not me. Another artist, Wendy McNaughton, who does these incredible illustrations and infographics is offering up drawing lessons to kids. And I'd like to put out there that you who only are recording all these talks and putting on a virtual conference, it means an awful lot that you and the rest of the team would work this hard. So this spirit of collaboration is something the web platform needs to. And so I'd like to look at what's happening there and pull it back into what we can make a bit in the web platform. Sometimes I wake up and my Twitter notifications are through the roof. And like so many that they put the little plus icon in there and stop counting. And I feel nervous. Did I tweet something? Did I tweet a mistake the night before? Did I tweet something impulsive that I shouldn't have? Or has the world blown up again around web components and frameworks? I just can't with all that. I completely understand why people get angry, but Twitter wars about web components never go anywhere except they go on and on and on for days. Let's just start by recognizing that frameworks are part of the web platform. If you're using a framework, you are using the web platform. And we really want your feedback. This hasn't always been the case that there were many avenues to give feedback, but we're really interested in it now. If there's anything you hear about happening on the web platform and you wanna figure out how to get involved, feel free to contact me. Stubbornella is my Twitter handle and it is actually the best way to get hold of me if you want a quick response. So please don't hesitate to reach out. So Chrome has changed. Working with frameworks like Ember is now a core, blink and web platform objective. It's in our yearly goals. We succeed if you succeed. We also hired a frameworks PM, that's me. We added feedback from framework authors to our release process. It's one of the steps that our engineers need to follow. Very senior blink engineers are reaching out to the community and we have several teams dedicated to working with frameworks now. For many years, Chrome tried to build a framework around web components. When I started working in the space, we had the realization that having a framework under the Chrome umbrella meant that we were competing with our best partners. So what did we stop doing? Polymer was sunsetted before I joined. We recognized that our effort in that area never really saw significant adoption and didn't really meet the performance goals that we had in mind. So it was time to make a change. But what do we do next? I reached out to a few framework authors before I started and asked them for their wish list for the web platform. And this seemed like a pretty good place to start because we got lots of good feedback there. We started collaborating with the React team, hoping that it could spur innovation that the whole ecosystem could benefit from. We can put resources into figuring out the most efficient ways for frameworks to do certain things that they need to do and then other frameworks can learn from that and figure out how it should work in their world. We started having weekly meetings and we had some offsites together to design a scheduler. It's been pretty fascinating to watch a cross team collaboration actually happen. So now we collaborate to make the web awesome and we recognize that this is actually what we wanted the entire time. This couldn't have happened without framework authors generosity and being willing to give second chances and a new start. So I'm personally very grateful. Thank you, Yehuda. I know it was hard at first. So if there's anything I brought to Chrome it was the understanding that frameworks and the web platform are two halves of the same whole. When we work together outcomes for both developers and users are significantly better. We're really excited about continuing to collaborate with frameworks, particularly around performance. So one honest piece is that performance outcomes are actually not great for everyone. They're great on my iPhone but they're not amazing on a lesser phone in a bad network or flaky network, particularly in emerging markets. And that's something we care about because that's where the web needs to grow. Now I want to put to rest the idea that one framework is that much faster or significantly better than any other framework. I'm not going to tell you which ones which in this chart but you can see that there's not a huge difference in performance between them as well. You'll notice they all have a pretty big difference between their time when they show pixels which is the two blue lines roughly and the time to interactive which is when the user can actually click on and interact with things. So yeah, I think that the sort of framework wars back and forth don't actually make a lot of sense. There isn't a huge difference in performance here. And to get these numbers, we did a survey of over four million domains. And so we wanted to make sure that it wasn't a benchmark or something that could be inaccurate or overemphasize something that is not as important. So I'd like to propose a shared goal between framework authors, application authors and browsers. Users want amazing features and great performance. We will make it so. The community is already building amazing features. So I'm going to focus on performance. I honestly think that building amazing features is part of the reason why they choose a framework in the first place. It allows them to get up to speed quicker to release features quicker and to be able to release more sophisticated features because they're not spending all of their time on underlying code. And let's be clear, frameworks sometimes make web apps slower but they're also our best hope to make them faster. Why do I say that? Standardizing things is actually fairly difficult. You have to have a lot of consensus you have to make sure it's going to work in every single browser. Sometimes we can't get to the end state of the API of our dreams in the browser itself. But frameworks generally speaking have more flexibility in regard to that and can take advantage of a lower level API we built and then build something on top of it that makes it easier for their users to consume within the paradigms that they're already used to thinking about. So let's just stop and look at what do users want in the first place? The first thing they want is to see pixels fast. The next thing they want is for the page to be interactive fast. And the third thing they want is it to be fast to get to the next route once their page is already loaded or whenever they're ready to go there. For pixels, we're kind of doing okay. A combination of server-side rendering or statically generated pages does an okay job here. It can be complicated to do well if the page is very complex or if data backends are slow. We also probably don't want to fetch all of the data in order to be able to put any of the page in front of the user. That's something we'd like to disconnect. I believe in the ember world that's the thing to check out is fast boot. So paradoxically, when we show pixels quicker, the longer the page looks ready but isn't actually interactive yet. Rage clicks are something that happen when users click over and over and over again in frustration and waiting for JavaScript to do its thing. One of the fundamental goals of the browser is to handle user input instantaneously. So the page needs to be ready, at least the parts that the user is going to interact with. Let's compare a single page app on the top and a multi-page app on the bottom. The rectangles represent the load time of an individual view, page route, something like that. Obviously the sizes are completely made up. It's just to present a point and propose an understanding. So you can see that there's a UX trade-off being made between the initial and subsequent loads. The single page app has a slower initial load and then very fast subsequent page loads. The multi-page app has a somewhat faster initial load and then they see that sort of first impression experience and then the subsequent pages are still pretty long. So we have some pretty good perf measurements for the first page load that tell us the time to pixels on the screen and interactivity. We really don't have very good single page app metrics for hydration time and transition timing. So what that means is that you've been grappling with UX trade-offs that our metrics don't capture. I also think we're asking too much of application developers. When you're working on an application, you have a day job building features. I think what I see is application developers care a lot about things like accessibility and performance and semantics but often aren't particularly a lot of time to work on them. And the trade-offs and complexity are actually pretty hard to navigate. How do you make your application code yield every few milliseconds within the context of a framework that doesn't have that feature or it isn't turned on yet? That's pretty hard to do. And so I actually think that this presents an exciting opportunity for frameworks and web platform to collaborate. We both want application authors to be successful out of the box and there are things that are easier done in a framework and then there are other things that are easier done in the browser. And when we work together to define the line between the two, application developers win. So let's talk about Ember specifically for a moment. I would level with you a lot of what I'll talk about. Ember already has done but because of the differences in how people define a framework, most folks weren't thinking about it that way. I'll give you a nice example. On the left here I have UI frameworks. Their main job is updating the view and making sure the view reflects the model and the data that you have available. On the right I have SDKs like Next.js, Knox, Gatsby and those are more responsible for the server client integration and the lifecycle of an application. Honestly, they're responsible for a lot more of the performance piece of the puzzle than the UI frameworks are. Then what do we do about Angular and Ember? Because they actually kind of fall into both camps. They are a UI framework and library. They definitely take care of updates to the view. And they're also an SDK or a CLI that does similar things, basically setting up routes and doing that server client integration. So that makes it a little more complicated to compare these against each other in a meaningful way. So given the complexity there, why should Chrome invest in the framework ecosystem? Why should we spend time improving these tools? To take a look at this, let's look at some data. First from an MDN survey. They did a survey of developers and designers. It's reached almost 30,000 people who responded to it. And we found that 72% of developers use React, Angular or View. So that's huge. It's clear that developers are choosing to use frameworks. More than 12% of time spent on Chrome are on pages that use a JavaScript framework. Again, 12% may not seem huge, but it actually, it really is an enormous leverage point. In the top 100 URLs by time spent, if we look at React, View and Angular, we see that 30% of users' time is spent in applications that use those frameworks. What the difference between time spent and page loads shows us is that, well, for one, the frameworks are more likely to be single page apps, but also users are spending more of their time. And so the applications that are using frameworks are more important to the user's day. Once you add internal Google frameworks, bootstraps, sorry, backbone, and some other things, it grows to 41%. And then if you add jQuery, it grows all the way to 73%. Now you can argue whether jQuery should be included in the framework bucket because it is a little bit different, but it's worth looking at the data. So what is Chrome doing to help? We're collaborating on answers to many questions. We're researching lots of things, we're testing it with partners, we're making sure that everything we're doing works in production before we ever recommend it to anyone else. So some of what we're working on right now, each thing is in different stages, is loading code and data, scheduling important tasks, contributing metrics that properly capture hydration time and single page app transitions. For the moment, we've contributed that to Next.js. We're going to get a bunch of data back about what we see there and verify that those metrics actually make sense and will work in a broader context. Ember has these sort of metrics built in. So again, really lucky to be working on a framework that has had this sort of thoughtfulness around performance. We're also looking at routing, that is in a much later stage. We're excited about Mozilla shared libraries, the idea that if everyone is using Moment.js, why do we need to have multiple copies of it? Could everybody not share one copy of Moment.js since it is used so ubiquitously, it wouldn't really give away any user data. We're also interested in conformance tests so that's no when they make a mistake. We feel like the code review is too far out to figure out that you made a mistake in building the application. So we want to add conformance tests that catch common errors, like you're blocking and loading your CSS too late and so the page is just staying blank and it's pushing out your largest contentful pane, that kind of thing. We've also done a bunch of improvements to BundleSize that we're pretty excited about that shipped in Next.js and are actually webpack improvements and so they're getting accepted by Gatsby as well. And I've heard a little bit from you, Huda, that he's excited about this stuff and that he might consider having your underlined tools use webpack so that you can also take advantage of those same heuristics. And then we're also collaborating with Microsoft to bring form controls from 1999 to 2020. So frameworks are bringing the power of tools like of companies like Netflix, LinkedIn, Facebook or Google to the open web. We want those solutions to work for everybody but that's very complicated to do because open source tooling is fairly complicated. Our goal is to prove that it can work in Next.js and react and share what we learn with the entire ecosystem of frameworks. We also learn from each of the frameworks which each one has its specialty, the thing that it's best at and we've been able to take in a lot of information about what frameworks have tried already and where we might go next. We also see that y'all copy from each other and I think that's great. That's the kind of collaboration and inspiration that will make us all take a step to change improvement in the user's experience of the web. So the web is essential for so many things including the kind of sharing that allows people to take what they want, what they do well and share with people around the world in a time of crisis. So I grew up in a tiny back then very isolated community on the main coast. It's a little island and you had to drive 45 minutes to get to a traffic light. It's a rugged community that deeply cares about each other and understands that it's thanks to both our independence and our interdependence that we thrive. I remember at some point I realized I had read all the books in the library that interested me. There were no more. I think a lot about what it would have meant to me as a child to have all the world's information available to me. Because of the internet, the island is no longer isolated. I watched the local basketball games online. I find out who won the lobster boat races from the local paper and I stay close to my sister in spite of the distance. I haven't been back in years but it doesn't seem all that far away. The web is an incredible equalizer when for the price of a phone plan someone can discover that they're not the only queer kid. Be inspired by beautiful art even if they never set foot in a plane or educate themselves even if the library doesn't have any more books. So when I try to do its right for the web platform part of me is doing it for that girl standing in the library hoping to find another book. The thing that we're making here, it matters. It's really important and browsers can't do it alone. We need to walk shoulder to shoulder with frameworks, tools, SDKs, application authors. The web needs to be fast to be healthy and together we can make it so. So I encourage you when you turn off the video to think about what you uniquely bring to both the web platform and the COVID-19 crisis. Try to think about three things. The first is someone to listen to. The second is something to learn and the third is something to give and whatever you do, please stay inside and see. Thank you so much.