Angular Momentum 2
===

[00:00:00] 

Hi, and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it free@logrocket.com. I am Taja Kumar and I'm a developer relations consultant. Today we have Minko Gev on the show.

Minko has been on the show before and is the engineering product and developer relations lead at Google for Angular. And so of course I'm really excited to talk Derell and Google and Angular all of it. Today he's here to talk about his JS Nation talk Angular momentum. Welcome back, Minko.

Thank you. Glad to be back.

It's great to have you.

And it's been, I've been really excited about this session for a long time cuz I, I really admire your work and commitment to angular, not just Angular, but engineering excellence across the board. I've been following you for a while and I'm excited and honored that I get to chat with you today.

Before we get into the talk and your details, do you mind just telling our listeners a little bit about your background experience and involvement in Angular, Google, dere, et cetera.

Sure. Yeah. I [00:01:00] was actually reflecting on this today. And turned out that I have been working on anger related things since 2012 or so. I was very obsessed in college with software engineering, like design patterns and best practices and I was supposed to build to. An application, a web app for a startup based in San Mateo here.

That was back in the day when I was still in Bulgaria, in Sofia, and I was trying to pick the best framework for the job, and with my bias towards software engineering, like design patterns and best practices. The only solution back then was Eng Gs. So I started doing j and contributing to different open source projects.

In the meantime, I opened my very first pool request toes. I remember how excited that, exciting that was. Created a style guide that ended up being popular, got traction, people started translating it to different languages from there. I started reading the Angu source called, and wrote a book about aguar.

So one big part of [00:02:00] my talk at JS Nation was that Anur JS and angu are actually different technologies, which is not obvious. And I would say that maybe the branding could have been a little bit better. So that's something we can talk about. And yeah, from there I built some tools for static analysis.

Google started using them and invited me to join the team. After. I stopped working on my startup back in 2018 or so. I joined Google to contribute to anywhere like this time as my full-time job being part of the operat relations. And since then started I took over this team and now I'm also. Supporting the product, figuring out what we'll be building next in anywhere, how we'll be MA able to manage all the different requirements that are coming for the framework from different sources and figuring out the path forward.

Wow. That's a lot. There's so much in there I want to unpack. And I think, we like digressions here on Pot Rocket. We might digress a little bit because I [00:03:00] find that everything you said pretty interesting and I wanna zero in on, you mentioned this first pull request to angular js that you were very proud of.

I know a lot of people listening want to get into open source and people want to contribute to these large projects. There's a lot of fear there. How do I even approach this? Because it's a code base I'm not familiar with, and I, what if someone else takes the issue and is the team going to be mean to me on the full request?

And I speak to a lot of people as a devel consultant myself, and there's a lot of fear, uncertainty, and doubt in contributing to open source. So I'm curious what your experience was. How did you find the issue to work on and how did you get familiar enough with the code base to actually start opening pool requests?

Yeah, it is a very simple pull request. I just added missing Brace, I think, documentation in J Doc. So a super simple one. I wouldn't say I'm really proud of it, but I was definitely very anxious to open it. I remember like opening it twice, even the first time I closed it, just because even though it was so simple, I messed something up.

With get and the second time. It worked out and I kept refreshing the [00:04:00] browser because back then, GitHub was not getting these like push updates when something changes. So I kept refreshing and trying to figure out what's gonna, what's gonna happen? Is it gonna be merged? And eventually, after a couple of hours, one of my former colleagues now, he approved the poor request and got it in.

So it was really exciting, even though it was just a single line change.

That's great. And then how did you graduate to probably more significant changes. You mentioned you did some stuff with static analysis and so on. Did someone from the maintainers come alongside you and say, Hey, I wanna help you with more onboarding, or how did that, how did you grow in that?

Yeah, it was a long journey actually. Like first I re-implemented, like I built a small prototype of on 200 lines of code, so I wanted to build the basic functionality. Yeah I wrote an article about that and. It has the same things. It has like selector based matching. It has the same compiler, which is just in time compiler of the dome, has dependency, injection, all that stuff in 200 lines of code.

So I spent a lot of time trying to figure out how it works. [00:05:00] Kept reading the source code. I was very excited about compilers. And back then, N U R G S back in the day had an interpreter of expression, so that's where I learned a lot about Lexi analysis, syn analysis. And this helped me to build a tool for static analysis as well, because it uses the same concepts.

I am parsing the content and after that I'm traversing the abstract synex tree. And since I joined Google, I mean before that, in the meantime, I was also. I should show you all the books here I have about compilers. I was really excited about that stuff and I kept doing a lot of engineering work. I'm sure I've written like many millions of lines of code because I was doing that.

I was going through my notes in the notes app and I had a, an entry there. You shouldn't be working 12 hours a day just because eventually you're gonna burn out. You should be working only 10 hours a day and two hours you should be doing martial arts.

Say that I reduced my coding time.

Now I'm definitely way more [00:06:00] reasonable in the but I definitely went through this period of time where I was just writing colds every single moment. And this helped me to faster get used to more complicated concepts and make bigger and more significant contribution contributions.

And when you were making these contributions, did you also have a full-time job somewhere else at the time, or did you just have all the time to dive into all this compiler stuff and really go nuts?

Yeah, I had a startup. I had my own startup rhyme.com and we were building the product from scratch. Back then, I was actually using React , for the front end of rhyme.com. It was just the right choice at the time. Then your team announced that they'll be working on this new framework called Anywhere.

Back then they called it an two, which is completely different framework from an R js. And I didn't know what to do, or should I start using ANR two that is not ready yet, or should I be using an js? So I decided well, I'm just gonna go with React. And I'll say that was the right choice back then for sure.

Yeah.

Yeah, just build the startup with, ended up selling it to Coursera and I joined [00:07:00] Google to focus on anywhere full-time.

That's great. Yeah, I I also switched to React. I used to be an Angular JS developer up until 1.3 or 1.3 point something, if I remember correctly. And then the Angular two came around, which, is a different, Product entirely. And I was like, oh, do I have to learn Dart? Do I have to do, I have to use TypeScript decorator syntax and then React shows up for jsx?

And I was like, oh, this actually looks a bit closer to what I wanna write. So I share that with you. I wanna dive a little bit into your talk Angular momentum. But you started the talk saying that Angular has grown seven times in the last five years. And is the second most popular framework behind React in the 2022 state of JavaScript survey.

Why do you think that is? What do you attribute this growth and sustained popularity to

So yeah, there are quite a few things actually, and also I mentioned React as a framework. I think anger and reactor are generally in slightly different categories. Maybe anger is closer to something like next, Jess, rather than React itself. It's really hard to categorize them. But I mentioned React specifically just because [00:08:00] that's how people have been positioning these frameworks.

Outside, and that's like a popular comparison. A few things that contributes to Angu for sure, that it is backed by Google and you're just getting some certainty that it'll be a reliable product. Like people who are joining Google, they have quite a lot of engineering experience and they have seen a lot of projects with different scale.

And our team is working with small apps. There are couple of hundreds or a couple of thousands of lines of codes to enormous applications that are over 14 million lines of code. So we need to make sure that scales and scales ups and down. That's part of it. Google definitely the brand there is helping.

Angers brand as well, like anger. Jess turned out to be extremely successful because it was solving a huge pain for developers and the anger brand is still here. So anger, Jess opened the door and now we have anger that is really highly inspired by Jess, but I would say also evolved with [00:09:00] the evolution of the JavaScript ecosystem and general front-end development over time.

And the thing that I mentioned about best practices and software engineering, like just software design patterns, this is still the case for Angular. We're like putting a lot of work into making sure that Dakotas maintainable and following certain practices that we have discovered at Google as. Good practices when building software.

There are examples such as like testability and you're always built with testing in mind. And we don't have to do any unconventional work such as like monkey patching the window object or like any dirty hacks to. But just mock dependencies. We just use our dependency injection mechanism and you just passed the mock dependencies at test time.

These are three of the reasons that, that I definitely see.

There's, thank you for that answer. It definitely helps people probably also trying to grow an open source library. On what to focus on, [00:10:00] not to help it grow. As Angular has grown in, seven times in the past five years and so on, it's grown also in the face of competition, right?

And I don't mean competition negatively, I just mean there's a lot of options nowadays, especially around things like solid selt kit selt. Quick and react, of course. I'm curious, how has this competition influenced Angular? I know for example, that you're moving from zone js to signals, and I'm assuming this is because of the competition with solid, but I'm curious how else the competition has affected Angular and its development.

Yeah. I love that you're bringing it up. And also I love that you're positioning like competition and just having different alternatives is something good. Not necessarily bad because I see how the community often thinks that framework alters there spending their time in the. Like a dark basement trying to compete with everyone else in heating water frameworks, which is definitely not the case.

We've had Ryan ero from solids given, give us a talk about their activity model. We had Rich Harris talk [00:11:00] about sve. us like, so we are in touch. Like we discussed hydration recently with him. We had Evan New and obviously Mishko who built Quick, was very heavily involved in the initial design of Hangar.

Yeah, we're talking to all these people and. We're learning different things from each framework. For example, when we were evaluating the different, like we wanted to change the dangerous activity model because we saw that zone just might not be the most optimal thing because of the way it operates.

It just assumes that we're going to be performing global change detection. We started researching different alternatives and we have also always we already have a compiler, so we're thinking should we just make our compiler a little like. More sophisticated so it can track dependencies at build time or, and this way we can have a runtime reactivity that is supported by this compiler, or should we just keep it the way it is?

Compiling templates to very [00:12:00] efficient instructions and using alternative reactivity primitive, such as signals because, Why not? Or should we use signals in the way that they're being used in solid? Or should we explore something more with proxies instead? So we just explored this activity space.

We learned a lot from different frameworks, from solid, from felt. We learned a lot from view, like all these frameworks which have already really well established patterns for reactivity. And we try to put these reactivity concepts. Into the context of Angu and see how they fit the Angus mental model and Angus change detection and what is going to be the most efficient, the most like performance and developer like ergonomic thing for us to do.

So we decided to go with signals. That's one example where we drew a lot of inspiration from solid jazz, for instance. And this has been an ongoing process. We're looking to how it can improve the anger altering experience because we got feedback from [00:13:00] one of our developer surveys that this is a good opportunity for us to modernize the.

Altering experience for components. We have been looking at the entire framework space and evaluating the tradeoffs for each individual altering format and figuring out how it fits the anchors principles. So one of the minor changes that we did recently, I'll say it's minor just because just changing the control flow statements like our NGF and NG four are now going to look a little bit more People are saying that they look a little bit more like selt, but I'll say that they look a little bit more like the temping formats that inspired SELT in the past. So it has been just like a cycle over time where different concept just proved to be successful over time by being adopted by next generation technologies.

Yeah. I like that you point out and I agree with you, that instead of this competition that people think exists, it's actually, you don't compete, but you complete the ecosystem, right? The, everything has its [00:14:00] place, and I really appreciate you high. Lighting that point. You talked about, opting for solid inspired signals specifically.

I'm curious if you could speak a little bit to how, the signals work in solid versus how Angular is implementing them. I know this because solid, for example, will use signals in tandem with a compile step. And I'm wondering if Angular does something similar or if it's just a little bit of inspiration and then you're doing something different behind the scenes.

Yeah. There are some slight differences. So the signal library is generally pretty small. It's about 200 lines of code, but there are a lot of variations in semantics that can happen there for example, the in your signals library. That's a lot of like laziness embedded in it. So we are not performing a computation until it is absolutely necessary for us to do and anger has been having a compiler as well for many years now. There are similarities in the sense solids Signals are just reactivities more like both angu and solid are fine grained, but solid is going one level further. They are on like individual expression [00:15:00] level. The reactivities there is on individual expression level where for angu, we decided to go a little bit more. A little less fine grains and we're performing reactivity per view level, and it might not be obvious what view is in angu areas, like a concept that we're using mostly internally within the frameworks runtime. We can think about it as being a fragment from the template of a particular component. We decided to go with this approach just because, just we think it is good fit for Aguar and even though it is not as, Precise when it comes down to updating a particular, the result of particular expression, it's has less of a runtime overhead because we'll have to wrap fewer parts of the view in an effect when it comes down to figuring out when a signal within this effect has changed.

So both have their trade offs and that's the biggest difference, the level of granularity.

For those listening and maybe who aren't as familiar with some of these concepts I wonder if you could [00:16:00] spend a few minutes just talking about signals and effects and, tracking effects that change. Because I think there's a lot of people who just haven't read the content about that.

Yeah that's a good point. So a signal, we can think about it as a value, which we can read and we're getting also we, we can read it and we can set the value. That's pretty much what a signal is. We can think about it, I guess as some kind of a variable. But with I gather and the set methods, there is also the concept of effect.

Select a proxy.

Like a proxy. Yeah. It could be implemented with a proxy.

Okay.

And effects are just functions in which we read signals and these functions get executed. Once we change the value of , any of the signals that are read inside of them, that's pretty much it. So if we have let's say signal title and inside of an effect call back, we read this title or let's say load in the console.[00:17:00] 

Once we change the value of the title, we're going to output the value of the title in the console. That's pretty much it. These are the concepts that. Are relevant for our conversation here.

So for those listening who may be familiar with things like RX Js or Redex it's effectively a subscriber to an observable as an effect, and an effect is observable. Is that close enough? For an analogy for people listening.

Yeah. I like to position r js very different compared to like signals mostly because I like thinking about r js as mostly process sync of a synchronous stream of data over time. And signals are a simpler concept that. Has also a lot of similarities, but we don't have the whole set of operators, let's say.

We're not going to be mapping signals to different values. We can do that in anger if we want to, but we'll first have to convert the signal to an observable.

Okay so a signal is a way to read a value and when the value is updated, notify a subscriber, a k, a run in effect um, and an effect could be. [00:18:00] Updating the DOM or updating a piece of the virtual dom, if you're using that or via compiler, actually update. Run an effect. Update an element attachment element.

Okay, so effect react to changes in signals. Effects our subscribers. Signals. Great. I think people will appreciate that distinction just as we continue the discussion. Fantastic. Okay so in, in a way it's very similar to solid, but you have mentioned some differences there. I'm curious, so is the feeling then that as part of the new direction of Angular that signals would help the reactivity model?

And also you mentioned the authoring experience. A lot of people personally, so I spend a lot of time at conferences talking to a number of developers, and a lot of the comments I hear about Angular are around the authoring experience of components where they say, oh, I don't understand the decorator part of it.

Why do I need to write? And what is like at, I think, NG module or something? and people find that. Hard to GR in the beginning, but of course if they're seasoned, angular developers, it goes away. I'm curious if you could speak to how the authoring experience is [00:19:00] changing and how signals and the reactivity model affect that.

Yeah. I actually, I love talking about the careers because. There is so much history there, and there are so many strong opinions about altering format as well because we really get attached to some certain like syntactical constructs and that's very understandable. We have to interact with them constantly interesting about decorators.

The anger team originally proposed decorators to piece 39 many years ago. And they were, they had different semantics compared to now. They were entirely, we call them design time, but they didn't have any runtime semantics at all. They were just syn, just constructs that exist when you're writing the code.

But at runtime they had no meaning. And that's how we're using them in anger. Most of the time we just Use them to figure out which class is a component and what is the template of this component, the styles and the selector. We have been exploring [00:20:00] alternative we have been looking into alternative altering formats as well.

It's very early stage. Pretty much we have been doing some very early prototyping with Pet projects and it's not obvious what is the best altering format moving forward. So I can't really comment on what we'll be doing in the future right now, just because we're not aligned on the team as well.

I have my own opinions. Our people on the team have their own opinions, which are mostly aligned, but it's not obvious. We need to just put all of them in one design document and evaluate the trade-offs.

So what I'm hearing is since everything's so up in the air and not, there's not a lot of consensus, there's maybe a tiny chance that Angular just adopts J S X and we all just continue to write. 

Yeah, we have been talking a lot about G S X I honestly like GS X because of multiple reasons, but also it's. I have been getting a lot of questions from people what GS X actually means because is what solid J using is it gsx or is it just a GSX syntax? Because GSX has [00:21:00] a syntax, it has also a runtime semantics and it has also some.

Kind of typing information that comes with it. And solid is aligned with the syntax and with the type typing, because you can use it with type script. So they're, you can write valid type script with the TTS X in solid, but they have different runtime semantics, for example. They're not consuming it the same way that react as where they're constructing the virtual dome with it.

Yeah.

So I love a lot of the aspects of Ts X and my opinion here is not like share between like everyone on team, everyone on the team. Some people are feeling stronger that maybe we should be using the same tempting language that we currently have. And I can see definitely the advantages of it.

If you want one more opinion in your pool. I'm for Jsx and Angular. But I also see the standalone type of authoring components at a few conferences here and there. And that looks very interesting to me personally as well. Speaking about Angular, this talk is titled Angular Momentum, and it's about how Angular is [00:22:00] indeed gaining momentum and growing and all of the new things that are coming up.

I'm curious if you could speak to Why adoption by a large community is key for angular. It could be this thing that you just use at Google and it's great. But like it seems to be also in your dev role, right? Uh, Growing a large community of developers is important. And really in a way pushing it to be a popular framework for UI development is some type of kpi.

Why?

Yeah, there are quite a few reasons. First of all, if Google builds a popular framework, eventually when Google. Hire as developers, they'll be familiar with this framework that is used internally and they'll be able to ramp up faster. But also when we have a very popular framework inside of Google that we have built, we're getting a lot of support from the larger community like Stack Overflow.

There are a lot of community libraries which we can directly use at Google, and this is quite helpful for us for sure. We are getting uh, additionally like some just. Doing [00:23:00] something good for the world this way, just releasing cult that is completely open. This literally changed my life personally, and I see how it is making a big difference for a lot of people around the world as well.

Just teaching them best practices enabling them to grow in their career. There are quite a few reasons for that. The ones that are supporting the business are probably directly, are probably the first two that I mentioned. And we can also see that pattern in many other companies.

For instance, Versal, they have Nex J I'll say Nex. J is very well tied to Versa, Brazil's cloud business. And we have builder that came up with Quick, which is supporting their e-commerce platform. We have additionally Netlify that is supporting now. Solar Jess. So it's a common pattern that we see right now where when someone adopts a particular framework, this could eventually provide a smoother adoption curve to other services.

We, for example, are trying to provide a really good integration between anger and firebase. This is not on the [00:24:00] Angus plate. This is the Firebase teams work. We're pretty much entirely focused on the framework right now, but yeah that's another. Example.

Awesome. Thank you for that. That's a really good answer. I, I wanted to Spend some time talking about, you mentioned quick a few times. And I know there's Resum ability, which is this thing that's very popular and it, it's very smart because you serialize everything and you only load JavaScript and at attach event listeners and so on, on demand.

I know Angular 16 has a new hydration system, so it sounds like resum ability, at least for now, isn't on the cards for Angular because you're going with hydration. Is that accurate or is that inaccurate?

Yeah one other team that I'm working very closely with, and I'm supporting them in a similar way, I'm supporting anywhere as the W team. And Wiz is an internal framework that is used by Google search and. Most billion user products of Google, where performance is extremely critical. They have been using the concept of free mobility for close to 10 years [00:25:00] now.

And we are evaluating the trade-offs between developer experience and performance between and your, and with all the time currently. And your prior to hydration, it didn't really have this proper hydration. We were just taking the. Server rendered htm o like when we, when the browser turns, it's to do and we're destroying it, re rendering the application from scratch on the client, which was suboptimal.

And even if we want to go the reasonability direction, we'll first have to make the framework hydrating. We'll have to take this first step. And yeah. I'm not saying that we are necessarily exploring hydration itself, but we are not excluding it as an option just because if you turn out that, This is a viable story for Angu or sub subset of Anor and provides decent developer experience.

We might be able to eventually add this feature.

Sorry, did you mean mobility? You just said hydration.

I'm used, I res.

Okay. Yeah that, that makes sense. Okay. So it's not off the cards, it's just you, hydration [00:26:00] is a step in the direction of Resum ability if you feel it's necessary one day. This is awesome cuz the prevalent discourse is hydration, bad resum ability.

Good. At least that's what the builder team keeps saying. Um, But in your case, what you're saying is no, no hydration actually is requisite for resum ability in some sense.

Yeah. Yeah. And , there has been the argument by some framework orders that you cannot go resumable if you're already using hydration. It depends, . . You might not be able to use the exact same features in the framework that you're using.

Today if you wanna make it resumable, but does that make it a different framework or does it just make it the same framework with more constraints? So \ it's a very interesting topic,

Yeah, definitely. Do you see a future and feel free to decline to answer at all, but do you see a future where Wiz. And Angular eventually merge into one God framework. That kind of just takes over the web cuz it gives you all the benefits of angular and it's really fast.

Yeah well, this is really tight, integrated with the tech stack that [00:27:00] we have at Google, and a lot of these things are just, Not open source, mostly because it doesn't make sense for them to be open source. Just Google operates pretty differently because of the Mony point, the built system we have. Maybe there are going to be some ideas inspired by Wes that they're gonna become part of indoor and vice versa.

But I, I don't see the future where we have entirely like absolutely the exact same tech stack outside of, inside of Google.

. Thanks for, that was a silly question, but I'm glad you humored it. In, in your talk, you mentioned you put out an rfc for declarative lazy loading and templates which is really awesome. Right. And react, we've got the suspense thing going on, and server opponents now have async t for data fetching, which is in some degree could be considered lazy loading.

I guess if your data is. Um, A component or something. Can you explain a little bit more about this rfc and why you decided to add it to Angular?

Yeah, by the way, it was not a silly question. It was a really good question about uh, with, and I appreciate that. yeah, I uh, am really excited about the deferred blog. That's actually one of my [00:28:00] favorite features. Ever. Probably it's a really easy way to lazy load code entirely declaratively just because you're just putting something into a block part of your template and you declaratively specify when you want to load.

These. Like the piece of code, like the part of the templates and all the transparency dependencies. And you're also declar, you're specifying when you wanna prefetch it so you can prefetch it, let's say immediately when the application is open in a non-blocking way with request item callback, for instance.

And you can easily load it, let's say, when it gets into uh, easily load it and render it when it gets into the view port. So this way with intersection observers we're. all the work that's like you have to do manually in many other similar functionalities, and all of this is happening completely transparently.

So that's the feature. You're just take part of your template. You say that this is deferred and you specify when you wanna prefe it and when you wanna legally audit and render [00:29:00] it. That's the whole thing. And there is going to be a lot of. I'll say, I wouldn't say magic, but there's going to be a lot of like behind the scene work that anger does to make that possible.

If you're just going to add a bunch of dynamic imports and within the anger cli, we're going to figure out the optimal bundling strategy for everything that needs to be lazily loaded, and we're going to add some. Further rendering instructions that are going to inform the prefetching and the lazy rendering.

And the most interesting thing is that it may have different semantics depending on whether this deferred block is sero site rendered or not.

Right.

And there might be an opportunity even for partial or progressive hydration. Imagine if one deferred block, if you have two deferred blocks on the page that were both server side render, if one of them is changing state in the other.

We might be able to just have this dependency between them kind of embedded in the server side, render content by just , figuring it out by serializing the reactivity graph. And [00:30:00] Loading the affected block by state change whenever the state has been changed through the signal it's, anyway, there are a lot of exciting things that we're going to follow up with on rfc.

We can spend probably a whole podcast talking about it.

Yeah, that sounds really exciting because I wasn't aware that some blocks could be rendered only. So does that mean then a deferred block, if you mark it as a server rendered block just that block is evaluated on the server and it's output is sent to the client , to then be like effectively not hydrated, but you get the idea to be placed into the block.

Is that how it works?

Yeah, we're not there yet. Currently, if you have a deferred block on the server, we're not going to render it. But there would be a follow up. I believe we're mentioning that even in the R F C, that once, if we decide to server render it, then we may want to not hydrate it. This is just going to be rendered on the server, but not hydrated.

And , we can hydrate it when the user, let's say, start interacting with it so that we can make it. Interactive and handle the user interaction. And that's [00:31:00] relatively simple case. It's, it gets more complicated when this piece of UI is holding state that may mutate the state in another lazy blog that has not been hydrated on the pages yet.

Yeah. And if a server rendered lazy block, whether it's hide or not, . If it observes a signal that updates how does that update in this case? Does the server just push another, something, another object that says, Hey, this, block it, this position, update it with this new output Or how, how, how would that

Yeah. It's very similar to how we are running change detection, very similar to what we discussed at the beginning of the podcast, between like with signals and effects. Imagine we have the lazily loaded block, let's say on the, in the navigation, which gets hydrated, and it mutates state that is used in the main content of the page, like the main block of content.

Now, imagine that we wrap this main. Content in an effect. So we're going to figure out that the signal that we are reading in this main block has changed and this can [00:32:00] trigger like loading the UI and hydrating it and potentially reflecting the changes in the signal through the anger exchange detection.

It's very powerful how we just, these two primitives with signal and effect. We can do so much.

Yes. Yes, absolutely. This sounds a bit like for those who maybe dabble in the astro world, it sounds also a little bit like island architecture where you're able to say, I want this thing to run only on the client, this thing to run on the server, et cetera. And I want this to for example, Astro I know uses intersection observer to when something enters the view port, then hydrated.

How similar or different is this in comparison to Astro's Islands and was it influenced by Astro?

Yeah, that's a, that's an excellent question. I have not been calling it islands mostly because I don't wanna. Reduce the scope of the work that Fred did in Astro because they also support different frameworks and for us it's only anywhere.

I don't know if we have looked specifically. Astro for this one? Just because , we have been looking at react lazy and react expense to understand how react lazy and reactive expense work. And , I'll say that there are, like, [00:33:00] conceptually it sounds the same, similar uh, we decided to go a little bit more declarative way and actually that's part of the reason for this is the anger philosophy.

Anger is. Like really going like very declarative and static. We want to be able to analyze the view entirely at compile time with our compiler and make optimizations where J X is really dynamic and you can do anything you want there. And it works great with the virtual dome model, but when you wanna.

Start optimizing change detection further, or you wanna do some different compiled time optimizations. You just need to set constraints and change how GS X functions the same way that solid did, for instance, they have custom control flow there and I love it. And with anywhere we decided we're still going with templates and probably that's the direction will be sticking to mostly because. Of this constrained space. There is a really good talk by a former coworker of mine, the power of constraints, which explain how you just make something a little bit more constrained. This enables you a lot of more [00:34:00] optimizations because of variety of reasons. So just making, just by making the view declarative and a little bit less expressive , would allow us to make it.

Way easier to optimize and way easier to read as well because I've seen some very tangled gsx, for instance, with a lot of nest control flow and complicated use.

Okay. In your talk you mentioned using ES build and it changes the way how Angular builds. I'm curious if you could speak to how Angular was being built before adding ES build. And now the benefits of using ES build after.

. Yeah. I'd say that that's a big difference between the anger kind of ecosystem and other communities. I have been getting questions from people on Twitter on like, why is anger using its own cli for instance? Why don't you just enable simple built with vt? And that's something that maybe we should do.

Uh, One of the reasons why we did it is to. Ensure that we can change the built mechanics without breaking , like developer applications. [00:35:00] So if we have an application like if we have, if you're managing your whole built process within your C L I you don't have to think about optimizations that you can make in your build pipeline so that you can produce smaller bundles.

We're just gonna change . This particular piece of the Build pipeline and we're going to enable smaller bundles for your improve your build process. And that's exactly what we're doing with Use Built Before Buil, we were using Webpack. And uh, it's really powerful for sure, especially after introducing this caching in version five they made built even significantly faster.

But in the meantime, we started using Webpack in combination with buil. We were using Webpack to bundle your application, and after that we're passing this to buil, to minimize, to like optimize your bundles. We're using it only as an optimizer, and this already improved build speeds with about 10% 

Wow. 

relying only on Terser, because we're using entire terser, which is JavaScript paste.

And that's what's completely transparent for people. [00:36:00] They just got their fa their builds like, 10% faster. After that, we changed the way we're doing some compiled time transforms with our built optimizer and we improved build speed with another 10%. And after that we're thinking like as built is growing in maturity.

A lot of people are using it and are successful with it. Why not try to experiment with replacing Webpack with is built entirely and just ensure that everyone's built, continues to function just the way. They function today, but just making it faster. And yeah, we did that. And uh, some of our early test point show that a lot of applications receive like all of applications built, gets about 2.5 times faster just by updating.

So latest saying U C L I.

Wow. Is that because ES build is built in a different way than Webpack somehow and it's built for performance. That's why,

Yeah, it's implemented in Go, so it doesn't necessarily use JavaScript for everything. And performance benchmarks have been very [00:37:00] important , for the use build team as well. Specifically for Evan 

I wonder if at some point somebody's gonna come and write another ES build, but in rust and that's going to be even

Yeah, there is one already what is it? It's wc.

Yes. Small web compiler, that's from Versal, 

yeah. I think it started as an independent project and they ended up hiring the maintainer. So that's, yeah, that's another example.

did Angular experiment with that as well to try and get the builds even faster or?

The difference was not too significant. And at the time when we started using buil as Wuc has, was not like, we didn't consider it to be as like mature yet. And if we're going to migrate some of the biggest corporations to a build system, we wanted to make sure that their applications are gonna work.

Yeah. Yeah, that definitely is important, especially when so much business depends on it. Alright, we've got a couple more questions I wanna, I wanted to ask you about. Angular has always been, at least to me you know, I like your mental mapping of. Angular doesn't actually map to react, but more next Js cuz [00:38:00] Angular is a framework.

It's kinda like a Swiss Army knife. It has a lot of different things and it gives you these things. For example, even routers, right? With React, you don't get that. Angular has things like forms routers. I heard something about a cdk, a cloud development kit. I don't really know if that's a thing, but I'd love it if you could speak to the other updates to these various angular components that you seem to have mentioned in your talk as well.

Yeah, re react and nex J like anger maps better to nge, but it's somewhere in between. Also, because it provides you this full stack for development of frontend applications. We don't necessarily have the backend component here. We have the server site rendering, but we are not providing you these like API routes, for instance, with and. We want to make sure that if you're building a ui, you have everything that you need, so you have the framework to build your components, but you also have a forms module that is following the exact same versioning as the framework, and we run integration tests all the time since Pulse. Itself and the [00:39:00] forms module, they live in the exact same monorepo. So we have plenty of integration tests there, and we really know if something breaks, just because every time we push a commit, we're going to test to either of these, we're going to test it against the entire Google Monorepo with I don't know, 4,500 annual projects or so. So we wanna make sure that , we have this really well integrated solution that is stable and yeah, works across releases. And yeah, as you mentioned, we have the forms module. That's only one part of the piece. We have the router, which has been having, it, has been featured complete for the past six years now, seven years now. Having variety of different features, preloading, nested routes, obviously, and even some.

Magical features that I don't know about that are too shakeable if you're not using them. Uh, We also have service worker. We have, as you mentioned, the cdk. The CDK is the component development kit where you have, we have a set of components that you can directly take and use in your application and style them [00:40:00] based on your

design. 

they're like headless components, like select and things like this that you 

can, okay. 

And the C also comes with. Different tools for accessibility. Like accessibility has been critical for us at Google and we believe this critical for any application. And I understand also that when you're building a startup, you can't really focus on accessibility too much. Like you target, you wanna ship the application for most of your users with like you have with 20% of the effort.

You want to get 80% of the results. So it's understandable. That's why we have the cdk, so that you can make your application accessible as part of these 20% of the effort.

that is so awesome. So if I think about these things, forms, routers and C d K I can literally think of. Different React libraries that do this, but they're discreet, they're different from React. I think of Formic or React router or reach ui, which are all just separate MPM things you installed.

But I love how Angular just encompasses these in itself. And as you mentioned, it's tree shakeable, so if you don't use it, you don't [00:41:00] pay for it in a way. That's fantastic. All right, we're about to wrap up, but I have to ask you this Miko, cuz I really want to hear from you as the.

The person who works on this day in, day out what do you see for the future of Angular going forward? It's already in quite a good place, right? There's standalone components. I'm really, personally very excited about that. Just the simplified authoring experience. There's the signals, of course, there's all of these things coming for the future.

What are you excited about?

Yeah, we touched on a lot of the things already that we're going to be working on in the future as well. Signals they're at their very beginning, like phase. We have the signals library and now we're going to. Work on the fine grains change detection in version 17 that we're going to ship I guess in November.

And from there we'll be looking at further improvements on the deferred block so that we can incorporate it as part of server side rendering. And yeah, these are two of the bigger things that will be happening throughout 2024.

Fantastic. These server just I'm still obsessed with this server block [00:42:00] thing. Are they close to what we consider react server components where the. The blocks as it were render on the server and their output is sent to Angular on the client side and then rendered by client side Angular, or is this, do, am I off understanding that?

Not necessarily, yeah, we are not necessarily aligned with the philosophy behind reactor or components., I guess depends there. Reactor components are, I guess a lot of things. But it will enable, the deferred block will enable us to have server only components, let's say.

So if you wanna render a component only at the server and not pay for the JavaScript in the browser, this is something that you'll be getting. We're not gonna. Since like anger doesn't use virtual, do rendering on the server and getting the patches that you need to do on your component in the browser, that's not gonna be part of the story.

Okay.

And we're not gonna have the data aspect as well, especially the data aspect. We're feeling pretty opinionated about it because it gets really easy for you to lay to leak sensitive data on the client. If you have these server blocks there are all our frameworks. [00:43:00] We are experimenting with them and this is something that makes us a little nervous.

So likely we are not going to go this direction. But there are alternatives. we, , we have been experimenting with server only services uh, which enable part of the, this in the part of the data story, not part of it, but like the entire data story, 

fantastic, man. This could honestly be, this could go on for another 45 minutes, maybe half an hour. But let's leave it here just in, in respect for your time MKO, honestly, such a, such an honor to be able to talk to you and get these insights from Angular. In closing the podcast, I'd love to give you the opportunity to wrap up with any closing thoughts or anything you wanna highlight.

Yeah, just thank you very much for listening to this podcast and I really appreciate to hear everyone's thoughts if you have any comments about what we have been up to. And if you have any feedback that you'd love to share, just feel free to connect with us. We're the, and your team, we're on Twitter or commenting our RFCs, we really wanna make sure that with uh, the projects that we have on the [00:44:00] roadmap, we're.

Solving developers' problems and we're making anger better for everyone.

Yeah. And of course all the links to the RFCs, to the Twitter, et cetera, will be in the show note captions. So feel free to check out the description of the podcast episode. Minko Giev, an absolute honor privilege. Thank you so much for making the time to come on the podcast, chat with us and share your knowledge.

It's it's a huge honor and I don't take that lightly. So appreciate your time.

Really appreciate it for having me. Thank you.