Transcription

♪♪ ♪♪ ♪♪ Cut! If you think about building a web application, what you end up building is a lot of marshalling. In other words, how do I get data from the database to the user, and then how do you get it from the user back to the database, right? So that's a marshalling problem. And if you build web apps, you end up doing marshalling all day long, right? Because it's like every single screen that you have, a form or input or a table that shows data, is really just a problem of getting the data back and forth between the database and the user. And so the question was, could you simplify this? Could you make some vocabulary where you could directly connect to the database and bypass the complexity around it? And so the idea was, add extra vocabulary to HTML, right? And so this is where the goal started. And I teamed up with another person called Adam Abrams, and he was more of a front-end developer and back-end as well. And so we kind of wanted to build those two pieces. I think the original project was actually called the Vanilla Binder, and then we made a website called Get Angular. It was a mixture of a front-end framework and also a database, so think like Firebase on it. And I wanted to have a system which non-developers could use to build applications. So it really wasn't meant for developers. It was really meant for somebody like a designer, somebody who knows HTML, but doesn't necessarily know how to code. And so the idea was, could you add extra vocabulary, extra attributes, extra tag names, into the HTML syntax so that that extra vocabulary could do very simple applications like make a guest book or create an appointment or just basic storage capabilities. It turned out that the framework part of it, like the idea of having an extended vocabulary that you can create for building web apps, was useful to us building actual web apps, right? And so we kind of dropped the storage part and just started focusing on the framework as it is known today. We were building an internal tool that was the back-end for how we let everybody on any Google product submit feedback about where we might be able to do better. And we were struggling because we had a small team and we had to build a web front-end. And Misko was on this team, and he said that we had been struggling on this for months, and he said, I can rebuild the whole thing in two weeks with this little side project I have, this new little JavaScript framework. And at the time, Misko was a Java expert. He was known for helping people build testability and construct Java architecture the right way. And so my thought was like, well, he probably doesn't know anything about JavaScript, but why not? Like, two weeks, of course I can afford that. using this side project that I've been working on. Yes, I made a post like that. I didn't quite make it, did I? Not quite. It took me three weeks instead of two weeks. Misko was actually, he had been building this project out in the open source. He was thinking of going off and just doing this as a separate company, leaving Google and focusing on GetAngular. You know, I had my selling hat on. I was like, no, man, that's a crazy idea. Google's got a ton of resources. You can basically, you can do your startup, but do it here. I didn't have headcount to fund the Angular team per se. I had to scrape and squint and, you know, steal from other projects to get a couple folks. And like, I pulled together enough headcount for three people to be on the project. And after Misko and a couple of contributors started on the project, we were able to hire some external folks. One of the first people we hired was this guy, Igor Minar. Ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha. Are we frameworked out? I think so. Ha, ha, ha, ha, ha, ha, ha, ha. So if you took the prototype of GetAngular or AngularJS as it was shaping and put it in front of web developers and showed them how you can build very rich, very interactive UIs with it, they were hooked because they understood that, first of all, they can write the UIs in much less code than they were typically used to. And secondly, the code was running on the client side, which meant that you could build much more interactive UIs than full-stack applications. Applications that required a full-page reload were rendered on the server side with very little interactivity on the client side. So both this productivity boost as well as the possibility to build much richer and more dynamic applications were very appealing to developers at the time. And we needed people to help us build it. So from early days, we worked with whoever wanted to contribute to AngularJS. We spent time mentoring them. We spent time giving the feedback on the changes they were making. We spent time on calls with people and we tried to see who are the people that had the passion, the motivation, and the drive to help us make Angular better. There was this dude on GitHub that was sending us pull request contributions that were way better than anything we've seen before. So we set up a call with him, talked to him to find out who he is. I asked him, like, who are you? And he introduced himself as a trumpet player. There was like zero planning, zero top-down influence from Google or Direction. At least I felt like we were totally doing whatever we wanted. Misko was always super excited about any idea. I love that about him. I would bring a new idea how to get rid of the form factory or whatever because I felt like it didn't fit the right design. And he would just get excited. We'd rewrite the whole thing in one day before Igor got in the office. There was no formal approvals or planning. We were all doing everything. Writing documentation, later doing talks at conferences and stuff, working with the customers. It was kind of messy, but it was kind of magical, actually. The early days were both exciting, but also frustrating because we had a lot of autonomy to work on AngularJS. But we were also, at the same time, not taken seriously by most engineering teams. We were seen as this experiment that was given some mandate, but there was a lot of uncertainty that came with it because we didn't know if the project would go on for a year, two years, five years, or if it would be shut down tomorrow. We tried to talk to Google Maps, we tried to talk to Gmail, all these big product engineering teams. They were kind of looking at what we were doing like, yeah, this is a good toy, good luck with that. We needed much more sophisticated solutions for applications. Our first review for Angular, we thought it was great. We had been using it on our project for a while, and so we wanted to take it to our directors and our VP, hopefully get some more funding for it, get more people who could work on the project, and at least get some high-level air cover. One of the guys in the room was one of the famous architects and leaders of Google from a technology standpoint, this guy Urs Holz. And so after we'd gotten done with the presentation, we'd showed how it reduced the amount of code that you would take, how it was easy to evolve a system from one point to another, why it was really easy for developers to get in on it. We concluded the presentation, and Urs told us very bluntly, you are all liars. And that was actually one of the quotes that we leaned into in some of the presentations. We were like, yeah, we were called liars, but here it actually is real. But it was an interesting challenge. We were given this challenge called liars, but also if you don't want to be called liars, go prove yourself. Go make this actually show us that this can happen. So we got permission to keep on going and exploring this direction and building AngularJS, but it didn't really come with any additional resources. It didn't come with any additional help that would make us make this happen, and this is why we leaned so much on the open source community to help us. I remember when we launched Angular 1.0, and we had a tracker to see the traffic on the website, and we were hoping to get some modest bump and that people would pick it up, but it went crazy. It was like a hockey stick from the get-go, and this was where we got a little excited and a little scared because we hadn't really anticipated this much attention. From 1.0 all the way up through 1.3, it was nothing but a skyrocket ride. All right, folks. Hey, we can barely believe this is happening. Can you guys believe it's happening? Finally. It's unreal, isn't it? It's unreal for us. I'm in denial. I'm in denial for it. There was an office hours with the Angular team around Google I.O., and I went, and like most of the people in the room, I was totally fanboying at Brad and Igor and Mishko's presence, and I got in a line. There was a line to talk to these guys, and I was nervous. I was in an ultimate fanboy moment, and I got to the front, and I was excited, and I was like, hey, my name's Aaron. I know some people that you like. I know Joanne's. I know John Lindquist. I know Dave Geddes, and we've all thought about building an Angular-only conference, and we were hoping that maybe you guys would come. Immediately, Brad was like, yeah, well, actually, we're going to send the whole team if you do that. So I immediately recognized, okay, if they send the whole team, this is going to be different, and we hoped the community would care. We hoped they'd be excited. We thought once we put the link up for tickets, we'd get some interest. Truly, before we had even had a chance to refresh the page one time, they were all pending, and we slowly started seeing those shopping carts complete their purchases, and that was when we realized, oh my God, we just sold out the conference in 10 seconds. I think Angular's real selling point was you just include it on a web page, and you could instantly start writing HTML-only that had JavaScript functionality, and that had never been done before. The infamous, like, where you could just type in an input box, and it would spell it backwards on the next line, and you could do that without any JavaScript, just HTML, that demo was something that the web had never, ever seen before, and so I think some of the really cool first demos were so mind-blowing that AngularJS just immediately stood out as an easier-to-use framework. If you are building a solution with developers in mind, friction has to be as close to zero as possible from the get-go, and AngularJS got that right, in my opinion. You were able to start an application very fast, you could use a CDN, you could drop in some script tags, and you had access to this wonderful system that gave you two-way data binding, gave you dependency injection, gave you directives, and a way to start building something non-trivial without having to do a ton of work yourself, and I think that there was something really nice about that. It was at a time when people were, you know, they were comfortable, they were used to using jQuery, they were also trying to look for more opinionated architectural solutions, and I feel like AngularJS really helped them see, like, okay, well, here are many problems we're all running into, let's try to give you something that includes more batteries by default. So I think that it did a good job at trying to give you a slightly better path to building something non-trivial. When we reached Angular 1.3, this is when it was getting super big externally and internally, and we got re-org'd under the ads part of the organization, and they were heavily invested in GWT, but they were looking for something better and something easier. The tech leads over there were really still into Java, and they loved the type-safetiness and, like, a lot of the things that we now get out of TypeScript but we couldn't back at the time, and they wanted something that seemed a lot like GWT with the development tools and all of those nice things that they have for Java, but they wanted it with the Angular framework. The thing that led us down the path to Angular 2 was really their requirement that we build it on Dart. Well, Dart is a new programming language and a platform. It includes libraries and programming tools for writing structured web applications. So basically, Dart is a new project that has the goal of improving the productivity of web developers. I just remember, like, the day when Brad Green came and he was like, OK, guys, bad news. I don't know if he said bad news, but he did. And I almost quit. I remember, I almost quit. He was... Yeah, it was a very difficult conversation because we did not feel like... we didn't feel that it was the right thing to do, and we had no choice. It actually ended up being a way that we probably saved the Angular team from being disbanded, but it was really hard to swallow where we were super passionate about JavaScript and all of the flexibility that it gave developers. And to them, it looked like I was shoving them down a trough where, you know, it looked like death to them, probably. I think if we had not been pushed by the Dart team to go this way, we would not have gone down the TypeScript path. You know, Misko and Igor might view this differently. They might... and they might be right. My view of it is that we were so passionate about the freedom from types and we actually worked it into some of our talks where, you know, we sold against GWT, the Google Web Toolkit, for its requiring you to use types. And one of the things we used to say is types are for people who like to do a lot of typing. And we totally changed our theory on this once we had seen some of the work that we were able to get done with Dart. And I think it took that exposure in our context, in Angular itself, to understand how types were actually critical to building large-scale applications. And large-scale applications, again, they were not the target of Angular from the beginning. And so it's totally understandable why we would have had a different perspective. But as we were serving larger teams and having folks who had long-living applications you had to revise over many years, types became actually a critical thing that we knew our developers needed and that we knew we had to bring them along on the journey with us. So we knew we needed a type system. And so the original idea was to just add assertions, kind of a runtime type checker that basically, as the code is running, it's asserting that, yeah, you have the object here that you think you have. And so this kind of gave birth to AdScript. We're going to talk about Angular. Specifically, I want to talk about how we are not building a language. Just to make this clear, we are not building a language. And the thing we're not doing, that's called AdScript. I never really thought that AdScript was necessarily a big thing that we should be promoting. But somehow, we kind of went on the conference and basically said, hey, we were thinking about this AdScript thing. It got attention of Microsoft with TypeScript. And they kind of reached out to us and said, hey, what you're building is, we already have a system for it. So instead of building yet another thing and fragmenting the ecosystem, maybe we should work together and come up with a common solution for it. And so this is kind of the birth of the cooperation between Angular team and the TypeScript team. And the funny thing about citruses is that when you take the seed and you grow it, you will get a citrus, but it will not be a lemon. It will be something else. We announced that we were going to do Angular 2. And it didn't go very well. There was a presentation we did where we had tombstones up for a bunch of the concepts that we were retiring in Angular 1. Probably not the most sensitive way to introduce change to a community. Tobias, I'm sorry to tell you that we killed the controller. Really? Yes. I hadn't actually seen the announcement yet, but I had to watch it as soon as I got home because Igor was obsessively talking about like, what do you think we could have done differently? I mean, 1 to 2 was rough. No, 1 to 2 was very rough. I mean, you finally gain your stripes into feeling comfortable at your job place. You're the Angular guy. They changed the entire framework almost overnight, you know, and there was not the RC process at the time or anything like that. And you're like, man, now what do I do? And the thing is, to me, it got to the point, it was right when we finished a digital transformation for a company, you know, and we felt so good about it. And then all of a sudden, they said Angular has just changed. We're like, okay, that's maybe a minor change here and there, but the entire thing changed. Like, the way you approach it, have script get introduced and everything like that. And basically, I remember one of my managers looking at me and saying, like, okay, are we going to, are we ready for two? I'm like, I'm not even ready for, like, coming to work tomorrow. You know, so don't ask me about the two. Just release the framework and leave it with these features, okay, and then add more afterwards. So we'll be done by 2016 and that's it, okay? Okay. Okay. Is that we're building a command line interface. Angular CLI. Material design with component routing. Observables. You can do functional reactive programming. Could we move the framework itself into the web worker? Finding an XML template with data to create a native UI component view. But at the time that Angular was released, I was in a very lucky situation to not have to maintain an AngularJS application and just be allowed to work on Angular and dive into the framework. I was at NG Europe 2016 where some of the folks were talking about the things they had planned for Angular and it was like, yes, this is so obvious. Okay, why didn't we have this in AngularJS? But on the other hand, I was just excited because what I mentioned earlier, the fact when they introduced the CLI at NG Europe, I was like, yes, I don't want to deal with Webpack. Or I think in the first place it was SystemJS. So having the Angular CLI, NX, those kind of tools, abstracting that entirely from me is something that I very much appreciate. But the migration process was rough and I think for a lot of people that was really scary and in the end forced them rather to look in other directions, like you said, React, which seemed less scary than having to deal with breaking changes and the fear of going through something like that then again afterwards. We moved to Silicon Valley to be in the action, to be around people that were obsessed with technology and building and we took advantage of that by going to all the meetups that we could. And so we went to Angular meetups all the time in San Francisco and the Valley and we found a lot of people that were obsessed like we were with this technology. There's things like custom directives, there's routing strategies, there's rendering strategies, there's lazy loading, great state management within GRX. So all of these things that you would normally have to piecemeal together with other languages and frameworks were out of the box with Angular. We were building 15 products inside of one and we had a very small team. It was under 10 engineers. So we had to build really fast and TypeScript allowed us with kind of type checking to be able to find a lot of these trivial bugs very proactively without having a huge QA team. And fortunately for us we started with Angular 2 so we didn't have those same frustrations but we saw that a lot and when we were hiring people when we would go talk at some of these technical talks there was a huge frustration around what happened with AngularJS to Angular 2. Don't call it a rebrand because it wasn't one. Yeah. I would be doing workshops often where I was introducing people to Angular and especially in that state of learning Angular and learning any framework in general you're searching constantly like half of learning programming is your Google food. And so if you are just saying how do you do an Angular 4 loop and then you have some that are AngularJS and it's like okay is this Angular 1? Is this Angular 2? And I was like every search would be how do I do this thing Angular 2? Then you go away from 2. And then it's just like okay what do I search now? And the messaging was always it's just Angular. It's just Angular. And that wasn't true. Like unfortunately you couldn't just search Angular if they would have just pivoted the name at that point and made GoogleJS. No I'm just kidding. Like what could have come of like you know we would have had that dip. Anyway long story short developers were pissed after the presentation came out because everybody was like oh Angular team is just breaking everything and I invested all this time into my application and my skills and now it's all gone and it's like no no we're making it better we're making it better. No it didn't land that way at all. And it took us many years to to this day I think a lot of the perception people have around Angular is because of how we communicated the transition from AngularJS to Angular version 2. And the fact that we felt like this was the right thing to do for everybody and I think in retrospect everybody would agree that it was the right thing to do. But just the way we messaged it was not right. And it caused so much harm that to this day Angular is still recovering from it. I think we all realize that Angular v2 was a mistake. Not in what we were trying to do but in how we were trying to do it. And it was too late to course correct so we just had to go with whatever we had and just somehow just make it work and slap it all together and ship it. Because we were running out of time the developers were running out of patience like people at Google really wanted to use this thing and it was unstable for the longest time so we just had to ship it. So we did ship something knowing that this is not what we wanted to ship but it was the best thing that we were able to ship at the time. And this was 2016. I think AngularJS was a project of passion Angular 2 was not. It was just like the thing that people do. I think it was just like too many chefs in the kitchen too many constraints too many mandates too many... We were just overwhelmed by our own ambition and by all of these artificial mandates and constraints that were placed on us. Like you have to make it work with Dart. On the flip side with us using Dart we also were funded. We actually grew the team tremendously. We went from like 3 or 4 people into about 12 people it seemed like almost overnight. So I joined the team at the time we were switching from AtScript to TypeScript. Someone wrote a compiler called TS2Dart and the idea was that Angular would be written in TypeScript or I guess previously AtScript but it eventually became TypeScript. This compiler would translate that TypeScript code to Dart and so they wouldn't actually have to write two frameworks. You could have one framework that was authored in one language but that could offer an experience in both. One of the challenges of building the code this way of compiling TypeScript to Dart was that you're limited to the overlap between the two languages. The set of things that can be expressed in both. And that created friction on both sides. So for the Dart experience it was never a really idiomatic Dart experience. You couldn't use things like factory constructors that were built into the Dart language and one of the selling points of the Dart language the improvements over the JavaScript experience because you couldn't do those things in TypeScript. And in the TypeScript side a lot of people wonder today why Angular uses null all over the place instead of undefined. It's because Dart has no undefined. It wasn't great. And eventually the Dart team was just fed up with us and they were like oh, we'll just take over AngularDart and we are forking. They were like yes, let's do it because that is the right... That's not how I remember it. I was upset about the fact that they were forking it. But in retrospect I'm glad they did. In retrospect... We didn't know what it meant, right? We didn't know what it meant but I think there was so much funding that came with the mandate to support Dart. But I think for me it was like I spent so much time and effort making sure that it worked in this special way so that both things can be supported and now you're taking a fork away. It felt personal. But in retrospect I'm like it was the best thing that ever happened. If that didn't happen then we would not be talking about Angular today. And the only way forward was make lots of small breaking changes over a long period of time to completely abandon what Angular B2 was and rebuild it to what we wanted it to be. Two engineers from Amadeus in France who were working on Angular with us they're kind of external team members they come and visit the team in Mountain View as they have a few times and they give a demo of this prototype that they've built of a different approach to rendering and a different kind of design for how to structure the internals of a framework. And it was the fourth prototype that they built so they were using Roman numerals IV. And Nishko saw this demo and fell in love with it. He had been thinking quite a bit on what do we do next how do we make the framework smaller how do we make the framework more tree shakable. So one of the things we talked quite a bit about is dead code elimination. If you have 30 features and users are only using 10 of them how do you make sure that all of the code to support the other 20 that they're not using doesn't have to be shipped to the browser because that's expensive. That makes the application bundle much bigger than it needs to be. Nishko saw the IV design and realized that it really put tree shaking at the heart of the design behind the framework. And he thought that this was what Angular needed to take the next step. Yeah, there's a lot to say about IV. The original intent was that it would be a relatively small project in scope that it would ship in Angular version 7. It really ended up just becoming a textbook case of scope creep and turned into effectively a rewrite of the entire framework. From start to finish seven releases so that's about three and a half years. Because it started off as a small project that grew in scope kind of inch by inch I think there wasn't a lot of consensus on the team that it was the best thing that the team could be doing. Some people felt that it was too much of a lateral move. It certainly did have a lot more of technological enhancements for the framework. Misko in particular saw it as necessary for Angular to be able to continue to evolve. But from a developer experience standpoint moving from Vue Engine to IV mostly felt the same. Maybe faster performance maybe smaller bundle sizes but developers don't really feel those things viscerally. If you spend three years working on this huge internal framework and three years working on this huge internal refactoring and rewrite and at the end of it the framework still feels the same to the developer it is kind of underwhelming. I think the trap was that it's really easy to prototype something and to prototype even a lot of it but it's really really hard to get that last 20%. So you can get it to 80% really quick but the details are what mess you up. Another huge piece of it was as Misko was saying the car is still running we didn't want to break the world again. With AngularJS and Angular we had this huge schism in the community and so the goal for IV was to change all of the internals of the engine without requiring any changes from users and how they were using Angular. But what we quickly realized was that there were so many tiny little things that were undocumented that had a huge impact on how the code would run. The order that lifecycle hooks would run in as components relate to each other that was never something that was guaranteed by the framework it was just an implementation detail of the framework. If you moved from a breadth-first method to a depth-first method it would completely break applications because they were implicitly depending on the order of things even though it wasn't guaranteed. And so there were a thousand little details like that that were incidentally the way that Angular happened to execute but nothing that should have been dependent on. We had to kind of do backflips because we had a brand new algorithm but it had to run in the exact same order as the old algorithm. So even if it was not as easy to implement or even slower we had to do it that way for backwards compatibility. That led to Angular 8.0 I think where you could try IV there was an opt-in flag and then 9.0 where it became the default experience. So we shipped IV right? Party. Celebration. Woo-hoo. Except it wasn't turned on at Google and it wasn't turned on at Google because although we had handled quite a bit of the migration challenges for the run-time behaviors it turned out that IV poked at some things in the way Google built JavaScript that made it very challenging to transition the Google infrastructure the whole Google codebase onto IV and that project took several years beyond the initial public release. Internally at Google we have something called the churn policy which essentially states that when an infrastructure team like Angular tries to make a big breaking change such as enabling IV we can't just kick this over the fence. We can't just say hey IV flag exists all the application teams go enable it and set that on and then we're going to delete it. It doesn't really work that way and instead what the churn policy states is that we can't do that. We actually have to take the time and energy to migrate all Angular applications in Google. And at the time there were probably 2,500 applications Angular apps in Google that needed to be migrated. When we sort of shipped out IV externally a lot of people complained and being like ah this is a lot of work you know there's all these breaking changes we have to manage and we have to do it 500 times. It felt like it was a project that the Angular team was overwhelmed by a little bit. For me as like a community member. So I got scared quite honestly because I was the last at that time eight years I was working with Angular. My skill set literally the first thing in my CV said Angular. That was the thing that I had a proven track record of okay that is a skill that I can showcase. Will Angular survive as a framework through I see other frameworks delivering feature after feature after new use cases that they come up with. And Angular being stuck with hey we have this commitment on IV was scary. We were all very aware of like people saying stuff like oh Angular's dead and like oh don't ever use Angular. It's really disheartening to be on a team that you're excited about to you know hear that kind of sentiment. On the like high positive side of IV it did end up delivering what it kind of promised where with IV landing we were able to give Angular all these features that we couldn't before. And we could iterate on it faster and give all this new stuff that everybody was excited about possibly building at the time that the community was asking for. As much as that like three years of toil of working through IV was difficult for the team and difficult for the community we were able to do it for the community I think in the end it ended up being worth it but I know we wouldn't do it again. Like we certainly learned the hard way not to take on projects in that way. We had two of the like kind of core engineers step down right and go on to other ventures right but I think for the value of the community everyone just kept going and I think what Ben was talking about how you know they didn't really like act like that like I made this this is my house you know I'm gone it's gone like it wasn't that energy right. And so just not having that I think let us continue to find out even as a core team but we have to find out what what would happen next ourselves like we got to experience it and figure out what we would do. Everything is great. React is great. Spelt is great. View is great. You can't really make a bad choice. So then how do you differentiate yourself when you can't make a bad choice? You just continue to be the best you can be at the things that you're really good at and that's what we're focused on and I think that's what allowed us to kind of survive the change you know such a big change right in our whole space. The leadership came from the Google team and the community rallied around and said yeah if you keep the light on we are here. Yeah I think what's interesting is that for something that is so broadly used within Google and for something that obviously has such a value to developers and developer trusts and community members and community partners and community partners and developer trust and the external ecosystem what I saw was that there was not a connection between their worth, their real worth and people understanding that worth above and so what I tried to do was articulate that and try to draw that connection. I wrote a paper called Angular Google's Underfed Golden Goose which is about like hey this is a team and a group and a framework that derives great value within Google. It is the most used framework at Google. It also drives a lot of worth for all of these other people. We have a few paths to consider here. We can run things in maintenance mode. We can not invest or we could reinvest and we could invest in people who are really excited about that. People above. In a way that they were not excited before. There was a lack of articulation at that time through nobody's like, there is no ill intent there but I think there was a missed mark and so I just tried to draw that connection a little bit more clearly and they were just so thoughtful and energetic and hard working and wonderful to talk to. It is weird to say I was surprised but I was surprised they were so welcoming. Not only welcoming of having me be there but genuinely excited about hearing my perspective coming from another community. As I was talking to the team, I was asking them about their framework and why they made the decisions they had and asked would it be okay if I asked you a bunch of questions around what was going on there and they said yes. I wrote a paper called Babbi's first Angular. I moved a bunch of my view applications around the world. I invested in zone for reactivity and it can be noisy when you check the world. Do you still believe in that as a strategy? In asking those questions they gave me honest takes. We have been considering revamping the reactivity system. What do you like about other teams? It was really helpful in us talking together about what a new strategic direction could be, what opportunities lay ahead. It was at a time when Ivy was wrapping up which is great. It was very much like okay we have this time and this chance. What's next? COVID happened and we didn't have any in-person interaction. There was a moment in 2021 where we were able to do this for the first time. One of the exercises we did was I called it a design review ten years later. This idea we would take a look back at the framework and see what was working and what wasn't and talk about how to tackle it. One of the themes that came up was reactivity. In Angular the original design was based on zone.js. You as an application developer could put your state in whatever shape objects whether it's in services or inside of components and you could change it however you wanted and the framework would figure that out. Over time what we noticed was as you scaled your applications up that model had some performance problems. It could be very performant but it was easy to do things that caused many change detection cycles or things like that. At the same time we had this additional model in Angular that I would call on people at managing their performance and keeping it in the good zone while they were scaling was the applications that were building on top of unpushed change detection using RxJS as this messenger of telling the framework hey I'm updating this specific value you need to know where it's changing. But there was an interesting kind of gap because it was still under the hood doing this dirty checking operation. Yes you notified me you changed this component that's great I'm still going to check the rest of the world just because. So the framework was not paying attention to the notification in the same way as a reactive framework and the framework were to pay attention that you could achieve much more optimal performance than we were getting today. One of the things that was very clear to us that we want to have a reactivity system that can be used anywhere can be used in a template can be used in a reactive framework. If you have a giant like this and you want to move it somewhere else to share it between two different components you shouldn't change the paradigm you shouldn't refactor the code in a drastic way there were only two solutions in the beginning and then you've got operators that can buffer events or I can wait for five events to arrive or maybe I can wait for five seconds to pass. You've got tools to actually work with time. That's powerful but it also contributes to this perceived difficulty of learning. There are so many operators so many things. There is only one operator which is map or derivation and this is essentially what signals are doing. They are much simpler in nature. This is different primitive in nature because they completely bypass the notion of time. I've got a value for you. It can change. I will not tell you when it will change. This is the different animal, this is the different primitive and this is what you want to use because that's the problem. Essentially I reached out to Ryan. I can see that you are working on another framework. Maybe we should chat. He is so excited. He wanted to talk to me about all things reactivity. He read some articles and he saw that from his perspective, although I don't want to speak for him completely, that Angular was being viewed as kind of a legacy framework in certain ways from the outside world and he felt that we needed to do something to change that. He thought part of it was to just look at what other people were doing and he got interested in the reactivity models that we were using. It was a huge win from my perspective to see Angular adopt signals. Some of the old React core team members came out of the woodwork to defend the decisions that were made. This is the first time in a very long time that I saw the discussion being present back when React was first introduced back in 2013-14. Some people might look at my willingness to help others as aren't they competitors, isn't that a strange thing to do, but at a certain point I'd done so much education on the topic and really just wanted to see these patterns succeed. I think the picture here is bigger than that. Most importantly I want these ideas to propagate and survive. There was a time period when React first came out that these ideas were almost completely dead. I never want to see that happening again. I think there are viable alternatives here with signals and I'm glad others are starting to agree. I don't think that innovation is possible unless you have an intentional choice. I think as long as you're intrinsically motivated, things like that just naturally happen. I'm not sure it's like we've got to go talk to Ryan Carnato or Rich. It's always good to do those things if you're motivated to learn and grow. When you have to do that, you have to be open to other ways of working and looking at this. Massive props to people like Ryan for working across frame work boundaries. He doesn't have to do that. I think that's a huge sign of health in the industry and I'm very thankful for his approach. Welcome to NGCONF 2024. Most of you may not know this, but inside of Google we have one more frame work. Going forward, Angular and Wiz are going to work together more closely. Working together on this will help us year after year to continue making progress on making Angular better for everyone. This is a framework that focuses on products that really need high performance. The strategy here is to open source the parts of Wiz that make sense and open source them through Angular. Now seems like the right time to start converging these technologies because we started getting a lot of requests from Wiz and the other framework needed. Both teams started exploring signals independently and then we realized that the Wiz team was basically reimplementing a lot of what the Angular team had already done for signals and so we just encouraged the teams to maybe try to explore that and if that worked that could be possible. Today 100% of the YouTube mobile web app is using Angular signals. This is the same library that the Angular and the Wiz teams built together and is currently in the Angular's open source repo. So for everyone who is wondering whether Angular is going to survive in the future, the fact that the team is using Angular means that Angular will be powering Google search and if that's not a demonstration of Google's commitment towards Angular or the need for Angular to stay then I don't know. We're not going to stop working on Angular and Wiz and stay in the same place and convert the frameworks in the next 3-4 years without delivering anything. We're going to keep convergence in mind and we're going to unify on these specific features until we eventually turn into the same framework. We're making consistent small steps and every step is making the framework better. It's not one leap back in 2010. It's a new framework with new features that are future looking. We worked on new documentation making sure the learning journey is smooth and people can start adopting Angular as they need to. It's one of the most exciting times to be working on Angular. It's both because of our code base health but also because of the team that we get to work with and the community that we get to interact with. It's a very special moment in the history of Angular. There's an inherent complexity that we're going to have to deal with as a team. There's a level of health into our code base, there's a level of health within our team, and there's a level of health within our leadership as well. We have Sarah's support in a way that I don't know if in the community that we get to work with. I think it's both a technical and people situation. The team has grown so much. A lot of folks on the team have been working on Angular since before Angular 2 was released. So there was a ton of learnings throughout this process that enables us to be better about what we're able to accomplish today. The renaissance is real, that's a quote. I think it's a fancy term, but I do think it has shown where Angular has come over the years as far as where it was. Ivy took a long time. A lot of people left and we didn't know what to do. If we look today to see what Ivy unlocked, I think the renaissance is a result of those things. I'm looking forward to seeing what comes next. Even if it unlocks more things. During the Ivy rewrite and afterwards there was not much happening from the IDE side of things when it came to Angular. I'm always like, when can I go back to Angular? With what recently has happened with Angular, I'm super glad to be back full time on supporting Angular. Angular blocks syntax was great. It was so much fun to support it. You had to do a lot of fixes and update the model building, but it was fun to develop. I was really glad to be back on supporting Angular with these new cool features. Whether you use Angular or not, it's hard to not see what we're doing and at least notice. Here's the secret behind Angular. It's about being there. Being there lets us hear with a way that we've never heard before and it helps us drive our decisions. When you're service-oriented in your mindset, it's hard to lose. We try to avoid disrupting developers where we can. When we have a big announcement coming, people get to be excited instead of worried. We're not going to rewrite the whole thing again. We're focused on evolving the framework while also bringing all of our community along with us. When we have something big to announce, it's hard to lose. I think hand in hand, React sees a decrease in popularity with recent decisions around React components. That's my outsider's perspective. React is going through an Angular 2 phase with server components while Angular 2 is still in development. I think this was just a very lucky moment for Angular to gain popularity in the framework ecosystem. We did have some concerns about Angular losing its talent and losing its team team. We are more confident than we have been. It's interesting how frameworks rise and fall. Angular became a very enterprise y framework. What was being taught at schools and boot centers was that whether or not they were capable of doing the same thing for half a million lines of code wasn't important. Angular is the Keanu Reeves of frameworks. It had an amazing experience. At the beginning of the new era of Angular, the JavaScript ecosystem has been a volatile place. There were new frameworks every other month. There were memes saying I've been in the dark. My mindset changed since we released version 17. We had the most successful livestream. I have a couple of podcasts a week. People are excited about what we are building. Angular is really exciting to be part of it. I always wanted Angular to be self-sustaining or sustainable, and I feared that there were so many moments throughout Angular where tomorrow was the last day of Angular. At least that's how many of us felt. It's great to see the community excited about what's happening. People keep on believing in Angular and building applications with Angular. It's great to see that. Leaving the Angular team was like leaving my world. As I check in now, it's amazing and super rewarding to see that Angular has found fresh direction in ways I would never have predicted. They've maintained the passion and what Angular was originally trying to strive for. They've refound their footing, I think, and I couldn't be