EPISODE 1830

[INTRODUCTION]

[0:00:00] ANNOUNCER: Modern web development faces several challenges, particularly when building scalable, maintainable, and high-performance applications. As applications grow, managing complex user interfaces and ensuring efficient data handling in modular code structures becomes increasingly difficult. 

Angular is a TypeScript-based web framework developed by Google. It's component-driven and designed for building single-page applications with a strong emphasis on modular architecture and performance optimization. Angular scalability, maintainability, and built-in features like modular architecture, TypeScript support, and robust tooling have made it popular for enterprise applications. 

Jessica Janiuk is a staff software engineer at Google where she works on Angular, which just hit version 19 late last year. In this episode, Jessica joins to show with Josh Goldberg to talk about the Angular project. 

This episode is hosted by Josh Goldberg, an independent full-time open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ESLint, the tooling that enables ESLint and prettier to run on TypeScript code. Josh is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a live code streamer on Twitch. Find Josh on Bluesky, Mastodon, Twitter, Twitch, YouTube, and .com as Joshua K. Goldberg. 

[INTERVIEW]

[0:01:39] JG: Jessica Janiuk, welcome to Software Engineering daily. 

[0:01:41] JJ: Oh, thank you for having me. 

[0:01:43] JG: Thanks for coming on. I'm excited to talk to you. You do a lot of cool stuff in and out of Angular. But just to wind things back a bit, how did you get into coding? 

[0:01:50] JJ: Oh gosh, that's a really good question. I got into coding probably back in the 90s, which is showing my age. But with my first family as PC, I started playing with QBasic, which came with Windows back then. I don't know if it still does. And learned batch commands and messed up our computer quite a few times, but discovered I had an act for it back then. That was probably the first foray I took, programming classes in high school for Pascal, but I don't remember any of it. 

And then, yeah, from then on, I've just always had a knack for tech. Coding was something I was always interested in as soon as I had access to computers. And I've just kind of played around with all sorts of tech and programming languages since then, but I didn't actually end up with a formal degree in software engineering. I kind of roundabout made my way into being an engineering for a career. 

[0:03:02] JG: What did you do before you went into engineering as a career? 

[0:03:05] JJ: I started my career in video production. I worked as a producer working - my whole goal was to eventually make my way out into kind of the Hollywood space, but not in 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. 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 the jobs that are far less glamorous. I was writing for our real estate support services companies. 

Back then, they would do television home advertisement programs that were 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 had both a software side and a video side and they offered me 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 taking in MLS listings and generating a script to time and spitting it out into a format needed. 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. That's essentially my roundabout way of getting into actually engineering and tech. 

[0:05:08] JG: 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. 

[0:05:15] JJ: Exactly. I've heard it said that every good engineer is a lazy engineer. 

[0:05:21] JG: Yes.

[0:05:22] JJ: 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. 

[0:05:35] JG: It's like one of those cookie clicker style games where you keep doing the things so that you can do the thing more. 

[0:05:41] JJ: Yes, exactly. 

[0:05:43] JG: Where did you go after MLS data automation? 

[0:05:45] JJ: 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 Squarespaces 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. 

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. Yeah, I started at this company kind of proving myself and then very quickly ended up as their lead engineer. 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. 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. 

[0:07:10] JG: Ooh, that's a throwback. 

[0:07:12] JJ: Yeah, I think it still exists, but I haven't touched it since that job. 

[0:07:17] JG: A lot of people who went into web development in the IE 6 and so on days did not stay in web development because of IE 6 and so on. Why do you think you've stuck in that area since then? 

[0:07:28] JJ: 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, "Ha-ha. I beat you, Internet Explorer." 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 checkmark 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. I think that's where it comes from and why I've stayed with it. 

[0:08:23] JG: Lovely. It occurred to me after asking the question that not everyone in web development today might even know what IE stands for. So thank you for explicitly saying Internet Explorer. It's been so long. But okay, let's fast forward a little bit. 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? 

[0:08:44] JJ: That's an unexpected story. I never expected I would be at Google, let alone on the Angular team. 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. 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 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 I/O? That's so crazy." I was super excited about it. 

And 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. 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 unattainable to me. 

After going to I/O, I actually got to go a few times. And one year was a year where I actually saw the Angular team present. 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 I was doing an AngularJS project at the time. And this was shortly after Angular 2 came out. 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." 

Kind of flash forward, I got my first what I would call real tech job. And by that, I mean working at a tech startup, 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. 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 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. I accepted that role and declined the onsite. But there was still interest from Google and I'd get 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 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, 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. 

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. Yeah, that's the long and the short of kind of the background of how I got here. 

[0:13:37] JG: Have you seen examples in the wild of people mentioning that seeing you with communications background and so on has helped them? 

[0:13:44] JJ: I don't know that I have. I have seen people say like they are inspired by me. And I've seen like, "Oh, Jessica is my goal as far as where I'd like to see my career go." And that's always 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." Maybe someday. We'll see. 

[0:14:17] JG: Maybe a listener of this very podcast will hear this and write in. 

[0:14:20] JJ: Maybe. Exactly. 

[0:14:22] JG: Okay, let's dive in a little bit. 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? 

[0:14:34] JJ: 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. 

[0:15:19] JG: Sure. 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? 

[0:15:39] JJ: Yeah. Well, I know there's a lot of people who think about the #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. 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 the pros and cons and what we can gain from each other and how the approaches that each framework is taking. Because historically, you'll see that every framework has taken bits from each of them. And we don't think that there's anything wrong with that. Inspiration comes from other frameworks, other modalities of doing things come from those, and other experiences. 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 our way of doing things the only way," we're going to miss out on a lot. 

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. 

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." I guess maybe that's the answer is 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. I think that's where that comes from. 

[0:18:16] JG: That makes a lot of sense. It's a very good and forward-thinking way of looking at things. 

[0:18:21] JJ: We hope so. 

[0:18:22] JG: 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? 

[0:18:30] JJ: 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. 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 2 kind of switch where it 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. 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 boilerplaty, more difficult to use frameworks. Now, we're doing things like our deferrable 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, "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. 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. 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.

[0:21:19] JG: Sure. I'd like to go through those in order. Let's talk about deferrables, defer and hydration. Why is that such a difficult problem? In fact, what is that problem in the first place? 

[0:21:28] JJ: Okay. When it comes to deferrable stuff or lazy-loaded code, one of the problems that people have in complex apps is that their initial page load or - 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 when user interaction have a negative impact on your core web vitals. And, typically, the goal is to reduce that initial bundle size. 

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. You need to 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 a really - I wouldn't say a 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. 

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 @defer. 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. Just the framework handles it for you. 

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," 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. 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 applications so users can see your website faster. 

[0:24:13] JG: I think this speaks really well to at least two things. One is this shared investment in performance and clean code in 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 at defer, at loading, at error, and so on. And it just seems like a natural extension of what's already been there. 

[0:24:42] JJ: Yeah, thank you. I think we agree. The Angular team actually really likes Svelte syntax. Initially, for our at @defer, we're planning on just using the same syntax that Svelte uses. That was actually part of our initial RFC that we put out when 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 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. Now we're just trying to make a natural, easy-to-use syntax that is very close to HTML for people. 

[0:25:57] JG: Continuing forward on that, you also mentioned signals earlier. Jessica, what are signals? 

[0:26:03] JJ: 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. 

[0:26:14] JG: Thank you. Great. 

[0:26:14] JJ: Yeah, you're welcome. Yeah, some people actually put things on those lights too, like bat shapes and stuff like that. 

[0:26:22] JG: Oh, why is that? 

[0:26:23] JJ: 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. Signals is a new form of reactivity that I think was kind of pioneered in the Preact 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. 

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 we're 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 anytime that signal changes, you get kind of - subscribe is the wrong word because people think of observables when they think of subscribe, but your consumers of that signal will get notified or updated. 

It's very lightweight. And along with that, there's computed signals, which are essentially a memoized signal that caches values and updates computations that you've set based on other signals. It's kind of a whole graph of reactivity. But the key factor is that it is small and fast. 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 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 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. Hopefully, that answers your question. It's a reactivity system that is lightweight, fast, and responsive. 

[0:29:19] JG: 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. 

[0:29:32] JJ: Yeah, me too. 

[0:29:33] JG: That was a great library. 

[0:29:35] JJ: Yes, it was. 

[0:29:36] JG: Shutout, MobX. Is there a particular reason you think that signals are being added to Angular now, as opposed to three years ago or 10 years ago? 

[0:29:44] JJ: Part of that story of trying to improve our reactivity system and to improve the learning journey is 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. Synchronous work is definitely not the best use. 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?" We've been seeing that feedback of Angular and we're trying to respond to it in the best way that we can. 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. We take that as a huge sign or signal that we're doing the right thing. 

[0:31:32] JG: I love it. Are there any other parts of Angular that you think the team is going to invest in simplifying or streamlining in that line? 

[0:31:39] JJ: Yes. And we've signaled again, as such, in past videos and talks and stuff. We're constantly trying to look at ways that we can improve, as you might hope a framework team 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. I don't know if you've used Angular recently. But in the past, any time you wanted to write a component, you have to do add component. And then inside there, you've got a whole bunch of flags you have to set that it's a lot of boilerplate. It's a lot you have to add. We had to specify whether you're in standalone, and 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. 

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. We are looking at how we can reduce that. One being 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. 

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. 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. 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. 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. 

Things are using Vite now and trying to use modern build tools. I think a lot of frameworks are doing all of this, but we have to constantly evolve ours, too. 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 a lot of the other frameworks are doing, like the cash and validation strategies and whatnot for deployment. That kind of thing is being worked on. Gosh, so much. 

[0:34:53] JG: You've got a big team doing a lot of stuff. 

[0:34:55] JJ: 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. 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, any amount of engineering hours we have available to us. But I would rather us be ambitious than not. 

[0:35:20] JG: 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. 

[0:35:34] JJ: Sure. Very trendy, our industry. 

[0:35:38] JG: Speaking of which, 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 importance. 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 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? 

[0:36:14] JJ: Forced perspectives. I love that term. It's a film term. All of the things about 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. When you're server-side rendering, things like window don't exist. And that certainly adds a lot of issues when dealing with, "Ah, 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 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. 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 know we don't want the complexity of React Server Components style work." 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, one size does not fit all. 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 and FER 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 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 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 to server-side render because they need the performance, but a bunch of other pages on your site don't. It really takes careful thought to figure out exactly what is the thing that you need. 

[0:39:25] JG: It 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? 

[0:39:34] JJ: There is a vision, but I am not allowed to talk about that because that's in the Marvel Cinematic Universe. 

[0:39:42] JG: Oh, I thought he died. Is that a spoiler? He came back? 

[0:39:46] JJ: I mean, I don't want to spoil it for anybody either, but - 

[0:39:48] JG: I regret saying anything. 

[0:39:49] JJ: Like I said, I'm not allowed to talk about it because - I think hydration for us was largely seen as a detriment for years because we didn't actually have it. We had what we called 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. 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. You can get the same benefits of all that defer loading, while also leaving some of the page not hydrated until someone actually needs that code. 

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 it's 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. It's that hydration within the dehydrated block that would make it a little island of interactivity within your whole application. 

It's very challenging because Angular has hierarchical dependency injection. Our hydration system requires that parents be hydrated when we hydrate a child component because we need to know the dependencies. 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 some day be able to support the option of defining a section of your app that you want to detach from that hierarchical system and be able to make a little island of interactivity. Other things we're thinking about are how could we make our signal graph affect hydration? 

[0:42:54] JG: 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. 

[0:43:08] JJ: 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 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 started with hydration, then we looked at our deferrable system. In order to get to incremental hydration, we needed both of those. Each of these are a stepping stone in our future of improving how these things work. 

[0:43:50] JG: 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? 

[0:44:03] JJ: Oh, gosh. I'm a huge Star Trek fan. I described Star Trek as my first love. I have been a fan since early childhood. Grew up with The Next Generation, which has LaVar Burton in it, as Lieutenant Commander, Geordi la Forge, the chief engineer. And this past year, I got to go to a convention, a 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 have conventions there. 

And so I got to go to Trekonderoga, which is the name of the con. And several Trek actors were present, including Jonathan Frakes and LaVar Burton. So I got to meet both of them. And LaVar is exactly the person you want him to be. I know they say never meet your heroes, but LaVar 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. 

[0:45:40] JG: 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. Every episode, it's a different short story and it's phenomenal. He's an incredible narrator with a great, great set of books to read. 

[0:45:55] JJ: He absolutely is. Absolutely. 

[0:45:57] JG: The last question I have for you is, could you explain the what and why of Angular Cereal for us, please? 

[0:46:05] JJ: Angular Cereal. Okay. For those that are unaware, a year ago, April 1st, we released a commercial for Angular Cereal. You can go on our YouTube channel and watch it. That was my silly creation. Where it came from is a year ago for ng-conf, 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. They wanted to be on stage and then cut to commercial and then show something silly. They're just like do whatever you want. And out of that, my brain went to Angular Cereal as a concept. 

I designed cereal 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. It was ridiculous. I remember thinking while I was shooting this commercial, "What am I doing right now? How did I get here?" Since then, yeah, Angular has been a part of this complete breakfast. 

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 Oh's cereal box that was also part of the shoot. 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 the ng-conf, I actually handed out pieces of the 3D printed cereal for people to take as a little souvenir. It was a good time. 

[0:48:05] JG: Really pulling in your communications video production background. 

[0:48:08] JJ: Oh, yes. Yes. Yes. I love the fact that I actually get to use those skills when I'm on this team. 

[0:48:14] JG: 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 your mom." And it reminded me of the community post-season six after-credit scene. It was really well done. Nice. 

[0:48:25] JJ: Thank you. Thank you. 

[0:48:28] JG: Great. Well, we're already over time. 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? 

[0:48:38] JJ: 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 on Bluesky. I'm on Mastodon. I am hoping to be on Flashes when that comes out for Android. I'm an Android user. And I do have a Linktree. You can find that at jessicajaniuk.com. And that should get you to all of the things that I am currently on. 

[0:49:17] JG: That's great. Looking forward to doing that. For software engineering daily, this has been Jessica Janiuk and Josh Goldberg. Cheers, all. 

[0:49:23] JJ: Yeah, live long and prosper. 

[END]