Angular v21 AUDIO EDIT === Paul: ~Hi there, and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. I'm Paul, and today I'm joined with Mark Texan and we're here to talk about Angular V 21. It's a big upgrade. There's a lot of things to talk about, not just on how you might structure your app, but how you might work in teams, how your different team organizations might change and how we can like progress and, excuse me, sorry, mark.~ ~I lost my, my, uh, preamble link right here. I'm gonna restart. Here we go.~[00:00:00] Hi there and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. My name is Paul, and today I'm joined with Mark Texan, and we're here to talk about Angular V 21. This is a lot of changes going on. We're gonna dig into not just how you might change working within your team to move faster, but structuring your app, things from testing to UI and ux. We're gonna dig into it and happy to learn. So welcome to the podcast, mark. Welcome. Happy Mark: having me. I'm so glad to be here. Paul: So Angular V 21. ~When, when did this officially get announced? Uh, and I'll, ~I'll set the stage here a little bit, mark. ~Um, ~we're a very react heavy audience and a lot of times when we talk about Angular, ~it's, you know, ~we get questions of ~like, ~okay, so ~like, ~is this one I should switch? Is this one, I should re-look at Angular as a React person. So some of the questions might be flavored like that. ~Um, so stepping back, back, uh, back to V 21, when V 21 launched, when was it? When did you guys decide that was the right time to cut over, uh, and expose that next version, ~ Mark: ~Sure. Good question. So we actually do two releases per year. So we knew that V 21 was gonna be the third week of November no matter what. Right? So like that was just going to happen. So I think we released either the 19th or 20th of November, and because we do a spring and then they winter release, so some people might say fall, spring slash winter release. We already kinda know what our schedule's gonna be for the year, even before the year starts. We already know, and we don't do time based releases, I'm sorry, feature based releases. We do time releases, so whatever's ready at the time of the release is what we include in that particular release. We think that right now is an excellent time for people to look at Angular.~ ~Did you, you know what friends at home who are watching, definitely check out our very special V 21 developer event. We did a really wild thing with an animated movie that we think you really love.~ Paul: Why is now the better time to hop into Angular? Because ~you know, ~we've had miko on the podcast before. We've talked about,~ um,~ oh ~well ~now is the time when we're completely changing the way you do data fetching. I remember when V 20 came out. So why is V 21? Is it something about the way Angular is positioning itself for the future of applications? Is it. [00:01:00] Fixing, if you wanna call it that. Some things, some pain points. Is it a hodgepodge of everything? Mark: Love this question. So think about it from a different perspective. We have been focusing on building this tool in such a way that we allow developers to build whatever they want, right? So if you wanna build a small application, we have our tooling that helps you to just start generate application. And then we have been building ~feature after ~feature after feature over the last few years to make it where. For, so we already had the small end covered, but what about the scalable application? We really want to make sure ~that ~that developer experience was solid. And we think that right now, like there, there's always, every time we release something that is the best time to switch because we have something new for you to try. And in this case, we've released quite a few new things that meet developers where they are right now for modern development workflows. And we're really excited about some of those features. Paul: Meeting me where I am in a modern development workflow, what does that mean for me, mark? So is it about how I work with tools? Is it ~um, ~me as an individual making MVPs or is it [00:02:00] me working in a bigger organization? Because sometimes you. We will find angular in those bigger organizations that have really serious apps,~ um,~ that, that need to give a certain guarantee. So what does that mean? Meeting me as a developer where I'm at? Mark: Sure. Yes. So everything you say, and what I mean by that is, so think about the aspiration for any developer like there is, well, there is, but when it comes to like startups or people who are building applications with success on their minds, right? Everyone wants to scale. So everyone wants to be a large application at some point where they're servicing, ~you know, their act,~ their monthly active user count is in the hundreds of thousands, right? That's what everybody's dream for the most part. Of course, there are some people who say, oh, ~well ~I've only made this application for me and my friends to like, do you know our fantasy football league? Okay, fine then. Right? So for those people find,~ right,~ this may not apply to 'em, but in general, everyone wants a scalable, large application. 'cause that means success, and that means revenue. That means a lot of things for their business. So when we say meeting you, where you are as a developer right now, think about how people are [00:03:00] working. ~Uh, ~when I started this industry, oh my gosh, I'm gonna date myself a little bit. 20 years ago, I started working 20 years ago as a software engineer. The tooling was the browser ~and, ~and the FTP server. Right now, 20 years later, tooling is not only your IDE, not only your like,~ uh,~ tooling to deploy your application ~to ~to infrastructure, but now it's also ai, for example. That's a really critical part of the modern developer workflow. People are using AI in all sorts of ways, and us or we, on the dev, on the Angular,~ uh,~ engineering team, we are trying to figure out what, how do we position the Angular to be successful in this modern world? So ~we ~we're releasing things like the Angular MCP server, the Angular AI tutor. We have the angular extension for Gemini cli, right? So we are doing all of these small things that are that, that we hope to have a big impact. But they are meeting developers right now where developers need good tooling. They need AI powered tooling, and they need a framework that scales. And we think that we meet those [00:04:00] criteria. Paul: Gotcha. Okay. I think I'm getting what you're picking up, what you're putting down. So I could use a variety of different AI tools. I could have a variety of different places where I want to insert myself,~ uh,~ into the app and with these tools, I could do it here. I could do it there. It's neither here nor there. ~Uh, ~it's where I'm at. ~Uh, ~so when we're talking about MCP servers, when we're talking about plugins, especially with AI tool, and that's a popular. Topic these days. ~Um, ~there, there's this fellow that I saw ~on a, ~on a YouTube video talking really succinctly, and I like the way he ~kind of ~framed what is value in that day and in today's day and age of tooling and the value is your context and memory management layer that you can insert into these tools. It's how you. Cut through the cruft and re really allow people to get the answers and information they need without mess, without having clean slate every time. That intelligence, that context, that memory layer, that's the secret sauce that really pushes a product into something that sticks or not sticks as whether it be tooling, whether it be an app, whether it be ui. So I'm curious how you guys are approaching [00:05:00] that. Is it purely out of, ~uh. ~MCP and just saying, Hey guys, you can go like query all this documentation. Are you putting forth opinionated workflows on how we test,~ uh,~ changes in how we test? How exactly does that translate into a way that doesn't make me scared of, oh my gosh, there's more tools and now there's like more context I need to manage? 'cause that's really where the intelligence is. So I'm curious how the team's been thinking about that. Mark: Excellent question. Love this one. So here's what we've been thinking about and doing in terms of how we managing that first thing on Angular dev slash ai. We launched a bunch of. Context files that you can include,~ uh,~ in your development workflow. So whether it be for cursor, whether it be for fire based studio, whether it be for places like Antigravity, like wherever you want, wherever you're working, we provide those context files that will give you the, that will give the LLM the context for how to build like modern applications. And then with some. Notes on how it, you know, what features to use, how to do things, [00:06:00] some best practices. Now here's the interesting thing, at least what I think about how those best practices work, is that those best practices were not just us. Guessing those are actually aren't guesses. Those are vetted through a tool that we also released recently called the Web Cogen Score, which was an evals tool that we made in open source. And it's not only for Angular,~ uh,~ you could use it for any framework. Well, I'll say you can configure it for mostly any framework. ~We, ~we don't know what the full scope is, right? But like we've seen it configured for solid, for example, the solid team tried it out and they configured it, and what it allows you to do is to measure. The quality of your like context file, right? Your best practices file. And then you can get, you could track regressions for example, if you release a new version of your framework and then you start to see that, ~you know, ~when you generate these 200 applications to run the eval system, you can say, whoa, something went weird. Let me check this context file that I have. ~Right? ~And then, so that's how we're thinking about it. So this is evidence based versus like. Here's just us taking, you know, our, 'cause you remember what people were doing, and this [00:07:00] doesn't feel like that long ago, but it was only like six months ago where we were doing LLMs txt. Everyone was doing this and they were taking their entire documentation and trying to distill it down into a bunch of bullet points and feeding that ~as, ~as your context for your context window, right? That was only six months ago. That shows you how fast this entire industry is moving. So in the last six months, we like really changed the way we work. So we saw that that was like one way to work, but we thought we could do better and this is how we, we thought we could do better. Paul: ~that, I mean, ~the framework of. Detecting ~regressing~ regressions and putting them back into your context is huge. ~Like ~that is a game changing workflow. Me personally, that I had to put ~hours and ~hours and hours and hours of work into for one project and I was like, okay, for this project, here's how, you know, if like something's good, something's bad, and once you get it going, it's great. ~It's, ~it's, you can ~kind of ~get more hands off about some of ~the, ~the dirty things you don't want to think about, but. I don't wanna do that for every project. And so ~this, ~this set of tools, they help me keep that opinionated stateful store. What's working, what's not working, the testing of~ my, uh, con, ~my memory [00:08:00] and my project context over time. ~It's, ~it's a framework to help me as a developer tune that stay up to date. Okay. Very cool. Mark: And ~you know, ~these are early versions of it, so we're hoping to improve it over time to give you even more flexibility and functionality in it. But you could do it for React, you could do it for Felt, you could do it for Angular. Like you, you could try ~the web gen,~ the web code, gen score. It's open source. Like this is something that we just saw a need for and we just made it. Paul: All right. Well now moving on to like some ways that I might use that in angular. Some new features, some new bells and whistles that we might want to touch on. Tell me about signal forms. I don't know what a signal form is. I know what a signal is and I know what a form is. Mark, what is a signal form? Why is it big news? Mark: Sure. Excellent question. Excellent question. So for our friends at home, if you're thinking about Signal, so you said you have a React heavy audience, so if this were like a solid,~ uh,~ JS audience, they'd be like, oh yeah, signals, we know all about this. ~Well, ~for people at home, a signal is just a,~ a, a a variable. ~A data point that can notify interested parties whenever that data changes, right? So that's what the idea of a signal is. Now, [00:09:00] think about taking a signal. Having your data model as a signal. So you have your form and you say, okay, I'm gonna model my form as a signal. And then you can combine that with,~ uh,~ what you do currently with forms. So the reason this is a big deal is because now we're allowing developers to bring their own data model to like the form system. ~Uh, ~and angular form data in general is annoying for most. Frameworks, it doesn't really matter what you work in form data ~is, is ~is like a hassle to work with because how do you keep things in sync? What if you change the data model? ~Right? ~But then the form doesn't represent those changes yet. You gotta like bind manually. You gotta do all this reconciliation with signal forms because it's reactive and it's based on signals. You literally can say, okay, ~well ~look, if this data model changes, because it's bound to our form, it's reactive. I don't have to do any manual re reconciliation. No manual reconciliation. That is just the nature of signals being reactive and updating the form model because it's the same. So the signal form, when you bind it to the certain signal model, when you bind it to a [00:10:00] form. That locks you in. And then you have all these really nice functionality that you can do, like custom, you can do like validation. Really straightforward, do custom validation. ~I mean, ~you can do custom form controls and we've tried to make this as ergonomic as possible for developers by removing a lot of the pain points from our previous. Iterations on form data. So this one is a big deal because ~we ~we're really excited about how we can remove the pain that developers were facing in trying to solve this problem previously. ~Mm-hmm.~ Paul: Yeah, for forms are a debacle. 'cause every framework does it a little bit differently. And then we've gone through this transfer transformative last ~like ~five years of, do you do it all on the client side? Do you do it on the server side? ~Uh, ~how does signal forms help sort that out? What is client side validation, server side validation, and how does that tie into the binding of the model Mark: Excellent question. So signal forms work on the client side now, but because it's just a signal, you could pass that signal to your server. As your normal data and do, and you should always do [00:11:00] both, right? You should, because validation is just a fence, right? You try to build a high enough fence to keep your data with integrity, so on the client side you have validators that you can implement and then ~you could, ~you could do the same thing on your service side. ~Mm-hmm.~ Paul: So it's client side by default for free. Then if you wanna take the signal server side and do extra stuff and build a higher fence, you just listen to the signal, pick it up, and then you can write whatever you might need,~ uh,~ for that server side. Awesome. Okay. Mark: What you would normally do, you continue that story a hundred percent. Paul: Now, moving forward, do you guys see signal forms as the defacto, singular way to do forms? Would you recommend people start migrating forms ~in, ~in attempt to have that coupling typed and, and, and, and strongly? ~Uh, ~held together so that it can be maintained or just keep things, how they are, start building signal forms as you move along. ~Uh, ~what does that migration look like for teams? Mark: Right now we are in experimental mode, so we are asking, we're asking developers to try out the signal forms [00:12:00] APIs, but. We also are saying like, Hey, ideally once we've matured this,~ uh,~ solution enough, we want this to be the default that you use for your form data because it takes the best parts of our, we had something called template driven forms, which is like a very low barrier to entry form system, but it was really based on like binding through the template. And then the data model you just, you know, was a little bit looser. But then we had something called reactive forms, which were, ~uh, ~strongly typed. But there was much more complex. ~Right, and, and that's the thing that we've always kind of, I won't say, how can I ~say this? We've always ~kind of ~had to work around some of the complexities of angular. Like we've been working them really hard to make it less complex in some areas. And this is another step in that direction where our reactive forms are strongly typed. You could do a lot, but it was kinda hard to do. And we just still think ~like, ~okay, you know what? This just, there just has to be a better way and this is a better way we think. Paul: Do you think signals are gonna be a theme of the Angular team moving forward in terms of reshaping some features, adding to that ergonomics as a fundamental primitive? Mark: A hundred percent. I think that we've [00:13:00] already started to do that where we've replaced things like, so in React, there's like props that ~you, ~you can send down. So like our version of props we call inputs, like our inputs are signals. ~you know, ~so that's like a good example of how we are taking signals and putting them in all the places that make sense for signals to be and to reduce like toil for developers ~and ~and reduce friction and pain. So we are doing that wherever it makes sense, but not forcing it to places where it doesn't make sense. So like, that's a really important distinction to make. Paul: ~Where, ~where's the spot? It doesn't make sense. Sometimes the negation of painting a picture is the most important. Mark: Yeah. Lemme think about that. What's a good place where it doesn't make sense? You know what? Any, okay, here's a good place that doesn't make sense. Anytime you have an unpredictable stream of events, it doesn't really make sense for that to be a signal because signals don't have ~a ~a concept of time. So that should be an observable because you don't know if or when something's gonna happen. So that should actually be like an observable, like Rx Yeah. Style, like observable. So ~you really, ~you really wouldn't want that to be a signal. [00:14:00] However, ~you know, ~we do feel like ~you're, ~you're a state, for example. ~Well. ~You have a lot of control over your state and then if your state changes, you want to update it everywhere. ~I mean like ~React is like really,~ uh,~ great about this, right? ~You know, ~when you update your state, ~you know, ~you say, okay, set state, and then ~every, ~every, everything updates, right? ~Um, ~and so that makes a lot of sense from a design pattern point of view of your state modeling. And so we think like signals make a lot of sense. So you update the signal. Any parts of your application that are dependent on that signal should be notified that there have been changes. Versus the, ~you know, ~the pattern of you having to say,~ well,~ did something change if something changed? Let me make updates in my application. ~Well, ~that,~ that's,~ that's a little bit more, you know, challenging. Paul: ~The, the, ~the comparison to the observable really sealed the deal for me. ~That was, ~that was a good one. ~I, ~I appreciate that. ~Um. ~Moving on to like UX stuff though. We, I, at the beginning of the podcast I ~kind of ~told you like, Hey, this might change how you, like, work with you or your UX team. ~I mean, ~everybody's changing how they're working with every team in 2025. 'cause our tooling's changed, like you pointed out, mark, like so drastically. ~Um, ~but here we're talking about [00:15:00] angular specific ways that you could enable faster collaboration,~ uh, in, ~in your team. So things like angular material, what's going on with angular material,~ uh,~ what's going on with. Aria,~ uh,~ angular aria. How does that change how we design components? Does it change how we design components and inversion our UX on top of the APIs, on top of forms,~ and,~ and build out those experiences? Mark: Yeah, let's talk about it. So ~this is, ~this is great. I actually love angular artery. So let's talk about what Angular material was. There's the material design spec that we adapted for Angular, and we gave you a set of components that have some functionality in them. Then you can put those components in your application and then you don't have to build things out like tabs, some fancier dropdowns, things like that. And all that was great. ~Like ~all that was great except for what we found from developers is that it was a little bit challenging to apply your design system if you did not want the angular material. Look, how do I apply my design system if I don't want the angular material look so angular [00:16:00] aria. Is a step in a different direction where angular material came with styles, angular ships with no styles. We call these headless components. So when you render it to the screen, sure you'll see a component, but it's an un styled component. It doesn't really match the theme of anything. It doesn't have our opinions on it. It is very basic. So think about it being like almost like a wire frame version of a component, but. Not that bare bones,~ but,~ but pretty close, right? And then we give you the ability to bring your exact styles to it, your exact design system. And then you can style these components. They can look however you want because we're not bringing styles. You bring the styles. But here's what we do bring, we bring accessibility patterns with angular aria in these headless components.~ these headless~ So accessibility has to be at the top of your application design needs because the application needs to work for everybody. People use the internet in very different ways. It has to be able to work for everybody. So we're saying here are [00:17:00] 13 popular, or I won't say popular. Let's say common design patterns, accessibility design patterns. We have some components that encompass that, and they're all angular already components, meaning you can use these components like a toolbar, for example. You can take the toolbar. You can say, okay, I can use the basic one. It looks fine, but it doesn't really have any style to it, but it looks fine. Or you could apply your own theme or you could do, like we did on Angular dev, we applied a retro theme to a bunch of the components just to show how it's possible for you to create the styles for this thing. ~I mean like, ~like ~this is, ~this is really, really fun for developers to be able to be creative now and then they still get the power of the angular aria accessibility layer, but now they get the flexibility of their own designs. Paul: Got it. So this is like a ton of boilerplate I would have to write. Otherwise, if I was reaching for like a shad CN set of components and I put them on my app, things like accessibility,~ uh,~ how they bleed together and make sure that we have clean state [00:18:00] interactions,~ um, ~you would all have to think about from the ground up. So if I can pull from this wire frame, it's almost like a ghost component. I can think about it. If I'm picking up and then you put on your own skeleton, your own phenotype, and ~how, ~how does that get assembled? How does that get versioned? ~Um, ~does it change like having a UX team, having component library that they version ~or, ~or storybook or something like that? Mark: You could do whatever you want there. I think ~the, ~the way that we've seen it in early days is that developers, ~you know, ~if they get their design system and they design for those components, ~you know, you, ~you, you do your styles once. You don't have to keep redoing them, right? You do your styles once for the components, and then people can just start pulling them into the application, right? ~Like, ~like that's ~the, ~the workflow that we're imagining for people. And then if you do storybook, for example,~ um,~ I'm not as familiar with storybook. I mean like using it, I know what it is. ~Um, ~I haven't really used it, but I can imagine you. Having storybook for your components and then your design system applied there, and then you could see these angular, ~you know, ~like the angular or components or whatever components you build on top of this, right? Like you use it as a [00:19:00] building block to combine a bunch of things together to make something like you get to do what you wanna do, right? Paul: Do you guys think that components should exist at this level, which is like we have. The skeleton. We have your accessibility thing ~sort of ~primed and now you guys can work with the UX team. Is that the way components should be done? Because still today, mark,~ they're,~ they're pretty primitive. ~I mean, ~you can go, just grab code for a button, bring it into my app. I could go reach out to one of the hundreds of UI libraries and just bring it on in. But this is a more like tiered system ~sort of, um, ~it's ~kind of ~a shift in how we think about doing UX and. You guys are kind of have an opinion about that here. So ~it's, it's, ~it's interesting. ~Um, ~I'm curious how this might affect like teams and workflows and size of teams, if that at all. If you guys have put any premeditation behind Mark: Sure. So think about where we're pulling our ideas from and our motivation. So we are listening a lot to the Angular community and what the needs of the Angular community are. A lot of those niche are around this idea that developers needed a way to [00:20:00] have accessible,~ uh,~ components that they could style, ~you know, ~based on, on their systems at work. So if you, if you look at something like a Sha CN or a Bootstrap or any of these other great component systems, they have a look to them, which is fine, but what happens when you want something different? I don't know what that answer is, right? But you have to do some work. We want something different. And what we're saying is that ~like, ~okay, so for the teams, if you wanna use, like you could technically style the angular are your components like Shay, and if you wanted to, because we don't bring any styles ~you see.~ So if you like the Shay and look, then yeah, sure. Find that style sheet and apply it to the components. Like, see this, this is where ~like ~the ai, ~you know, ~like workflows can really change the way people work because I could imagine a world where we give you the sample style sheet, ~you know, ~like what are the definitions that you need to style this component, right? And in full. And then you could give that to ~uh, ~like to Gemini and then you can say, Gemini, here's the styles that I actually want. [00:21:00] Can you give me a version of this and get pretty far? Bet. Like I,~ like,~ I bet we can get pretty far and say, oh yeah, now the REO components look like STAs seeing, and I use Gemini to get me a lot of the way there. ~Right? So like the work ~the way we we're, we're offloading some of the work. ~You know, ~I think there's just benefits developers in a lot of ways because now if you use like,~ uh,~ AI tooling to help you, some of the pain points of building those style. They kind of go away because some of the work is just building the style sheet itself, right? Paul: Yeah, Mark: like that's a lot of that work. And I can imagine designers being like, okay, look, I already know what colors I want. I know what my primary colors are, secondary colors, what are my extra color, you know, uh, the third color. And then say, okay, now convert this, and then I'll take it from there, right? And I'll fine tune it to get it to where I want. ~Right? ~So there's just a lot of possibility. Paul: What about testing? ~If I have my,~ and we can think about this from a UX perspective. ~Uh, ~people have their ways that they might go about end-to-end testing and making sure that styles are transpiring correctly. Make sure that things are being bubbled up as they would plan. ~Um, ~we're [00:22:00] talking about changing the fundamental way that we might run tests and write tests with Angular right now. ~Um, ~as far as I understand it, and we're talking about V test, ~uh.~ Mark: V test. That's Paul: Yeah. ~Um, ~how does this, and we can start from the UX perspective, does this bleed into the way that these tests might be handled, written, run, maintained, and follow up? Of course. Just talking more broadly about V test and what this means,~ uh,~ developing with angular. Mark: ~Sure, ~sure, sure. So ~if, ~if you're doing end-to-end testing. And you're testing in a browser, you can totally test your components, you can test your interactions, right? And then ~you could, ~you could also check our test that we wrote for these components, ~you know, ~to see and make sure that these things are working. So you could,~ uh,~ look, 'cause everything from angles to open source so you can have a look and see how we tested the components. But if you wanna add, test your additional interactions, you can totally do that. And v test is a really interesting part of our story now ~because develop, so~ ~we had, um. Once~ at one point we had an in-house solution that we made at Google,~ uh,~ karma that we made at Google, and then we like donated, I believe, I think I don't quote me on that one. [00:23:00] I think we donated it publicly. And then,~ uh,~ we started working with other,~ like,~ testing solutions and then we decided to think ~like, ~okay, again, remember I talked about meeting developers where they are. A lot of developers use V test. That is just the way it is. Paul: It's true. Mark: there. They like the solution, and we don't want Angular to be an outlier in that space. If developers are really,~ uh,~ being productive ~and ~and shipping meaningful applications, we wanna make sure that we are a part of that. That regular story where people can feel like, oh, angular is not weird about this. I can use v test here as well. I can bring my skills that I learned from another framework with testing, with V test, I can bring it over to Angular. So v test is ~a, ~a really great new addition to the story. Paul: Was this a long time coming in the ways that you guys were chipping away at making sure everything would fit nicely with V test or was this a big V 21 scope that the team worked Mark: No,~ this,~ this was a thing that we had talked about and we had been ~kind of, uh, ~thing about it. We have been doing it as experimental for quite a while. For at least a [00:24:00] year. At least a year. It was experimental support, but the thing that was holding us back is that we don't like to leave developers behind. And what I mean by that is if you look at the Angular story over time, it always includes this idea of. Bringing developers with us. So there's either some type of thing, like a schematic, which is just like a,~ um,~ a modernized or update like tooling that we have. ~We'll, ~we'll usually release the schematic to help you say, so if we change syntax, we'll release a schematic that will help you to use the new syntax so that way you're not left behind. ~Right. We, ~we try not ~to, ~to ship breaking changes. For example, with Angel, we really try to ship it where it's ~like, ~okay, ~you know, ~we want everyone to still be successful, so let's see what we can do here. With V test, the one thing that was holding us back was the browser mode, right? Like browser mode only got, I think, stabilized recently for V test and once they finally stabilized and productionized their browser mode, that gave us a way to do it. 'cause we couldn't say, ~well ~go to V test for all your unit tests, right? And integration test, but don't do your end-to-end testing in a browser ~or, ~or [00:25:00] don't do real testing in a browser. ~Right? Like, ~like that's not a complete solution for people. So once we got that solution, then we were like, okay, we're able to do it. Paul: ~I, ~I was gonna ask ~like, ~what was one of the main motivators to. Push towards V test. But ~it, ~it is the common theme I'm picking up here, which is you guys on the team are really centering around what do developers tell us today? And then you plan based on that to meet developers. ~Um, ~something like V test, right? ~You, you, ~you didn't even roll it in yet because it wasn't ready. It wasn't ready. ~Um, ~I Mark: meet the needs of our developers specifically. Paul: of your developers Yeah. In interesting specification there of your developers because everything moves quickly. This industry ~and we, ~and we talked about that. It's just interesting to note because people are certainly feeling fatigued, ~uh,~ of tooling changes, getting rugged by things that should be there and not there anymore in a framework that is their day-to-day job. ~Um, ~sounds like you guys are very callous to doing that. Really like centering around what are people asking for and sticking with something that's maintainable. ~Um, ~I guess that is your motivator. Move [00:26:00] to towards v test. It is where developers are. You wanna bring it to developers and you did it now because now is the right time when it's stable enough and it's complete enough to do so,~ so,~ Mark: That's right. ~And, ~and again, this isn't me saying that like V test was not complete. I'm saying the way our developers expect it to be able to, ~like ~if you're gonna migrate developers off of a solution into a new solution, it should have parody. The way that developers were working because then that's how you get a lot of developer like,~ um,~ unhappiness, which makes sense. I would be unhappy. You would be unhappy if you got forced into a new solution that didn't work the way you needed to work for the way, or based on the way you expected it to work. ~Right. ~So that's what I mean by that. So ~like ~that isn't let me saying ~like, ~oh, ~you know, ~our develop are so sophisticated they couldn't use V test. We're saying we didn't have the browser mode, ~uh, ~support that we needed. To make it ~our, ~our solution and because that's what our developers needed was the browser mode. And then once it was stable in production, then we said, okay, ~you know, ~that was the last part of the story. Paul: ~Do you guys,~ Mark: ~give the people trying it.~ Paul: ~um, on, ~on the team, ~sort of, ~do you feel like there, [00:27:00] there's always this element and excuse my obtuse, obtuse language here. There's an element of, ~you know, ~when we do the Angular podcast and the React podcasts,~ uh,~ centered or this felt ones, you could throw them in,~ um,~ on React. It's like, oh my gosh. So what happened last week? ~Like tell, you know, ~and then there's this element of angular ~and, ~and ~you know, ~we, when we've had me go on ~and, and, ~and folks, they say,~ well,~ people come to us and they go, react already has this ~reactor, you know,~ or like, next JS does this. ~Why, ~why does an Angular do this for me now? ~Uh, ~do you find that there's some friction coming from the external communities who you wouldn't into like our developers immediately of like inbounds of ~like, ~oh, okay, but does Angular do this? And you're like, listen guys. If we're not doing the shoot at the hip, ~sort of like ~everything changes every week ~and, ~and you are ~kind of ~playing defense on that in order to retain this ~like, you know, ~change set that is palpable, that is okay for developers that doesn't create this like parting friction ~that could, ~that could end up having people drop off. Is that Mark: Yeah, so Paul: I need to manage? Yeah. Mark: this is hard in general for any framework maintainer for the re maintainers of React maintainers of self. The maintainers are [00:28:00] solid, like everyone has the same problems, which is like how do you ship the right features for the people, right? ~Like ~that's what that's really hard to figure out. And we are doing the best that we can to decide, okay, what's important and what's not important, and we hope that we get it right. Sometimes we don't. Sometimes we don't get it right. Sometimes there are things that we're like, oh, you know what? We should actually have done this sooner. You know what I mean? And then some things we're like, oh, ~you know, ~we did it at the right time. You know what I mean? And so it's just a balance that we're trying to strike. And we are very human at Google. That's one thing I like to remind people. We are not,~ uh,~ genius robots who never make mistakes. Obviously we're very human and so we are doing the best that we can to ship the features that developers, that empower developers. ~Right? ~And if, and you know, everything is great. That's the other thing to think about, Paul, is that everything is great. ~Like. ~So salt is great, solid is great, react is great, angular is great. View is great. [00:29:00] You could probably take all those tools and get out there and build like a wonderful application. There's no doubting that like, like we're past that time in the like framework, timeline, ~you know what I mean?~ Where it's like, well, I got, I can only use, ~you know, ~angular because Angular is the only one that can do this, or I can only use React 'cause bras the only one can do that. We're past that time. All the feature sets are pretty common. Everyone, we all talk and share ideas. ~You know, ~we are inspired by one another. ~You know, ~there are cool things that Angular does. What the real thing is, what can you do to make the story the best for your developers? That's what the real focus is. So what can React do to make React the best for React? Develop? How do we keep React developers happy? Same thing with Angular. It's like, how do we keep angular developers happy? People may choose Angular or not,~ and,~ and like we just passed that time of,~ well, we, ~we have to get every developer, like if people see a value proposition in our way that we've decided to solve problems, then welcome to the party. ~You know, ~we have a lot of cool stuff, but everybody has a lot of [00:30:00] cool stuff, so you just have to decide. You can't really make a wrong choice these days, and the choice then comes, does the tooling and the experience fit the way that you work and what you need, Paul: ~Right, and and~ Mark: ~that point of view,~ Paul: that's why I love asking about like the Aria components. 'cause it does ~kind of ~paint this niche picture of one aspect of the multiple things that are coming in V 21, which is. This might change how you do UX work completely. It might change how you think about modeling. It might think change how you work with your UX team. ~Um, ~and does that work for you? ~Uh, ~hearing that experience or hearing how you guys change that really makes me think about my experience if I were to use that. So it's, that's interesting to hear,~ uh,~ to hear you too as well. Say, mark, that we got great toys everywhere. It's about matching the style of the work of how. Your team might be designing it, how the React team might be designing it to my team ~to, ~to how we're building the product at hand. And that makes more sense of why you said our developers,~ uh,~ as that clarification earlier, right? You're trying to be very intentional. Very intentional. Mark: ~Well, ~because if you're trying to bill ~for, ~for the win, so to speak. We're trying to build for the win. ~You know, ~like I'm trying to build a [00:31:00] framework that's gonna ~like ~defeat all of the frameworks. ~Like, ~that's just not where we are anymore. You know what I mean? ~Like, ~we, as an industry, we're just not there anymore. Like ~the, the, ~the real battles are happening at a different layer now, and the framework is becoming, ~you know, ~like just ~a, ~a different focus. It's become a different focus because think about vibe coding. Think about ~how, ~how, four years ago, three years ago. You couldn't describe an application and make it come to life, right? Or if you use like a wizzywig editor, you could ~like ~use a Shopify thing, for example, to ~like ~make ~a ~a website. But the logic was whatever logic it was created, ~you know what I mean? ~And whatever plugins you can get. Now you can describe to a large language model almost any application that you want. You know what I mean? ~Like, ~and then there are people out there who are building now who don't even care about what code, what the code looks like. They've never even seen the code, ~you know? ~So it's ~like. ~ Paul: wild. Mark: So it's a different world. So now how do you fit in that world as a framework? And that's what we're really interested in. It's ~like, ~okay, ~well ~then how do you fit? That's why I said the whole AI tooling thing is really [00:32:00] important. How do you fit into the world where people write applications differently and ~we're, ~we're taking, ~you know, ~what I like to call, like a very advanced step forward versus ~like ~letting anything happen to us. We are charting a course. Okay, ~well ~we think developers need MCP servers. We also think that they need, ~you know, ~context files. We also think that they need things like,~ like,~ like we have our AI tutor, which is really rad that one of our,~ uh,~ engineers made,~ uh,~ my colleague Devin, he made a tutor,~ uh,~ that you could ~like ~ask it about your, your code base and it can teach you how to work in your code base with Angular. ~Like ~that is just Paul: That's huge and that's huge. Huge for ~like ~if you're starting a new project or you're bringing on people that have never used Angular,~ like,~ look at my project, learn how to use my project. It's really powerful as a lead to be able to give somebody that tool and just tell 'em to like, Hey, ask me questions after you use the tool. Dive in. Be curious, ~you know.~ Mark: That's right. And if you don't know Angular, that's fine because it's gonna teach you angular. But ~you see, ~it's like ~you could, ~you could link it to your project, it could read the context of your project, and then so you can develop lessons on how to do, I mean, [00:33:00] there's just a lot of things that we're trying to think about, like the Gemini CLI extension that I recently,~ uh,~ made,~ uh,~ I was the lead on that one and we, we recently released it ~like people are work.~ ~Okay. ~I never thought that people would want to work with an LLM from the command line. Never thought that that was a thing. ~Um, ~and I was completely wrong. Right now, Gemini, CLI is out there. Cloud code is out there. Like all these tools that are command line based tools that you work with, LLMs. But now we notice that the, there's a shift in the way developers are behaving. And so we released the angular extension for Gemini, CLI. So now you can get the Angular CLI, oh, sorry, the Angular extension in your CLI environment. And now the CLI knows even more how to work with Angular. ~You see? ~So like, these are all like ~the, ~the type of things that we're thinking about with ~like ~being, ~you know, ~really AI first and AI forward ~at an, you know, ~with Angular. Paul: ~Now. Running up on time here, mark. So I have, and there's more things we could talk about. I, I have a whole like, laundry list here on my, on my side monitor of, of like things we could go over. So guys, there's more to check out~ where should people's look if they wanna read blog posts, if they wanna ~like ~see an interesting tutorial. Do you guys have talks or anything on YouTube? ~Um, ~and before you answer that, I would love to close out with something that we didn't talk about Mark, that excites [00:34:00] you. They feel like the team really killed ~on, ~on a feature. ~Um, did an, ~did an amazing job. So that people could go like Google ~and, ~and sink into it since we didn't get,~ uh,~ the time and space to really dig into it here. Mark: Sure. ~Uh, ~defer syntax,~ uh,~ is a special feature. It is template level lazy loading, not at the router level. ~I mean, ~parts of your template you can request from the server. And it's like super simple syntax, but really advanced like functionality. And ~you could define, ~you could define all these guards and triggers to be like, oh, if this comes to the viewport re request this part of our template. Of the template. Not of like, you see what I'm saying? Like. Paul: Of the whole layout? Yeah. Of Mark: Just ~like.~ this little part you can request. And then we have incremental hydration, which is built on top of that, which you can hydrate parts application, but not the full screen. ~I mean, ~we have a lot of really cool like optimizations there. Check that stuff out. If people wanna find out more about Angular, go to angular.dev. ~Uh, ~definitely go to the Angular YouTube channel and watch that mini movie that we put out. ~Uh, ~it is unlike any other developer release video you've ever seen. We put a lot of,~ uh,~ heart into it. It's a lot of fun and it's,~ uh,~ a big [00:35:00] throwback for us who grew up playing,~ uh,~ games in the nineties. ~Uh, ~it's just a really, really, really fun thing. And you can always search from Mark Texan, T-E-C-H-S-O-N, on the internet. You'll find everything about me in Angular,~ uh,~ with when you search that. Paul: You're the angular man. Search up Mark Texan and we will link the video,~ uh,~ in the show notes. So if anybody's listening and you're like, where do I get this video? ~We, ~we will have it down below. You can click it. We'll bring you right there. ~Uh, ~mark, it's been a pleasure. You've been an amazing guest. ~It's, ~it's been great to learn about Angular V 21. These sound like huge features,~ uh,~ big changes that are gonna really enable like ~the, ~the 20, 26 years of angular apps coming out. So thanks for your time again and ~uh, ~humoring us. Mark: Alright, thanks for having me.