A story everyone. I'm told. I need the Web framework team here and Google and yeah, this is sort of a surreal experience and definitely not how any of us or myself expected to be attending Engy Comp 20/20. Like Aaron said, I'm coming at you from the beautiful state of Hawaii where I am and still a little dark, but I'm excited to be here today. And G comp is always one of my favorite days of the year. And I know that our team looks forward to energy come every year or two, not because we get to talk about the work we've been doing, but because we get to hang out with all of you and our community. And so I know I speak for the entire team when I say that we all wish we could be together in person. And first, I want to extend the team's thanks to the Energy Cup organizers putting on a conference. And normal life is super hard and changing everything during a global pandemic to pull this off online is just no small feat. So we are so grateful for your effort. I know a bunch of you stayed up all night last night and from our hearts. Thank you. Thank you. Thank you for all the work you've done. It's also been super hard to figure out what to say today during what is an extraordinary time in our world, and we're all dealing with Cauvin 19 and the impact it's having on our families and our communities and the angular team is no exception. We, along with all of our Google peers, have been spending the past month shifting to a new way of working where we're working fully remote. We've been getting our home offices set up. Some of us are working in an office. Some of us are working from their garage. And others are working from the front seat of their car in their garage. And our priority over the past month has been to figure out this new way of working and figure out how we collaborate within our team as well as across Google. And fortunately, the angular team has a lot of experience as a distributed team. We've always had team members and contributors that live across the globe. And we have many tools that support virtual work like Slack and get Hub. So all in all, we've been doing pretty well and we even released Angular version nine point one last week. Personally, I've been enjoying getting to see all the home cooked food that gigglers make since they're stuck at home meeting the babies, kids, spouses, pets and roommates who join our meetings. Sometimes they do it on purpose. And there's been a few times that it's been completely by accident. But we also have team members dealing with kids home from school illness or supporting their families and communities. And we have some team members that are working on Koven 19 related projects at Google, as well as in our open source community. The times that we're facing, our unprecedented. And I'm encouraging all of us to prioritize the time we need for ourselves and our families. And I also want to thank the team for showing up every day during this crazy time and doing hard work as well as the community for coming together and getting involved. We've seen just an explosion of collaboration between our contractors, our contributors and community leaders meet up and event organizers and our GDP team. We're literally seeing the best of humanity come out. We think each of you for supporting each other, supporting our team and angular itself. So normally I'd be up on stage at a paid way, more attention to what I'm wearing. And I'd give you a bunch of updates and metrics, but somehow today that just doesn't feel right. With the world upside down and all of us behind these computer screens now more than ever, it's important for us to connect as humans. So today, instead of doing all those updates and metrics, I'm going to share a little bit about more more about me, why I'm here and what I've been up to at Google. So first first joined the angular team back in 2015 as the leader for developer relations team. I was super excited by what I saw on Angular and how companies could benefit from it as a general person. I spent most of my time listening and talking to the community and then taking everything I learned from all of you and influencing angular product direction. After a couple years on the team, I took a break to guide my children through the end of their high school to graduation and then off to college. And just as I found myself facing empty nest, I unexpectedly had the opportunity to come back and lead Google's Web framework efforts. I had this opportunity to bring the angular team and our internal framework team named Wiz together. And I looked at that chance. It seemed like the perfect timing in my life to take on this leadership role as these two amazing kids of mine ventured off into the world. And although he's gonna be angry with me in about two seconds, I can't help but give a shout out to my son Gavin. We were supposed to be attending Engy Comp together this year. So hi, honey. Call your mom. As a leader, my focus is on understanding the team's overall health and how to best serve our developer users, both internal and external, to Google. And I'm a firm believer that as a leader, the most important things that I can do are to listen, observe and ask questions. And while I was familiar with Angular and I knew most of the people on the team, I needed to find out what I didn't know. When I returned and I needed to form a fresh new perspective. So I held listening sessions and I observed the cadence and culture of our meetings. I took a look at how our planning works and how the team was thinking about product strategy. I wanted to understand angular its community, where it had been and where it was going. My laptop often looked like this at the end of every day, covered in notes and reminders of things I'd seen or heard during the day. So while the team was working on getting angular Version nine released, I began charting a course for what would come next. In addition to all of our technical goals and our product goals, one important story that kept coming up was that our leads were wearing just too many hats. They could be great tech leaders or they could be great engineering managers. But trying to be both was a near impossible task. This is Jen. She is an experienced engineering manager who's joining us from the Ways Team. Jen has years of practice building and developing great teams inside of Google. She's bringing new ideas on how we collaborate with each other and how we learn from each other. Jen has already rebooted the planning efforts for our next versions and has set her sights on how we have more transparency in our roadmap to all of you. Jen is just getting started and I'm looking forward to all of you getting to know her. We've made some other important investments for Angular. We know how critical documentation is to understanding angular. We recently hired a lead technical writer. They'll be focused on making angular easier to learn. And they'll be working with angular writers in our community that you might already know, like when a Hailie. And we're working with product management to better understand the Web framework space, as well as how developers use web frameworks. And a new collaboration we're initiating with our data science team is teaching us ways to understand data signals and then incorporate those into our overall planning. All of these things we're doing and are focused on ensuring that we build an angular that works for everyone. And sparks a little joy. So just as we did with the core team and I want to take a hard look at Angular from the ground up and in every direction, and that includes the community. So we want to listen to your stories as well. We heard that you want to contribute to ANGULAR, and that's not so easy to do today. We heard that the volume of issues makes it challenging for you to understand when a change you might care about is coming. And we heard that you want a closer relationship with the project overall. So in the coming months, we'll be working on ways to build these connections. And we're going to start today with our survey. So if you haven't had a chance to take our 2020 survey and buy you to do so now, well, maybe not now. Wait until after an energy cougher during the break. One of the reasons that I was drawn to the ANGULAR originally was because of my background in the enterprise space. I spent the majority of my career here building enterprise software when I was a new mom. I was a software engineer, building enterprise solutions. When I returned to work full time, I worked at Microsoft as an enterprise developer strategist and in my first role at Google I led enterprise strategy just as technology was moving to the Web. And this experience has led me to hold a strongly held belief, which is that Google is just another enterprise for angular or enterprise customer for angular Google developers build the same types of apps that you all build. They build consumer based apps, small apps that grow to medium apps that grow to large apps. Some of those apps are on the public Internet. Others are behind the firewall. Some have large development teams and others are built by just a handful of people. Some apps are in maintenance mode with all the complexity of a legacy code base and all the demands of new features. And while Google engineers might use a slightly different tool chain or deploy slightly differently, the used cases are primarily the same. And so there's this intersection of concerns. And it is in this intersection that we will be focusing on. So that what helps Google helps the community and vice versa. There is now part of an organization called Core Developer at Corda. We're focused on building the best infrastructure for Google engineers and we are committed to the open source projects in our portfolio, which includes ANGULAR. Our leadership team is very vested and angular success. We have a brand new V.P., Michael. He's so excited about Angular that when we launch a blog post, I can count the minutes until I have an email in my inbox from him. Near the end of last year, we announced that there were more than fifteen hundred projects using Angular at Google. Today, this number is over two thousand and angular powers, many great experiences both inside and outside the company. We're continuing to work with teams like Google Analytics, Firebase and Google Cloud to work on new features. And we have seen tremendous success since we landed Angular Version nine externally. More than 10000 public domains have already adopted the latest version of ANGULAR. And we continue to see success with our strategy of making updates easy. On the eve of the release of nine point show most public apps. We're already using the latest version. Since twenty eighteen, we've been serving thousands of developers about Angular. And while that 2020 survey isn't quite closed yet, it looks like we've continued the positive trend, with developer satisfaction increasing 31 percent over the past two years. I joined Angular originally because I was excited to work with a team who understood that engineers outside of Google mattered. I rejoined the angular team because I was excited to have the opportunity to not only leave the team, but to be back here with all of you, this amazing community that treats each other like family. I've seen proof of that over the past month as we face this crisis in the world, as we've moved energy comp online and in so many other ways. And as our team goes through this time of growth and evolution, I know that we need all of you on this journey with us and that together we are gonna be more than fine. We are going to be freaking awesome. So thank you for your time this morning. Thank you for being here with us. Thank you for believing in all of us. And now I'm going to hand it over to care Eriksen, who is the technical lead for angular framework. And she'll be going deeper into angular version nine Cara. OK, great. So, hello, everyone. I'm Cara. As I mentioned and I'm here to tell everybody about what's new and angular version. Then Version nine came out on February 6th of this year. There is a lot to be excited about with this latest major. And today I'll be giving you a tour of the features that I'm most excited about for version nine. And you may have noticed that our version nine dot one release also went out last week. So we'll be discussing some of the features that are nine dot one as well. So let's get started. So one of the biggest features in Version nine is the release of Ivy. If you haven't heard of Ivy, it's the new rendering engine for Angular. And it was released in preview mode and version eight and version nine made it the default experience. We are over the moon. The ivy is finally out. It represents a huge effort from the angular team, given that we had to rewrite both the compiler and the runtime completely from scratch to get the characteristics that we wanted and do it in a way that was as backwards compatible as humanly possible. We've essentially spent the last year polishing and grooming Ivy to cover all the corner cases because we really we care deeply that the update experiences as seamless as possible for regular golfers. So this was undoubtedly a big project, but we were willing to invest the time to get it right because it came out of things that we were hearing developers wanted. We were hearing the developers wanted smaller bundle sizes so that they have better start at performance and could keep their users engaged that way. We were hearing the developers wanted apps that were speedy to develops that they could have faster compilation times for building and testing, and they wanted code bases that were easy to debug and maintain over time, especially as their code bases started to grow. So the Ivy product was designed to address some of these concerns. And now that I have is out, I'd like to discuss some of the benefits of Ivy as they relate to our original goals to make angular, smaller, faster and simpler. Our first goal was to make angular smaller. And we had a few different strategies for doing this. The first was to make the framework more compatible with tree shaking. So in previous versions of Angler, we had many core functions that would reference each other in the critical path for bootstrapping. And this made it difficult for a tree shaking tools like Tercer to remove. Framework code that the app wasn't actually using because of all the references. It had to assume that the functions were being used and retain them in the final bundle with Ivy. Instead of having the critical path referencing all of the functions, instead we had the compiler generate only the functions that you needed. This removes the references that were causing unused code parts to be retained. So that allowed tree shaking to work as it was supposed to work. So that was our first strategy. And this feature is going to have the most benefit for apps that aren't using the full feature set of ANGULAR. And because obviously then you could remove the things that you're not using. But it also paves the way for additional features down the road. So that we can allow for even tinier bundle sizes for things like angular elements and. Use cases like that. Our second strategy for doing the bundle size was to be more conservative with how we generated code. So when I say co-generation, what do I mean? So. When you compile your application with ANGULAR, the compiler will analyze all of your components and it will generate, among other things, a function that represents the templates that you've written or the template that you've written for each component. And then at runtime, these template functions will execute, which will cause your application to render. If we didn't have this separate compilation step, what it would mean is that we'd have to do all of that analysis, that of your templates at runtime instead of at compile time. So you can think of compilation or Cogen as a way for the compiler to pre analyze your components in your application and send that analysis data to the runtime in the form of generated code. So the more code that you can generate from this analysis, the more of the runtime can actually skip doing that same processing, critical loading times. So there is a tradeoff between the amount of code that you generate and the amount of processing that you do at runtime. So one way that we were able to reduce the generated code is by tweaking where we are kind of on the spectrum. So if we push a little bit of processing to the runtime, we can remove some of the generated code. And it's possible for us to do this because with Ivy, we also introduced a number of performance improvements to the runtime as well. So we introduced more aggressive caching of some of the processing data. We're more conservative about how we work. We're cutting down on extraneous property reads especially metamorphic ones. And because of these performance improvements, we could offset the cost of doing more processing at runtime and reduce the size of the generated code. We also had a bunch of, you know, with a long tail of smaller optimizations, like, for example, method trainings. We didn't have to duplicate method names, grouping together similar instructions, things like that. Reducing the size of property names that couldn't be mangled. But all in all, we were able to save about 30 percent for each component. So apps with lots of components are going to see the most benefit from this, because for every component that they have, we'll be saving around 30 percent on the generated code. So we were happy to see the results in the wild for some of these changes that we made for smaller apps that could benefit from tree shaking, we saw about a 30 percent improvement for larger apps that could benefit from the Cogen reduction. We saw about twenty five to 40 percent improvement, depending on your specific app. And then for more moderately sized ups, we're seeing kind of a flutter diff because the benefits are being offset by a slightly larger fixed framework size, and this fixed size is something that we can continue to reduce over time. It just a longer time frame to make some of those changes. Yeah. So we're really excited about this results. It means, you know, a better startup experience for users, which means more conversions, replication authors. So everyone is happy. And I'm just here's some example of some of the feedback that we got from developers after Virgin came out. This is from Hacker News. Someone says, I just updated my mid-sized app from version eight DOT two to version nine of Ivy and the total yes. Twenty fifteen bottle size decreased from 973 cabi to 669 cabi in over thirty one percent improvement with no effort on my part. So the critical part to see here is the quote, no effort. This is one of our most important goals is just to make angular better without causing any extra work for English Molpus. So we were really excited to see this. OK, so our second goal was to make angular faster and by faster. One of things that we wanted to improve was build speed. We were hearing from developers that as their apps got larger, the build speed just wasn't as fast as they would like it to be. So we had a few strategies for improving the build speed. The first one was simply asking the compiler to do a little bit less work. So in the previous compiler, we would always compile the application along with its dependencies. So any libraries that it was using and this is kind of wasteful, right? Because as you're making changes to your application, your dependencies aren't likely changing as often unless you're continually re npm installing and changing your versions. But we would still recompile your dependencies every time we recompile your application. So that was a little slower than it needs to be. So with Ivy, we introduced a tool called End GCSE or the Angular Compatibility Compiler. And this is a separate tool that we use to compile dependencies. And so with Ivy, what we're doing is we're only compiling your dependencies when necessary so we can kind of cash that data. So as you're developing application and you're changing your app code, we're only recompiling your application. We're not continually re compiling your dependencies as well. So that makes Able Foster. Another strategy had to do with removing the need to operate on TracFone. So this is kind of low level, but basically with the old compiler, we were getting two sources of data that had two different format. So we had your application components that were written in typescript, and then we had your any libraries that your app was using. And we've gotten information from those libraries using the metadata that Jason files. We had Jason and TypeScript. And so what the compiler would do is it would take out the application components type scripts and convert that into component. Jason. So that it could share some of the same code between compiling libraries in the application. And so it could feed the Jason into the same process. So that conversion from type scripts into Jason was kind of expensive. So with Ivy, we don't even have metadata that Jason files anymore. So there's no need to do this conversion. We're operating on TypeScript entirely. So we can kind of avoid the cost for this completely. So with these two improvements and again, like a longer tale of smaller optimizations, we were able to see a sizable reduction in build time. And if you're wondering what I mean by Bill Time, specifically, we measure Bill time as kind of the time that it takes the angular compiler to run. Once you remove the time it takes for the typescript compiler to run because, you know, Angela ROPS, the typed compiler, and we don't really directly control the speed of that. So we measure the overhead over TypeScript. So for our own documentation app, Angular Donio, we used to have an overhead of point eight X, and with Ivey we had eight point five X overhead, which is about a 40 percent improvement. And this speed up is super useful because it means that for the first time ever, we can use a Hoti for even dev mode builds, which means that when you engy serve, you're going to be getting the same compile time checks that you would with production goals, which is pretty great for a developer experience. We also made tests faster and we were able to do this with one big change, which was to be a little bit smarter about how we recompile components between tests. So in view engineer the previous version of ANGULAR. We would re compile all of your components between every single test US execution. Which again, is pretty wasteful because, you know, it's likely that your components haven't been changing that much between each test. So with Ivy, we don't reckon Paul components at all between tests unless you're using some of the override methods. So if you have a component that's overwriting a components template, then we'll recompile that specific component, but we won't recompile everything. And in most cases, what this means is we won't be recompiling at all between us. So this. Was able to make a 50 to 40 to 50 percent improvement in test speed. Lastly, we were able to make internationalisation faster and we were able to achieve this by moving the translation and mining process from the beginning of the bill pipeline to the end of the build pipeline. So in version eight, if you were trying to, you know, inline translations, that would happen as part of the compilation. So while Angela was compiling your application, it would, you know, at the same time substitute the translation text for whatever text text you wrote when you're developing the app. And what this would mean is that for every locale, you'd have to go through the entire build pipeline separately. So if your build was 30 seconds for every new locale you add, you'd have to add another 30 seconds because it have to go through the whole process. So with Ivy. We've moved the in line to a post processing step. So what this means is you compile with ANGULAR just once you go through your entire build pipeline just once, and then you only do the translation and letting part for each locale. So again, if your build is 30 seconds and your translation and learning process takes five seconds, then you're only going to pay for five seconds for each locale instead of the whole 30. And so with this improvement, we saw about 10 times faster. I Tindall's just pretty cool. OK. So are our last goal was to make angular simpler, to understand and to deep bug and to show you this part from a jump into a quick debugging demo, because these things are kind of more fun to see in action. So I have a new Seelye project here that I created. I haven't made a whole lot of changes to it, but you can see. Here's the default Selye template in here. I've added a few bindings. However, if I serve this. You can see that I coated in a bug and fortunately and so I'm getting this expression changed after it has been checked. Error, which is probably an error that you've all seen before. And so I just want to show you what it would be like to debug this error with I.B.. So you can already see the message checks is pretty similar. But if you look at the stock trace, you can see this is completely different than what we had before. If you go up a few frames in the stack, you can see already from here that the error is being thrown due to a text interpolation in C text interpolate one. And you can also see which component it's in. It's in the app component. And this is the template function that we generated based on the app components template. So if you wanted to see the exact line that's causing the error, you can go ahead and click. On that line, and it will take us to the exact line. That's three there. Pretty cool. So I'm going to pretend like, you know, I don't know how Life-cycle hooks work. Great. So we can do about this as if we're debugging this real. So let's say. So in my engy, after viewing it hook, I had changed the value of this property. So I probably say, OK, let's put a break point here and let's put a break point, you know, at this particular binding. So I could figure out which one actually happens first. So if I refresh the page, it's going to stop at the binding. And I might wonder, OK. So at this point, what is the value of the title binding? So I can do a trick here by reading the title property from the context. I can see. OK. So the title is Energy Conking Out right here. That's pretty cool. So I know that it hasn't been changed yet. To add the exclamation points, which is what I had wanted to do here. Right. And the Life-cycle Hook. And also while we're here, I can show you another quick trick, which is you can just kind of look at the whole context if you want to see everything that's on there. OK. So it's a cool it's on the first value and cough keynotes. And I skip ahead and see the life-cycle hook it's being is being executed after. So obviously this isn't going to work because the value is being changed after the volume has been checked as the error had communicated. So that's how I would debug this. I also want to show you one more thing, which is you can also. Debug things through kind of inspecting elements directly, this is kind of has hasn't Moorfield to what debugging was like an angular J.S.. So if you were to select, for example, the app component routes, you could actually do. Let's finish debugging. Right. OK, so let's do it here. So again, I mean, it's like the operates. And then I can use this global energy object to start inspecting my angular application. You can see we have a bunch of new methods here that you may not have seen before. So for now, what I'm going to do is I'm going to grab the component that's on its elements. So get components in the elements and look at what happens and see that it's the app components context here. And then let's say I want to change the value of it so I can do something like this, change the title to something new. So you can see that obviously in comp, the title is Change to Something New. But in the actual UI, you can see that it still has the old value here. So if I were still debugging, maybe I'd want to run change direction for the frame to see the new value. So I could do something like Anji thought. Apply changes and then pass in the components. And then you can see that it's updated UI. So we have a bunch of really handy utility methods like this that you can kind of inspect elements, run change traction. And the stack traces are hopefully a little bit easier to read. So I think these features are actually really exciting. I remember when I was working on the Angular Components team a few years ago and I'd be building, you know, like. A select dialogue or something like that, and I'd run into some change election issue and I'd have just such a hard time debugging it because the old stock traces would just kind of throw you in the middle of framework code execution. You'd have no idea kind of where you are and change Texan or what had triggered the change to action. And it was just so disorienting the way that it was, the way that it would go and the previous version of ANGULAR. So I wish that I'd had methods like this that would help you kind of inspect where you are and help you debug change traction in a more imperative way. So I think these changes are super exciting. OK, so that's the demo. So to summarize kind of what we just saw. We have simpler stack traces in Ivy. We no longer have just all of these frameworks, specific functions that don't tell you where you are. You can walk up the stack and go directly to the template that's causing the problem. And again, like I showed, we have a new engy or a pneuma number of methods on the engine global. I only talked about a few of them in the demo. The API changes and get component. But you can see there's this whole list of things that you can use like listeners and get injector. And we have docs for these in England occultation, so I highly recommend checking this out. OK. More cool things. We've also improved build areas with I.T. So previously, if you wrote something, your template that wasn't in your energy module. So I have nonexisting component here. You get a little bit of context like the Elmina above and the on it below, but it wouldn't tell you, you know, what template this particular code snippet was in. Which can be kind of problematic if you have a large application, it's kind of hard to figure out where the error is coming from. So with Ivy, we've made this a little bit easier. So you can see exactly where the error is occurring. It's occurring in the template of app component. And you can see the specific line that it's occurring in its online, 377 specifically. And we've also made a number of aesthetic changes. You can see that we have color coding for the first time and just formatting changes and it just makes it a more plus than debugging experience in general. We have also made type checking a bit more intuitive. Previously, there were some things that we just didn't type check with the new strict templates mode. We're also going to type check things like directive inputs and then objects. We had previously typed checks, local references to components and directives. But now we're also going to check local references to Saddam moments as well. And template context types. So whatever you're passing into structural directives like Engy for. And I'm not going to go into too much detail about this one, because we have two great talks coming up in the conference about Ted, the type trekking. So we have Alex's talk tomorrow morning about stronger type checking in tablets. Ivy and Brian's doing a lightning talk later today. Also on type tracking. So definitely be sure to check these out if you want more details. OK. We have a few more things that we also made simpler. For example, star merging. So one of our longest standing issues and get hub is an issue about how when you bind to class directly like this, like the general class, that it's destructive and will overwrite any other classes that are on the same element. With Ivy, we've made the rules regarding style precedence more comprehensive and intuitive. So. And generally speaking, the more specific a style is, the higher its precedence. So in this case and the highlighted binding would take precedence over the class finding because it's more specific which addresses that issue. So if you're curious about style precedents, again, we have a guide in the angular dog. So if you search for style Prestons, you should find it. We also made model definitions a little bit simpler. So over the years, you've seen a lot of confusion with entry components specifically because if you don't because previously, if you didn't put a component in it and flipped directly, it wouldn't be compiled. You also had to add it to this entry components array with Ivy. It's no longer necessary to add things centric opponents as well, cyclic relations. So the entry components are a specifically is deprecated and you no longer have to add components to it. OK. So hopefully you can see how Ivy has achieved its goals to be smaller, faster and simpler. But I also wanted to mention that there are a bunch of things, you know, in addition to these shiny features and fixes, like the fact that we fixed dozens and dozens of bugs over the last two years. We threw all of the Capitol building Tosti compatibility testing that we did through Google and all of the testing that the community has done through our C periods. We found a ton of edge cases and that's caused a mass edition of new tests for the framework to make it more stable. We removed literally years of technical debt and just overall, angular as a product is healthier than it's ever been. And as a team, we've as we've been doing these rewrites, we've had time to really think deeply about the concepts of angular and how we can make it simpler and more intuitive and easier to use over the next few years. And we have so many ideas on how to make life easier for English developers. So. Yeah, I think we built a really strong foundation for the next few years, so I'm really excited about that. OK. So in addition to Ivy, version nine has a number of other improvements that I want to talk about. One. One big thing is that we added support for TypeScript through seven. And in the angular nine dot one released last week, we also added support for typescript three to eight. So this keeps us up to date with the ecosystem and allows you to take advantage of new types, core features like the optional chaining syntax here. So check that out. We also made a bunch of improvements to angular universal for our server side rendering story, and we added a new pre rendering tool. And we've gotten some pretty positive feedback about this. These new improvements, for example, this tweet. He says The developer experience of angular universal is infinitely better now. But again, I'm not going to go into a whole lot of detail about Universal because we have a great talk coming up about that later today by Wagner. Angela Universal in our New Year under. So definitely check it out. On the component side, we also added test harnesses, which is pretty cool because it's an abstraction layer that allows you to test whatever material components that you're using without having to rely on implementation details in a Schmeling's VSS. So this means that, you know, you don't have to worry about the class being ripped or something material because you can just use the harness and be confident that your tests will continue to work. We also added a bunch of new components, for example, this new YouTube player component that embeds YouTube videos. And this new Google Maps component that embeds Google Maps. So how do you get all of these amazing features and benefits? You can use our handy dandy engy update experience. So first to want to update to the latest version of the Seelye tooling. And then then you want to update Angler caught your life. Normally. We've gotten pretty positive feedback about the migration process from so Craig McMurry from Dick's Sporting Goods said, I got the email yesterday at 4:00 p.m. Yes, tee that night and the final is out and by four, 30 p.m. It was up in our staging environment. That's a true demonstration to the hard work that you were all doing to make it easy for us to migrate. So we'd love seeing things like this. And hopefully everyone has this type of positive experience. But we also have a number of tools to help you through your update. So if you're updating tonight, definitely check out updates on Engler's. And I know it has, you know, some options that you can use to customize the instructions that you get. But basically, it has a list of really detailed instructions to help you update your project, your project. We also have a dedicated guide to updating to our English version nine on that list, things like breaking changes, deprivations, troubleshooting advice, basically anything that you need to know. So I would definitely check that out as well. So now that the nine dot one release is out, we're going to start working on angular tender. Oh, that's coming next. So there's a lot to excited about. So stay tuned.