Angular 17 with Minko Gechev
===

[00:00:00] Hi there, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Head over to logrocket. com today to try it out for free. My name is Paul, and joined with us is quite the guest, we have Minko Gechev.

He's returning once again, here on PodRocket. Minko is the engineering product and DevRel lead over at Google for Angular. So we're going to be digging into Angular and some of the really significant new changes and new features that are dropping with Angular 17. We're going to be getting into the release of Angular 17, and we're excited to do it.

Welcome back, Minko.

Hi, Paul. Glad to be here.

So Angular 17, this is like a significant push in the ecosystem. Would you say this is one of the big daddy releases in the past few years?

Yeah. But also at the same time, we have been building up this momentum for the past, I'll say 18, at least 18 months, 18 to 24 months. And [00:01:00] this is just the result of all these. Small steps we have taken to this point.

So a work in progress. Were there minor releases beforehand or is this kind of been behind closed doors until the past month or two when things have been coming out?

Yeah. Everything is generally available on GitHub and we're publishing it regularly on NPM. So people have been able to give a try of these features for a while now. Some things that we kept secret for the public announcement that we did on Monday. Was the branch refresh and the new documentation website. 

Drashner I'm sure Quite a few people listen to the podcast. No, sir. She called she coined this the angular renaissance the renaissance is quite the thing So I know we have quite a few things to delve into here And Minko you brought up for example the website in the rebrand if we want to start there Why did you guys decide now is the time to rebrand?

And can you talk a little bit about what brought you to the beautiful, like, we have a new logo, I can see you sporting the new logo on the shirt right now. [00:02:00] So what brought you to that rebrand?

yeah. So Angular has been moving forward, like quite a lot. I as I mentioned for the past, about 18 or 24 months or so. We built this like very solid foundation. Back in 2020, we rewrote our rendering engine. I think last time we talked a little bit about Ivy and since then we could be just iterating on it.

Just building more and more features on top. We significantly improved learning experience by introducing our standalone components. And since then we have been evolving the framework a lot in. performance and developer experience, but at the same time, the brand has been pretty much like consistently the same since I'll say about 2010 with AngularJS, which was even a different framework.

So we just saw that even though the framework is like pretty future looking right now, the brand is a little bit lagging behind and we want to make sure that the brand also reflects the modern framework that. And your turn to be. And [00:03:00] with this, we also decided to improve the learning journey further by adding an interactive tutorial based on web containers.

And we're thinking well, if we're going to refresh the brands and we'd like to really revamp the learning journey, maybe we should just also re implement the websites and improve the documentation, like the way we are surfacing is to developers further. This is what we worked on for the past, about one year, like the brands took a lot of iterations.

We. We had a designer from Google working with us specifically to make sure that with this new brand, we're reflecting the stability and velocity that Angular has been providing. Also, we had a look at the broader ecosystem. We want us to make sure that we're aligned with the trends in web development and also in the broader like software engineering industry.

So we did quite a few iterations there and finally we landed on something and we. Incorporated that's in the new website.

For folks listening, the website if you want to go get the documentation is angular. [00:04:00] dev. 

yeah, this is currently our beta website. We're going to make it the official new documentation websites around version 18, which is going to be six months from now. That's the current plan.

So right now with this new path to foster learning and adoption, you guys have an interactive tutorial, refresh documentation. Is there something else that the team is proud about in terms of opening up the funnel and approachability of the ecosystem?

Yeah. We have been iterating on the. altering experience for Angular components and also reducing the amount of concepts that we are introduced, that we are introducing since the beginning as part of the critical learning journey. So there are some things that Angular is unlikely to make a compromise with.

For example, static type checking with TypeScript. We're pretty opinionated about that. We realize that moving forward with JavaScript. This might be a little simpler for people getting started, but also if we move to JavaScript, it is going to impact applications that like developers that are building applications at scale.

And additionally, we'd like to provide a consistent developer [00:05:00] experience with Angular that doesn't really vary too much across different projects. But there are some other concepts such as RxJS. Let's say that we have been introducing like pretty early on in the developer journey, and it's not necessarily a core part of Angular itself.

You can use RxJS. It is great for certain use cases, but you don't have to use it from day one. And it's pretty harsh to use. It has a hundred, over a hundred operators. And I know a couple of them that I've been using over the years, but it's overwhelming to see all this list of operators on the website.

that's another part. I think we are also iterating over the. component developer experience. So we are doing small iterative changes there as well. Standalone components has been making a big difference in the community. And we see that currently that's what people use to develop new applications since the beginning.

So the concept of the so called like ng modules that we had in Angular, Still available. So we're not going to break existing applications and they'll be there for foreseeable future, but at the same time, if we're getting started with a new project, [00:06:00] we would rather get you started with standalone components and optional engine modules.

So you don't have to think about one more concept. We additionally also provided a migration that allows you to move your application from. NG modules to STEM along components. And further, we'll be trading on the altering experience for components more in 2024 in order to improve some of the rough edges there.

There are still some opportunities that could make component easy, easier to write, and more intuitive, and another big change that we introduce in version 17 as a more intuitive control flow. So, uh, wE in fact run a couple of user studies on signals. This is the new reactivity paradigm that we're using in

If I may ask Miko, like control flow here, we're talking about like for loops and if statements and in the rendered 

Exactly, 

yeah. So yeah, we run these user studies and we saw the developers are struggling to iterate over a collection of items. I'm talking about developers who have not used tenure in the past, and we [00:07:00] thought that this is a pretty fundamental. Piece of doing an anchor and then your application, you almost always have to iterate over a collection.

So we wanted to just make this developer experience for. We wanted to make this like as simpler as possible without also making compromises with some of the core beliefs that we have for Angular. We really want to have statically analyzable templates. Like we would not go with like a similar approaches react, let's say, where you can iterate over a collection with JavaScript and push individual, jSX elements into an array or do all this dynamic stuff that we cannot later optimize with a compiler. wE did a design of a new control flow that is like an if statement for loop and also a switch statement. And we opened a RFC, we collected a bunch of feedback and the community told us, Oh, we like your syntax, but there is here is even a better one that you might consider using.

So this is the, so the add syntax that we have in developer preview in version 17. So you use add if, and [00:08:00] overall it looks exactly the same as JavaScript. So, uh, Yeah, this is another improvement towards better developer experience and simplifying the learning journey, where we also incorporate quite a few performance improvements.

So, , we made four loops about up to 90, 90 percent faster in certain scenarios.

Wow, that's significant. Yeah, that's huge.

Yeah. So this is like a subset of improvements within version 17.

So we have control flow. That's huge. beTter documentation. Just to dive, maybe, into some specific features that you guys are double clicking on. Everybody likes delayed loading. So like people are always talking about react suspense as an example. And I know you guys are trying to keep up with , I don't want to say keep up, but you're trying to make sure angular can play at and be flexible to whatever sort of needs come down the line. So I know at defer is an interesting new controller that is popped into the ecosystem.

Can you talk a little bit about that one?

So with defer, we call them the so called they're deferrable, views. [00:09:00] You wrap part of your template in the add deferred block. And at compile time, we make sure that we extract this part of the template. In a separate bundle. So we extract this part of the templates together with all the transitive dependencies in a separate bundle.

And we load it lazily. And the thing there is that it provides declarative triggers. So you can specify that you want this piece of the templates as part of the UI to be loaded only when certain element enters the viewport. And you specify this declarative. We just say add defer. On viewport and Angular knows what to do.

And so this manages a lot of complex standard hood. It has, it interacts with the intersection observer API. The CLI knows how to bundle this and incorporate like all the transitive dependencies and extract it into a separate JavaScript chunk. And additionally, it also knows how to prefetch part of like these deferrable views.

So declaratively, you can also specify that, let's say you want to start loading when you click on a particular element, but you would like to start prefetching this [00:10:00] once the user. Scrolls and a particular element enters the viewport. All of this is declarative and you don't really have to write any manual logic for it.

And it is aligned also with Angular's philosophy to have statically analyzable templates that are declarative and have good separation of concerns. They're declarative compared to your TypeScript calls where you keep your application logic. We do it mostly so that we keep templates relatively easy to reason about compared to mixing them with application logic and with TypeScript calls where we have seen that this could cause some like exponential growth of complexity in certain cases.

Would you say that as a result, like Angular is more similar to Svelte as we are saying now, because Svelte is still like JavaScript and it blends those in the same view, but it's a compiled statically analyzable set of pieces.

Yeah. Yeah. Angular since the beginning has been having a similar philosophy to Svelte to an extent, but , I'll see it as [00:11:00] somewhere in the spectrum between Svelte and React probably are, I don't know if that's actually a feasible comparison. So something that Angular is working hard on doing is staying.

As aligned with the standards as it makes sense. So for example, we made an exception here with the new control flow, just because we saw it as such an integral part of the Opera experience that even if we are not a hundred percent aligned with HTML spec , this still is going to provide a sufficient, 

increase developer experience benefits. And we are, for example, like less on the magical part of the spectrum. For example we have a signals API that you interact with directly compared to Svelte. They also decided to go with signals in Svelte 5 with their rooms, but it is a different API, which compiles the computation targeted signals.

So there is one more level of obstruction. siMilarly with the observable. Properties that they had, like computed properties with the dollar label. it is unlikely for Angular to go this direction. We would like to be a little bit more [00:12:00] explicit and we're going to even more explicit place where we are right now, because currently we have this magical zone.

js, which triggers change detection or tries to reflect, like triggers the process that reflects. Changes in the view model in the DOM in a very magical way. So we would like to move away from that because we saw that it caused some challenges with debugging for Angular developers over the years. So we would.

Like to find the perfect medium, if we can, between the magic and the explicit. 

Yeah, I know for a fact that's one thing if you're on the YouTubes and you listen to all the people argue about which framework is best, there's a lot of interesting things that people say from every side. And one thing that constantly comes up just in this felt conversation is it's a little too much magic.

Like having things written out can be good. For your dev X, because you don't need to go ask a human being, you know, overstatement for sure. But there is this emotion where it's like being pedantic can be good.

uh, that's, one thing about frameworks that [00:13:00] everyone with their personal preferences can pick a solution and different solutions are opinionated and attracting different developers. So that's something that I appreciate in the ecosystem that we have.

And there's obviously the elephant in the room that everybody talks about. Cause it's SSR server side rendering. It's always changing. And the way that you approach those type of APIs is changing within the frameworks themselves. mean, We're in a time now when we just got Next 14 launched, which has a whole different model of server components. We have React server components. So I'm eager to get into that and ask you, Minko, how SSR has changed in Angular 17. Before we do that, really quick, I just want to remind our listeners that this podcast is brought to you by LogRocket.

So if you're making an app in Angular... React. Maybe you're just playing JavaScript and you want to capture events from the DOM. It doesn't matter what it is. You can go to logrocket. com today and just try out their set of tools and SDKs so you can find and surface issues faster. Use AI [00:14:00] power driven tools.

You can find trends you didn't even notice and spend more time building an app and less time debugging in your console. So head over to logrocket. com today and check that out. So server side rendering, I know there's big updates as well in Angular 17 or over the past 12 months that the team has been working on.

Would you say that Angular has fully opened its arms into being an SSR first framework?

Yeah. So there are a few things there, I guess we have been having server side rendering solution in the past, but it's developer experience has not been what we would feel proud of offering to developers. And lately we have been iterating a lot on that, just adding basic features such as hydration and really improving the build pipeline significantly.

Going SSR first, we may consider that, but we would also make it very easy for people to opt out of it. In fact, in 2024, we really want to make all new projects start with SSR from the start. But at the same time, we realized that not everyone needs SSR and SSR add some hosting [00:15:00] constraints. You need to pay a cloud provider to host your application because it requires some compute.

It requires like some computations on the backend on like on a. Cloud function or wherever your deployments target is that is going to cost you money. And for many applications, client side rendering is just fine. Still, we'll iterate a lot on server side rendering. We're currently in a pretty good place.

We improved build times with 87 percent and we added some life cycle hooks that. Allow you to interact with the dom in a very safe way so that we can properly hydrate your application on the client. And we'll continue trading. In fact, in 2024, we have some pretty exciting stuff coming up with progressive or partial hydration.

And we're going to make also SSR streaming to be more integral part of , developer experience as well for. Apps where performance is really critical because I know a lot of people talk about streaming, but we also looked at some statistics and in turn out it's like around less than 10 percent of people are using streaming with SRA.

In fact, so this is. It's not as many people as [00:16:00] the amount of people who talk about it, but we'll still want to make sure that it's a part of the core of the server side rendering functionality that we offer for Angular.

tHat's a really interesting call, Miko, because you specifically are mentioning you guys looked at the stats. You're looking at data and you're adjusting the features and focusing the team on these features that the data is suggesting and not just sort of like looking at what's newest and then trying to make sure it works with Angular.

And would you say that this sort of behavior of focusing pedantically On say, this more opinionated Angular way of doing something has given rise to more friendly developer APIs that are more organized. Is that sort of the direction, the ethos of Angular at this, in this age?

Yeah. It is for sure in the core of everything is doing very. Like evidence driven decisions that so we consider many different inputs even this podcast would be an input for our roadmap for the next year. As we, we discuss what developers are [00:17:00] used to and what developers are using. We, collect feedback from social media, collect feedback from GitHub. We talk to developers at conferences, run developer surveys, user studies uh, interviews with large enterprises or with small startups. And we try to find out, find what is the overlap between these different asks and developer needs. And we prioritize them based on the impact that they're going to make and the current state of the product.

So from there we iterate on solutions and I'll say where we really, really understand where an API would work for developers or not is once we run an RFC, we collect a lot of thoughts from people there, but that's not the last step for validation for us. After I'd go to user studies, once we prototype something, we're on studies.

We literally. Look at developers, write code and use this particular API and review what they're struggling with so that we can iterate on it further and fix the rough edges. And after that, once we have the API, [00:18:00] we work with enterprise partners or with Googlers, luckily we have. Thousands of developers using Angular at Google.

So we can connect with them and see how they use a particular API and whether they're struggling or not and how it works for them. So we can further iterate on the future on the feature and finally ship it in developer preview where for six months, we collect more feedback until we graduated out of developer preview and make it officially stable following our semantic versioning.

the way we evolve APIs. Uh, So we cannot change the API in a backward incompatible way, unless we have a major release. And also for us, it's critical to have also code transformations that. Can update your projects to the new API.

And speaking of backwards compatible, , everything that we're talking about here, Angular 17, it's backwards compatible, correct?

Yeah. Everything is backwards compatible. We have the new control flow. So there is an automated migration that can move you from the current control flow to the new one. And the control flow currently is in developer preview. This means that we can change it at any point uh, in the next six months.

And after that, we're going to lock it. [00:19:00] And there are still some things that we're trying to. Ensure backward compatibility within the control flow. There are still some corner cases, some edge cases that we're going to. Iterate on until we graduate officially from developer preview. There are some breaking changes.

Like in the, we do the major updates, major releases, because we want to open the door for some breaking changes. But,, the breaking changes are, for example, we now support Node. js version 18. 13 or newer. Or we support TypeScript version 5. 2 or newer there in this scale. There are also some, because Angular has a pretty large API surface and we really know when we break something, we really know that it's broken because we push the change at Google and at Google, there are hundreds of thousands of tests where if even one of these tests fail, we consider this a breaking change.

So we have really high confidence in understanding the impact of the breaking changes that we ship as part of a major release. That's why we could be so like pedantic, so explicit [00:20:00] in listing, let's say 20 breaking changes out of these 20 breaking changes, maybe there might be one breaking change that is going to impact you, but we see that from release to release.

The update experience, the breaking changes are usually not the problem. Sometimes what people struggle with is mostly the third party dependencies that have not been updated to the latest version of Angular. And this seems to be a consistent problem across the entire JavaScript ecosystem. We may want to look into it.

Yeah, that is certainly a persistent problem. It doesn't matter. where you are, right? your toolchain and your package chain, 

and everything working together. zooming out a little bit and looking back at, the landscape of where web frameworks are right now. Another thing that is very popular with developers is the view transitions API.

This is something that has opened the door for lots of creativity that would have otherwise felt a little bit convoluted to implement. Now, I know you guys are adding this API, right? Is it a fully fledged feature? And it's fully supported? And do you have plans to like, [00:21:00] add extra stuff on top of the view transitions API?

I'm eager to hear about what you hope to see developers contributing to that.

Yeah. We have been working with different groups, at Google and standardization bodies to see where we can extract, like get the most value from the view transitions API. We have integration with Angular router right now. So you can use the view transitions animations rather than the router animations.

So that's where it currently is in Angular and we're going to. Look at the adoption of the feature and the feedback that we received and see what we are going to do from here.

Awesome. Now Minko, I know a lot of the topics we've talked about today, like the control flow, this is An internal push from Angular.\ correct me if I'm wrong, but the motivation here is to make it easier for developers, make the code more maintainable, make it more explicit, like all these great things.

We have APIs like defer, view transitions, API support, like we can keep up With some of the crazy animations we're seeing from the svelte people where it's like they just drop in one line of code and boom, because it's view [00:22:00] transitions. It's a great API. And I know if we think back to when angular was like 10 years ago, and the whole ng module paradigm, like at the time, that was really cool.

It's so modular, you can just import things. And it was just like, wow, nobody else is doing like this ng module sort of thing. very nicely wrapped up ecosystem. And it felt like a very like unique thing that Angular is bringing to the table. It's something that attracted people from all swaths of the developer community.

Some of the topics that we talked about today, even though like control flow is Angular specific, some of these topics, they do feel very like, standard and they are allowing the breadth of Angular to once again be applicable to whatever situation is at hand in this modern landscape. So that being said, I wonder if there's any topics.

or updates in Angular that you feel like have that same veracity or flavor as something like when ng modules , came out 10 years ago, that helped draw a defining [00:23:00] line around Angular. It says this is something that like we do differently, or it's something that we do special that the other frameworks don't reach for.

Yeah. There are a few things. So as I mentioned that velocity and stability, our key strengths of Angular and I keep talking about stability and every framework claims that it is really stable and I'm sure like framework developers are doing the best they can to keep the framework stable, but I'll say still that this is.

One of the biggest strengths that are unique to Angular, just because we have this enormous code coverage with millions of lines of Angular in Google. And we really understand the usage of the different APIs. That's part of it. Another part of it is 10 years ago many frameworks just, in the ecosystem, there is a lot of inspiration from different technologies.

Like Angular is inspired let's say by SolidJS with signals and inspired even by Rails, by Ruby on Rails back in the day with The Angular CLI, we would like to provide this Rails developer experience for Angular for the web. And many frameworks are getting inspired by [00:24:00] Angular the same way.

So I would say over time, this difference is shrinking a little bit. We started building, similar solutions in a way, but there are still things that are very fundamental to Angular that. It would be really hard to incorporate in another framework just because of the maintenance model of the framework being maintained by Google and being so widely used inside of the company and having this monorepo.

Another thing that has been going on for the past, I'll say maybe a little over a year now is we have been working very closely with a framework called WIS at Google. And this framework is. Use for all the billion user products that Google has for Google search, for Google drive, Google photos, and so on and so forth.

It's

enables you to build really performant applications at scale. So I am anticipating this to have its impact on Angular as well. Angular is already very much focused on scalability because we have really large applications at Google and outside of Google that. rely on Angular to

[00:25:00] enable like hundreds, sometimes even thousands of developers at Google to build on a shared code base. And , you can see also the performance aspect that Angular has been , incorporating more and more which is I'll say partially inspired by this collaboration with Wiz.

My main takeaway here is that Angular is still focusing on, like you said, maintainability, scalability, and being able to have a really solid framework to bring a product to scale.

for Angular is still really critical to be a reliable solution. We have been innovating a lot. Lately, and we have been shipping a lot of new functionalities, but everything has been in a stable way and we would want to get people excited that their framework is making their lives easier, but in a very mindful, backward, compatible way that just seems more reliable and stable.

It is more reliable and stable. \ .

Yeah. 

we're probably talking to a whole myriad of like different framework [00:26:00] lovers on this podcast, but I know a bunch of people love react, right? If you wanted to tell somebody, Hey, go make your next to do list in Angular. Like, iT's going to be great. We have a lot new features.

Like you should test out the ecosystem. I know you've been in this one, but come over here. One of the reasons why you should come do this. If you say, Oh scalability that's really important. But is there something maybe on the tail end of features that can appeal to an individual that would say this is really easy for you to wrap your head around in our ecosystem.

Yeah, first of all if someone loves, really loves React, they should continue using it. And if they're happy with it just continue using it. If you're successful, if you would like to give a try of Angular, a lot of, some of the things that would probably be interesting to you as, the new reactivity with signals it brings performance to another level, literally.

If you want to build really highly performant user interface. And use a solution with well established support model. It would probably Angular in this case. I know there is this still myth around virtual DOM [00:27:00] that is really fast. And, but there is really no, it's just a statement without really proof for this.

And it could be fast, but depends what you do with it. This reconciliation is not really as fast. And frameworks such as Solids show this, you have signals, which allow you to update exactly the part of the DOM that has actually changed. And in virtual DOM, you cannot really do this unless you add a lot of like manual, like there

with, , use memo or in the past with like shoot component update.

In Angular is adopting the signal based approach. And it is also adding a compiler that at build time can ensure that it provides fine, like Angular has fine grain reactivity that's enables you to just update particular parts of your DOM when the associated state changes. So performance and stability 

That, that, that's really massive to that's a whole new update model. And I know that, passing internal state around in your components is not,[00:28:00] it's easy to wrap your head around if you're getting into web development, that doesn't mean it's the best solution for the task at hand.

Like you could be using Dom events for an example, and then here in the Angular model, you could be using signals, which is also like a widely supported concept and mental paradigm that people can wrap their heads around. And like you said, it comes with a significant. Performance and boost correct?

Yeah. It's we're still iterating on the solution. This is something that is going to land in Angular Maybe 20 maybe version 18. We would like to just make sure that we introduce signal signals in a very robust way, because it needs to interoperate well with the rest of the framework that has its own change detection model.

We are going to continue trading on it. And we already see the benefits, including with the new control flow.

So, lIke we mentioned at the beginning of the pod today, if you want to see what's going on with angular, check out their beautiful interactive tutorial with web containers, angular. dev. If people want to get more into the angular ecosystem, maybe not [00:29:00] checking out the tutorial. What are some other resources Minko that you.

would urge people to go check out.

, they can check also the version 17. Announcements at blog. angular. io and we had a really fun launch event. So make sure you check youtube. com slash Angular. We had a live stream with a bunch of video with the videos with the feature announcements and also taking audience questions.

This happened on Monday. It was a lot of fun to be part of this event.

And Binko, I know you are on the DevRel team, so external communication is always part of those roles. Where can people find your thoughts and your updates on what's going on with Angular?

I'm um, on Twitter or X at mgetchev, the first letter of my first name and my last name. And so I've been posting updates on LinkedIn also a little less hipster place, but I've been seeing that a lot of people engage in a very constructive way in there. So that's another place where you can see me posting.

Awesome. Minko, it has been a great time [00:30:00] for me. Honestly talking about Angular 17, it's one of those things that everybody, you know, if you've used it in the past, And then you want to come back to it. These are just like really enticing features. So it's exciting to hear that the team's been looking at the data and working on these things.

I'm definitely excited to go give it a whirl and thank you for your time coming on and talk to us about what's here and what's and what we can expect.

Awesome. Yeah. Thank you for having me, Paul.