EmberConf 2020 - Closing Keynote
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Sullivan, Nicole
Closing Keynote by Nicole Sullivan
 Hi. I'm really glad to get to present to Emra Kampf in spite of the circumstances, not getting to actually be there. I'm still really glad that the show has gone on. I'm Nicole Sullivan. I am Chrome's PM for frameworks. 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. There'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 work 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. 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. This may seem silly, but I know that a lot of high schools were going to have their musicals and those musicals got canceled. 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 want to see you. I want to 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 pm, 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 thank we and not me. Another artist, Wendy McNaughton, who does these incredible illustrations and infographics, is offering up drawing lessons to kids. I'd like to put out there that you who'd 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 of it 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 that I tweeted 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 want to figure out how to get involved, feel free to contact me. Stubborn Ella 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. That'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 for them for their wish list for the web platform. And this is 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 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, Yuhuda. 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, 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 one's 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 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 Ender 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 happens 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 that 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 in the 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 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 an 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, Nox.t, 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 the MDN survey. They did a survey of developers and designers. It 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, the 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 bigger 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 bundle size that we're pretty excited about 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 that he's excited about this stuff and that he might consider having your underlying 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 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 it 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 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 stayed 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.
 Hi. I'm really glad to get to present to Emra Kampf in spite of the circumstances,  not getting to actually be there. I'm still really glad that the show has gone on.  I'm Nicole Sullivan. I am Chrome's PM for frameworks. 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.  There'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 work 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. 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. This may seem silly, but I know that a lot of  high schools were going to have their musicals and those musicals got canceled. 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 want to see you. I want to 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 pm,  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 thank we and not me.  Another artist, Wendy McNaughton, who does these incredible illustrations and infographics,  is offering up drawing lessons to kids. I'd like to put out there that you who'd 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 of it 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 that I tweeted 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 want to figure out how to  get involved, feel free to contact me. Stubborn Ella 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. That'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  for them for their wish list for the web platform. And this is 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 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,  Yuhuda. 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,  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  one's 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  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 Ender 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 happens 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 that 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 in the 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 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 an  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, Nox.t, 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 the MDN survey. They did a survey of developers and designers. It 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,  the 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 bigger 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 bundle size that we're pretty  excited about 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 that he's excited about this stuff  and that he might consider having your underlying 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  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 it 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 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 stayed  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.
Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_0_2135.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_2136_2339.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_2340_2771.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_2772_3251.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_3252_3923.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_3924_6071.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_6072_7451.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_7452_7631.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_7632_8339.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_8340_8747.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_8748_9419.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_9420_9707.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_9708_16403.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_16404_19979.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_19980_21491.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_21492_21971.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_21972_22259.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_22260_23807.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_23808_25967.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_25968_34355.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_34356_36191.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_36192_36311.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_36312_38183.png Virtual_EmberConf_2020__Closing_Keynote_by_Nicole__ffiDfGkZyhk_2_38184_39686.png