A (3:05)

So I started my career in video production. I worked as a producer working. My whole goal was to like eventually make my way out into like kind of the Hollywood space, but not in full front of the camera. I wanted to be behind the camera and doing editing and special effects, that kind of stuff that interested me significantly. So I got a communication degree in college with the goal of hopefully getting out in that direction. Got my first job as a producer and it was the most boring job ever, at least in the areas that I was working in. I was doing like the jobs that are far less glamorous. I was writing for our real estate support services company. So back then they would do television home advertisement programs that were like 30 minutes long. And if you woke up on a Sunday morning and you turned on your local television, you might see a 30 minute program of someone reading about homes for sale in your area. I wrote those and for several years, day in, day out, I looked at MLS listings and translated a sheet of paper into a script to time. And I essentially was so bored in that job that I started writing software to do it for me. And the company I worked for, like had both a software side and a video side. And they offered me like time to do that and space on their server to do that. And by the time I left that job, I had written software that would automate, like taking in MLS listings and generating a script to time and spitting it out into a format needed. So it was at that point I was like, I should probably do this job instead of doing the producing job. So I pivoted my career at that point. So that's essentially my roundabout way of getting into actually engineering and, and tech.

B (5:07)

That's such a common way to get into programming. You have a boring task that's the same thing over and over again. If only there were a way to automate it.

A (5:15)

Exactly. I've heard it said that every good engineer is a lazy engineer. Yes, because they will do exactly that. They will fully automate a task that they're too lazy to do because it's repetitive and then you have more time to code on other things.

B (5:33)

Yeah, it's like one of those, you know, cookie clicker style games where you keep doing the thing so that you can do the thing more.

A (5:40)

Yes, exactly.

B (5:42)

Where did you go after mls? Data automation.

A (5:45)

My first real engineering job was for a small agency that was located in western Wisconsin in the United States and the company no longer exists. But this was back in the time before the square spaces and whatnot of the world, where people could just use a platform that would build a website pretty easily. Back then, smaller companies would pay local agencies to do that work and I worked for one of those. So I would help a team of people build out small company business websites that had your standard contact forms and maybe a catalog or something like that. And I kind of had to demonstrate to them that I was capable because of course I didn't have the degree and I didn't have the background experience. So yeah, I started at this company kind of proving myself and then very quickly ended up as their lead engineer. So I clearly have a talent for it. I remember they gave me my first task, which they probably thought would take me a while, and I did it in like 30 minutes. And it was like what I thought to be a fairly trivial task. So they were clearly surprised with how well I was doing at the time. But this was also back in the like, ie 6, ie 7, ie 8 days and having to deal with all of that. I was writing cold fusion code.

B (7:09)

Ooh, that's a throwback.

A (7:11)

Yeah, I think it still exists, but I haven't touched it since that job.

B (7:16)

A lot of people who went into web development in the IE6 and so on days did not stay in web development because of IE6 and so on. Why do you think you've stuck in that area since then?

A (7:27)

I actually know quite well why I did. And it was because, especially on the front end side, as frustrating as dealing with IE was, there was and still is such a satisfaction to me of writing code and seeing it immediately reflected on a screen. And the satisfaction of fully building something out and being able to directly interact with it in a browser gave me a dopamine hit. And I think there was also that sense of like, haha, I beat you, Internet Explorer. Yeah, so I think that's where it comes from because I still feel that now. There's a slightly different satisfaction now, which I think comes from the green check mark of all your tests running and some of the other hobbies of mine. It's like getting something physically working and doing a thing. I think I'll probably always get a dopamine hit from that. So I think that's where it comes from and why I've stayed with it.

B (8:23)

Lovely. It occurred to me after asking the question that not everyone in web development today might even know what IE stands. So thank you for explicitly saying Internet Explorer. It's been so long. But okay, let's fast forward a little bit. So you got into web development in the fun days of Internet Explorer. Now you're at Google on the Angular team. How did that come to be?

A (8:43)

That's an unexpected story. So I never expected I would be at Google, let alone on the Angular team. Like around the time that I was doing that first engineering job, or actually the job shortly thereafter was when Google I O was first becoming a thing. And I remember being excited about Google I O in general. I would watch all of the updates on it and then I had the opportunity to go one year and I was super starstruck by just everybody there and just kind of like literally starry eyed walking around like had little stars on my. No, I'm just kidding. I didn't actually have stars on my face, but I was just like super excited and like thrilled to be a part of that experience. Especially since I had a bunch of techie friends who are always looking at like, oh, what's the news coming out of Google? Oh my God, you get to go to IO. That's so crazy. So I was super excited about it and I was like, I thought of Google as the unattainable kind of job because to me Google was always one of those places where smart people worked. And I never thought of myself as that because I didn't have that Stanford degree, you know, I didn't come out of some fancy tech university and get to go into a job like that. I'm self taught. So that was just like unattainable to me. So after going to IO, I actually got to go a few times and one year was a year where I actually saw the Angular team presentation and I remembered watching the two people present and it was just like, man, it would be so cool to work with those people, to work on something like Angular, which is I was doing an AngularJS project at the time and this was shortly after Angular 2 came out. So there was all this information about the new version of the framework and I was just kind of like, this is the coolest thing. I can't imagine what it's like working with those people. So kind of flash forward I got my first what I would call real tech job. And by that I mean like working at a tech startup, like a company that called itself a tech company. Prior to that I worked for other companies that happened to have tech areas where they were supporting their major business operation. So now I'm working for a tech startup and I get an email from Google saying like, hey, we're interested, would you like to do an interview? And I'm just like, sure, I'm going to bomb it, but sure. So I do the phone screen and I like pass it with flying colors and I'm just like, what? This isn't supposed to happen, but it turned out that at the time I had already had an offer from another smaller startup. So I accepted that role and declined the on site. But there was still interest from Google and I'd get, you know, periodic check ins and stuff. And eventually I was kind of at one of those, I call it like a shields down moment where you're like happy with your job but you're kind of a little burned out and you're open to maybe interviewing somewhere. And the timing ended up being right and I interviewed and somehow like I remember being in the interview being like, this is going well, that's not supposed to happen. And I ended up getting the job and then I joined a mentorship program within Google and I walk into the room and the person that I see happened to be one of the people that I saw on stage at Google I o and we ended up connecting and through that opportunity eventually I was able to join the Angular team. And it's still like one of these things that I'm just like, wow, these people are my colleagues now. That doesn't make any sense to me still. And I don't take it for granted because I know they would disagree with this. But I feel like I'm always the dumbest person on the team because I'm very hard on myself. But I always want to learn from them and I'm always in awe of their ability and their knowledge and I think it's a wonderful place to be because everybody on the team is so wonderful. So I think I accept my position on the Angular team with a lot of humility. I know a lot of people now associate me specifically with the Angular team because they see me on YouTube and they see me give talks and stuff. But for me I do all of those things because I know there's a person like me out there too that doesn't think that they're capable but is and maybe they'll see me and see someone like them and eventually find their way here too and might be inspired by that. So yeah, that's the long and the short of kind of the background of how I got here.

B (13:37)

Have you seen examples in the wild of people mentioning that seeing you with, you know, communications background and so on has helped them?

A (13:44)

I don't know that I have. I have seen people say like they are inspired by me and I've seen like Jessica's like my goals like as far as where I'd like to see my career go and that's always like very heartwarming for me. To hear? Yeah, I don't think I've ever had anybody tell me directly like, oh, I'm inspired by your non technical background and want to get into tech and whatnot. So maybe someday we'll see.

B (14:16)

Maybe a listener to this very podcast will hear this and write in maybe.

A (14:21)

Exactly. But.

B (14:22)

Okay, let's dive in a little bit. So you're on the Angular team. A lot of folks may know what Angular is. A lot of folks don't. Just to start off, could you give us the insider look on what actually is Angular?

A (14:33)

So Angular is a framework for building complex enterprise applications at scale, and we believe it is one of the best out there. We're the oldest big framework out there at this point and we specifically focus on the web over the whole multi platform approach that there are some frameworks out there that are trying to target our expertise is the web and we think we can do best by focusing on that. We say enterprise because typically Angular is used more on the enterprise side. But yeah, I would say that is probably the way I would describe it. Sure.

B (15:20)

I can tell you've thought deeply and carefully on your language there. And there are two parts I want to highlight. One is that you said we think rather than it is, and then you said one of the best rather than the best. Can you tell us why is that phrasing so important, of phrasing it as one of the best from your opinion, rather than we are the best?

A (15:38)

Yeah. Well, I know there's a lot of people who think about the hashtag framework wars out there, but we, and I say we, as in the Angular team in general, feels that that's a thing of the past. We actually communicate pretty regularly with other framework authors. Like we've had conversations with Solid and VUE and Svelte, just every other framework you can think of, and we have those in a positive way. Those are kind of collaborative sessions where we talk about like the pros and cons and like what we can gain from each other and how the approaches that each framework is taking. And we like to. Because historically you'll see that every framework has kind of taken bits from each of them and we don't think that there's anything wrong with that. Like, inspiration comes from other frameworks, other modalities of doing things come from those and other experiences. So we know we're not going to be the only source of the definitive way to do things. And if we just keep our head in the sand and say, like, oh, Angular is it. Angular is like our way of doing things is the only way we're going to miss out on a lot. So we like to talk to other frameworks and we don't think that we're at each other's throats for marketplace dominance. Clearly, there are popular frameworks and less popular frameworks, and there are frameworks that have certain use cases. But a lot of people at companies don't get to make the choice over which framework they use because they're working on an existing piece of technology and somebody just happened to choose, oh, we're using React, or we're using Vue, or we're using Svelte, or we're using Angular. And those choices were made at a time that maybe the strengths were in those frameworks, or maybe a person just liked that framework. So we feel that in this space, we should endeavor to make this space better for everyone, rather than trying to be like, well, we're better than X, Y or Z, so I guess maybe that's the answer. We want people to use what's comfortable for them. We hope that people will take a look at Angular and like what they see. But ultimately we hope that with our conversations across frameworks, that we are all moving the web in a better, more performant, easy to use for engineers and users alike direction. So I think that's where that comes from.

B (18:16)

That makes a lot of sense. That's a very good and forward thinking way of looking at things.

A (18:21)

We hope so. APIs are the foundation of Reliable AI. And Reliable APIs start with Postman. Trusted by 98% of the Fortune 500, Postman is the platform that helps over 40 million developers build and scale the APIs behind their most critical business workflows. With Postman, teams get centralized access to the latest LLMs and APIs, MCP support and no code workflows all in one platform. Quickly integrate critical tools and build multi step agents without writing a single line of code. Start building smarter, more reliable agents today. Visit postman.comsed to learn more.

B (18:57)

Do you have particular aspects of Angular that you would call out as being particularly great, whether or not they are duplicated in other frameworks?

A (19:05)

Yes, I think there's a few of them. The biggest one though, I think is our mentality about bringing users along with us as we move forward. A lot of other frameworks don't have a migration system, so when we release a major version or minor version and we do a breaking change, we don't just want to say, hey, your change is broken, we want to bring you along with us. So a lot of those changes, if not all of them, will have an automated migration that will either run automatically or you can opt in to run that will take your code from the previous deprecated version to the new version. I think we learned the hard way that that is a very important thing through the whole angularjs, Angular two kind of switch where was a big major breaking change that wasn't an easy thing to migrate. And obviously for those that were around at that time in this space, that was a very controversial move and cost a lot of goodwill. And so since then we've put a ton of effort into making sure we don't break people. So I think that's a big factor working in our favor. I think a lot of the things that we're doing now are somewhat industry leading in the user experience space. Especially after for a long while we were considered one of the heavy, boilerplatey, more difficult to use frameworks. Now we're doing things like our deferable views or defer blocks where we have declaratively designed a system so that you don't have to manage your dependencies and write dynamic imports yourself and manage when they're going to resolve. You get a very user friendly API for people to say like hey, I want this section of code to be lazy loaded and hey, trigger that lazy loading based on a user interaction or once your browser becomes idle. And then on top of that we've extended that to be a boundary for hydration and our incremental hydration is kind of. I think a lot of people were surprised when we shipped that because it is a hard problem to solve. So I think a lot of the things that we're doing around signals and reactivity is also an industry leading effort in partnership with some of the other frameworks like Solid for example. We've actually worked closely with Solid to design an API that works well. So I think those are standouts to me of the things that we're doing right now that are really seen as positive and having a really overall across the entire front end industry kind of trend setting.

B (21:54)

Sure, I'd like to go through those in order. Let's talk about deferables, defer and hydration. Why is that such a difficult problem? And in fact what is that problem in the first place?

A (22:04)

Okay, so when it comes to deferable stuff or lazy loaded code, one of the problems that people have in complex apps is that their initial page load or. Well yeah, we'll just go with initial page load. It can be any page in your app that could be landed on initially. When you don't lazy load stuff, you can have some really heavy components in there that will take a while and delay your initial render and delay your time to first paint user interaction have a negative impact on your core web vitals. And typically the goal is to reduce that initial bundle size. So in other frameworks there's things like the suspense boundaries, but you still have to deal with identifying your dynamic imports that you're going to have to lazy load and all that sort of stuff. So you need to kind of figure out how you can break up your code in a way that won't negatively impact the user experience, because they're seeing a loading spinner for really, like, I wouldn't say long time, but where you might have a layout shift that comes with that while also keeping that bundle size as small as possible. I think that is probably the way I would describe it. So we have solved this in Angular by being able to essentially go into your template for your component and just wrap a section of that template in a statement that's efer and that basically just says every component, every dependency inside that block of code in your template, lazy load that. No having to write out those dynamic imports. It just the framework handles it for you. So that essentially solves the like, hey, I'm a developer, I want to be able to lazy load sections of my application. Here's how I'm going to do that. And we've provided APIs there that are like, here's your loading template, here's your error template if something fails when you load, here's a placeholder that shows beforehand and which are just kind of essentials for just about every kind of suspense, like boundary. You need to have that kind of thing. And prior to this, in any framework, you would have to manually write out all of that stuff, which is a lot of boilerplate, it's a lot of extra work. And then you got to handle making that perform it yourself. So that is the problem essentially, that deferring your code is solving, is trying to get a bunch of heavy dependencies out of your main chunk for your application so users can see your website faster.

B (24:47)

I think this speaks really well to at least two things. One is this shared investment in performance and clean code and service of performance that all the frameworks are working towards. And two, I think this is a really interesting example of how the Angular templating language can be worked with and extended by Core, that it's very clean and very in line with existing Angular template directives that you have, you know, at Defer, at Loading, at Error and so on, and it just seems like a natural extension of what's already been there.

A (25:17)

Yeah, thank you. I think we agree the Angular team actually really likes Svelte syntax. And we actually initially, for our. At def Defer were planning on just using the same syntax that Svelte uses. That was actually part of our initial RFC that we put out, and it was actually due to user feedback that we ended up switching to the syntax. But yeah, I think originally the concept behind Angular templates was that it was just HTML. And the truth is it's kind of not. And I think that was realized fairly early on because, you know, if you look in the working groups, you'll see them complaining about how we were doing attributes differently and that they were like, we need to talk to the Angular team to figure out if we can get them on the standards for certain attribute syntax, because we natively have used our own attributes that are not HTML standard. But I think that trip has sailed at this point. So now we're just trying to make a natural, easy to use syntax that is very close to HTML for people.

B (26:32)

Continuing forward on that, you also mentioned signals earlier, Jessica. What are signals?

A (26:38)

These are things that you can do by putting a big light on the top of your house and shooting that into the sky, and that will signal to people that your house is there. Thank you. Great. Yeah, you're welcome. Yeah, some people actually put things on those lights too, like bat shapes and stuff like that. Oh, why is that? Yeah, just to let people know that they're Batman, which is odd. You would think that they would not want to draw people attention to that. But anyway, no. So signals is a. A new form of reactivity that I think was kind of pioneered in the pre act world. I feel like Jason was one of the first people to put. Or at least I don't know if it was Jason that created it, but the creator of Preact, by the way, I think they pioneered Signals and then Solid kind of jumped in and made their own library. And then we started taking a look at. Because Angular has. A lot of people think of Angular, they think of rxjs, because we had it very embedded in our framework and it's part of the learning journey, but it's a little heavy and can be very confusing for people to do properly. And we've known this. Part of our goal for Angular is to simplify the learning journey for Angular, to keep as many dependencies out of that initial story, so that when people are learning Angular, they don't have to think about complex things like RxJS. I know it can only bring that in when they actually need it. So we've been trying to figure out a good solution for reactivity in that regards. And Alex Rickabaugh Pavel on the team, they were looking at what we could do in this space and were also talking a lot with the Solid team and proposed this idea of us using signals. Signals are essentially a reactivity primitive where you can create a signal and you put your value in that signal. And other anytime that signal changes, you get kind of a subscribe is the wrong word because that people think of observables when they think of subscribe, but your consumers of that signal will get notified or updated. So it's very lightweight. And along with that, there's like computed signals, which are essentially a memoized signal that caches values and updates compute computations that you have set based on other signals. So it's kind of a whole graph of reactivity, but the key factor is that it is small and fast. So this was proposed to the team and we were just like, yeah, yeah, that's the right direction for us. Let's go that route. And so that's essentially what signals is. You can say new signal, put your value in the parentheses and then you, when you want to use a signal, you call it like a function and it returns the value of that signal. You can set the value by like in your typescript code, by grabbing that signal and calling set on it. That's if it's a writable signal, you can have read only signals. And there are now new other types of signals, like linked signal. That is a fancy type of computed. So hopefully that answers your question. It's a reactivity system that is lightweight, fast and responsive.

B (29:54)

That does, thank you. I've seen signals and observables and things like one or both of those for quite a while. I mean, VUE had refs and such. I remember being a big fan of MOBX back in my REACT days.

A (30:07)

Yeah, me too.

B (30:08)

That was a great library.

A (30:09)

Yes, it was.

B (30:10)

Shout out, Shout out. MOB X. Is there a particular reason you think that signals are being added to Angular now as opposed to, you know, three years ago, 10 years ago?

A (30:19)

Part of that story of trying to improve our reactivity system and to improve the learning journey as part of it. We have seen over the years feedback from a lot of people that Angular is hard to learn. And part of that is rxjs. And if you look at a lot of rxjs Code in Angular, it can get really confusing and it is hard to do right, especially for a new engineer. And we think that it is ideal to use RXJs or observables in general, because now they're going to be a standard at the right time, because that is observables for those that don't know are really great for asynchronous work and anything that needs to continuously update. So let's say you've got data streaming from a server and you need to update that as it comes in. That's a great use case for observables. There are a lot of use cases that are not ideal. Like synchronous work is definitely not the best use. Like RXJS is very heavy for that. And users coming in and looking at that code are like, what am I looking at here? What are we actually doing? So we've been seeing that feedback of Angular and we're trying to respond to it in the best way that we can. So that is where this has come from primarily. Now, what can we do to make Angular easier to work with and easier to learn? And we have found that the feedback from people who are now using signals is overwhelmingly positive. They find that components are way more lightweight, easier to just look at and understand what it's doing. So we take that as a huge sign or signal that we're doing the right thing.

B (32:08)

I love it. Your team is generating more code than ever, but you're still stuck with rigid legacy tools. Inflexible workflows, manual updates and siloed communication are slowing you down, just as your engineers juggle more pull requests and context switches than ever. That's why there's Monday.com's dev platform. With fully customizable workflows, you can ship faster. No admin bottlenecks, no clunky add ons. Let your developers work in Monday dev or right from their ide. With AI powered integrations that keep every task in context, get full visibility into.

A (32:40)

Progress, performance and risk, all in real.

B (32:43)

Time, fully synced with GitHub and your entire ecosystem. And with business connectivity built in, Monday dev keeps engineering priorities aligned with the.

A (32:51)

Impact that matters most. No more admin bottlenecks.

B (32:54)

Visit Monday.comdev to learn more. Are there any other parts of Angular that you think the team's going to invest in simplifying or streamlining?

A (33:03)

In that line, yes. And we've signaled again as such in past videos and talks and stuff, we're. We're constantly trying to look at ways that we can Improve, as you might hope a framework team is is doing. But one of the key ones we're looking at is how we can eliminate even more boilerplate that we have in our components. So I don't know if you've used Angular recently, but in the past, anytime you wanted to write a component, you have to do at component and then inside there you've got a whole bunch of flags you have to that. It's a lot of boilerplate. It's a lot you have to add. We had to like specify whether you're in standalone and you have to. You can. You have to specify where your template's located and your style URL and your imports for all of your dependencies has to go in there. And a few other things that you might need. Like if you're trying to deal with a certain type of change detection, you might specify something in the component decorator. And that's a lot to have to think about. It's a lot of extra code to look at. So we are looking at how we can reduce that. So one being like you have to import all of your dependencies twice. You have to import it at the top of your file through your standard JavaScript import, and then you have to go into your component decorator and say you're importing it. Again, that's annoying. We want to be able to remove that. So. So we're looking at ways that we can avoid having to do the dual import. We're also looking at the fact that you also have to specify what your selector will look like in that decorator. So if you are in your HTML template and you want to reference that component, you have to specify what the selector will be in your component decorator. So if you want it to be like example cmp, you have to go into the component decorator, specify that, and then you use it in the template. So we're hoping that we can eliminate the need to specify that too, but we're really only in the early phase for that essentially again trying to remove complexity for people. We're continuing down server side rendering improvements. For those that don't know, in the past there used to be something called Angular Universal that was developed by our community. We actually officialized that as part of the framework now. So you don't have to like have a third party library to do server side rendering. And we're trying to more closely tie the framework to the ability to server side render and make it as performant as we can. There's a lot of improvements there too, like Things are using vite now and trying to use modern build tools. Like I think a lot of frameworks are doing all of this, but like we have to constantly evolve ours too. So we're also looking at things like improvements to hydration, which has been a thing that I've been focused heavily on. But also on top of that, all of the things that, you know, a lot of the other frameworks are doing, like the cache invalidation strategies and whatnot for deployment, that kind of thing is being worked on. Gosh, so much.

B (36:17)

You got a big team doing a lot of stuff.

A (36:20)

We've got a lot. And we don't even have that big a team. We rely a lot on our community to help with us. So, you know, if you want to contribute, you're welcome to put up a pr. But yeah, we're very ambitious for the amount of people we have and the amount of like engineering hours we have available to us. So. But I would rather us be ambitious than not.

B (36:45)

Sure, yeah, it's a very rapidly evolving world that you framework folks are living in. I mean, there's constantly some new up and comer introducing some wacky new concept that everyone loves and you are expected to align with.

A (36:59)

Sure. Very trendy our industry.

B (37:02)

Speaking of which, there is. You can tell I'm a React developer because many of my questions come from that perspective. There's a big back and forth that's been going on for a while in React land of whether you should server side render and whether hydration is important. Some folks think that SSR is very good because as you mentioned, SEO performance. Other folks hate it because it makes single page apps harder to build. And then there's the whole delineation of what's a single page app versus a multi page app versus a PESPA versus and so on. As someone who's now working in hydration, where do you see angular or what do you see as the flaws of the forced perspectives in that whole hullabaloo?

A (37:39)

Forced perspectives. I love that term. It's a film term. All of the things about like SSR improving your SEO and initial load, perceived initial load speed are true. SSR does that, but it sure does add complexity to your application. I think a lot of people don't think about the fact that the server doesn't know about the browser's primitives. So when you're server side rendering, things like window don't exist. And that certainly adds a lot of issues when dealing with how do I write code that can be server side rendered and works on the client and I think a lot of, especially early on engineers don't even realize that. I do think not everyone needs to reach for server side rendering. I think that SSR really matters when you need it. And when I say when you need it, I mean like there will come a point where you realize that as your app gets bigger and as you have a user base that gets bigger, you will start to see the edges of where a CSR client side rendered app are and server side rendering becomes the next go to. Because you just need that little edge of performance that SSR is going to give you on that initial load. I think what we're seeing in the industry right now is a lot of experimentation on the best ways to do it. Like I think React server components are seen as both really cool and really difficult to deal with and code around. And you see a mixture of like, hey, when is Angular going to get something like React server components? Or please, no, we don't want the complexity of React server component style work. So I think all of the criticisms and praise are equally valid for all of the exact reasons that are being discussed. I think people should really think about do they need it and if they do need it, you know, one size does not fit all. So think about why am I asking for server side rendering? Is it because I think it's cool? Is it because I genuinely need the SEO benefit? Is it for cost saving reasons that I want to do pre rendering or ssr? Where is the ideal mix of all of these so that I make my dev infra team happy because we're using less processing power or I make our end users happy because the site loads faster, because we have a problem with our initial load and people are navigating away because performance is a problem? Are we trying to save our clients money by doing certain things? Because like when people think of ssr, it's actually quite a number of things. It's not just I'm rendering on the server, it's like server side rendering, pre rendering, all of the cache systems that come with that. It can be a mixture of all of those things where you've identified individual pages. You want a server side render because they need the performance, but a bunch of other pages on your site don't. So it really takes careful thought to figure out exactly what is the thing that you need.

B (40:50)

Sounds like you're doing that careful. Thought you mentioned you're working on hydration. Is there a vision or a long term goal that you're excited about working towards that you're able to share?

A (40:59)

There is a vision But I am not allowed to talk about that because that's in the Marvel Cinematic Universe.

B (41:07)

Oh, I thought he died.

A (41:08)

Is that a spoiler?

B (41:09)

He came back.

A (41:11)

I mean, I don't want to spoil it for anybody either, but I regret saying anything. Like I said, I'm not allowed to talk about it because. No, actually. So I think hydration for us was largely seen as a detriment for years because we didn't actually have it. We had what we call destructive hydration, which is a fancy term for we destroy and recreate everything. But a couple of us on the team were tasked with actually doing real hydration. And since then it's been a big focus for us to continually evolve it into a way that one is easy for people to use and has little to no issues, is more and more advanced. So into the incremental hydration part of it. And for those that don't know what that is, or partial hydration, that is being able to leave portions of your application on your pages that are server side rendered and hydrated. Some of those sections might be dehydrated so you can like get the same benefits of all that defer loading while also leaving some of the page not hydrated until someone actually needs that code. So for us, we're looking at ways we can continue to improve that experience. Maybe it's parallel fetching of resources, maybe it's something else. We've looked at things like Astro and we know there are people who want to work with Angular and Astro, and right now that's a heavy undertaking. Maybe we'll look at that in the future. I'm not sure what our super long term plan is there, but essentially we will continue to evolve and advance what we have. Maybe we'll look at something like what we call islands. For those that are unfamiliar with more advanced forms of hydration, an island would be kind of like maybe a nested React server component or something like what Astro does, but maybe still slightly different, where if you can leave bigger chunks of your application dehydrated, but inside that dehydrated content, you have an island of hydrated content that is in the middle of it. So it's that hydration within the dehydrated block would make it a little island of interactivity within your whole application. It's very challenging because Angular has hierarchical dependency injection. So our hydration system requires that parents be hydrated when we hydrate a child component because we need to know the dependencies. So whenever we have a dehydrated block that you end up hydrating if it's a child of other dehydrated content. Right now we kind of have to go all the way up the tree and hydrate back down so that everything is present. But we hope to at someday be able to support the option of, like, defining a section of your app that you want to kind of detach from that hierarchical system and be able to make a little island of interactivity. Other things we're thinking about are like, how could we make our signals, our signal graph, affect hydration?

B (44:19)

It's incredible that all the things we've talked about, hydration server rendering, imports defer, these all spin together and impact each other. It's not one direct line of area to invest in. You have to think about the whole thing.

A (44:34)

Yes, exactly. And if you look at everything's a stepping stone, right? When you're working on improvements to a system, you can't go from, you know, A to G unless you're the USS Enterprise. But you can go from A to B and then B to C. And our hydration story has been that we had to build our real hydration system in order to get to incremental hydration. We had to build. We started with hydration, then we looked at our deferable system and. Or in order to get to incremental hydration, we needed both of those. So you. Each of these are a stepping stone in our future of improving how these things work.

B (45:15)

I can't wait to see what comes up in the next few years. But we only have a few minutes left. I have just one or two last questions for you. You mentioned the USS Enterprise. First of all, what was it like meeting LeVar Burton? And how did you meet LeVar Burton?

A (45:28)

Oh, gosh. So I'm a huge Star Trek fan. I describe Star Trek as my first love. I have been a fan since early childhood, grew up with the Next Generation, which has LeVar Burton in it as Lieutenant Commander Geordi La Forge, the chief engineer. And this past year, I got to go to a convention. Star Trek convention, Yes. I am that kind of nerd. In upstate New York at Ticonderoga's. There's somebody there who's built a full replica of the USS Enterprise, the original one from the original series, that you can go and tour. And then they. They have conventions there. And so I got to go to Trikonderoga, which is the name of the con. And several Trek actors were present, including Jonathan Frakes and LeVar Burton. So I got to meet both of them. And Lavar is exactly the person you want him to be like. I know they say never meet your heroes, but LeVar truly is the Fred Rogers of our age. He is a wonderful human being and thoughtful and empathetic and caring and just listening to someone in the audience say that he is a national treasure and kind of most of us in the room, including Levar, kind of tearing up, it was just wonderful. It's wonderful. I highly recommend if you have the opportunity to meet him and Jonathan Frakes, he was wonderful, too. I would highly recommend that.

B (47:04)

I'm excited about both actors. They're both fascinating people. LeVar Burton in particular. I recently started listening to his LeVar Burton Reads podcast. Just every episode's a different short story, and it's phenomenal. He's an incredible narrator with a great, great set of books to read.

A (47:19)

He absolutely is. Absolutely.

B (47:22)

The last question I have for you is, could you explain the what and why of Angular cereal for us, please?

A (47:30)

Angular cereal. Okay. So for those that are unaware, A year ago, April 1, we released a commercial for Angular Serial. You can go on our YouTube channel and watch it. And that was my silly creation. Where it came from is a year ago for NG Conference, which is one of the bigger Angular focused events. A couple of our devrel team members were doing a talk on stage, and as a prep for that, they asked if I would produce a commercial for it because they were doing a talk that was like a newscast theme. So they wanted to be like, on stage and then cut to commercial and then show something silly. So they're just like, do whatever you want. And out of that, my brain went to Angular Serial as a concept. So I designed serial pieces and 3D printed them, and we had a box design made for it. And I shot this commercial by myself in my whole house and played multiple characters on screen and was ridiculous. I remember thinking while I was shooting this commercial, what am I doing right now? How did my. How did I get here? Since then, yeah, Angular has been a part of this complete breakfast. So I have actually, in the background of. I know this is a podcast, so nobody can actually see it, but the cereal box sits behind me as a prop, as well as the Boring O's cereal box that was also part of the shoot. So those will travel with me wherever. That's where it came from. And we decided after that that why not release it as an April Fool's video for everyone to enjoy. I don't know how many people have watched it now, but the comments on it are great. And at that NG conf, I actually handed out pieces of the 3D printed serial for people to take as a little souvenir. So it was a good time really.

B (49:30)

Pulling in your communications video production background.

A (49:33)

Oh, yes, yes, yes. I love the fact that I actually get to use those skills when I'm on this team.

B (49:38)

Much like the breakfast, you are well rounded. There's this great line, by the way. I just want to pick on this great line in it, I'm not yout Mom. And it reminded me of the Community Post season six after credits scene. It was really well done. Nice.

A (49:50)

Thank you. Thank you.

B (49:52)

Great. Well, we're already over time so Jessica, thank you so much for hopping on the show. If people want to learn more about you and or Angular, is there anywhere in particular you direct them on the Internet?

A (50:02)

Well, if they want to learn about Angular, you can head over to angular.dev, you can head over to our YouTube channel, which is the Angular YouTube channel where you will see me often doing silly bits in the release videos. And then if you want to learn more about me specifically, I'm on all of the socials. Well, I am on some of the socials these days. I'm. I'm on Bluesky. I'm on Macedon. I am hoping to be on Flashes when that comes out for Android as I'm an Android user and I do have a link tree. You can find that@JessicAjanic.com and that should get you to all of the things that I am currently on.

B (50:42)

That's great. Looking forward to doing that. For Software Engineering Daily, this has been Jessica Janek and Josh Goldberg.

A (50:47)

Cheers all. Yeah, live long and prosperity.