Angular with Jessica Janiuk

0:00Modern 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's scalability, maintainability, and built-in features like modular architecture, TypeScript support, and robust tooling have made it popular for enterprise applications.

0:40Jessica 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 the 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 ES Slint, the tooling that enables ES Slint 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.

1:18Find Josh on Blue Sky, Mastodon, Twitter, Twitch, YouTube, and.com as Joshua K. Goldberg.

1:38Jessica Janik, welcome to Software Engineering Daily. Oh, thank you for having me. 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? Oh, gosh, that's a really good question. So I got into coding probably back in the 90s, which is showing my age. But with my first family's 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 kind of messed up our computer quite a few times. But discovered I had a knack for it back then.

2:20And so that was probably the first foray. I took like 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 like a knack for tech. So 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. So I kind of roundabout made my way into being in engineering for a career. What did you do before you went into engineering as a career?

3:04So I started my career in video production. I worked as a producer working. My whole goal was to eventually make my way out into 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. 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 the jobs that are far less glamorous. I was writing for our real estate support services company.

3:49So 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 the 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.

5:00So I pivoted my career at that point. So that's essentially my roundabout way of getting into actually engineering and tech. 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. 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. It's like one of those cookie clicker style games where you keep doing the thing so that you can do the thing more.

5:40Yes, exactly. Where did you go after MLS data automation? 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 Squarespace's 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 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.

6:28And 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 IE6, IE7, IE8 days and having to deal with all of that.

7:06I was writing Cold Fusion code. That's a throwback. Yeah, I think it still exists. But I haven't touched it since that job. 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? 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 the 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.

7:53And I think there was also that sense of like, ha ha, 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 lovely it occurred to me after asking the question that not everyone in web development today might even know what IE stands for.

8:30So thank you for explicitly saying you're an 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? 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.

9:06And 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 face. No, I'm just kidding. I didn't actually have stars on my face. But I was just 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. 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.

9:52and 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. So 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 is, I was doing an AngularJS project at the time. And this was shortly after Angular 2 came out.

10:36So 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.

11:17Would 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 onsite. But there was still interest from Google and I 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.

11:56And 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.

12:36And 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.

13:22and 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. Have you seen examples in the wild of people mentioning that seeing you with communications background and so on has helped them? 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.

14:14So maybe someday we'll see. Maybe a listener of this very podcast will hear this and write it. Maybe. Exactly. But 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? 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.

15:04Our 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. 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? Yeah. Well, I know there's a lot of people who think about the hashtag framework wars out there.

15:44but 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 View 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.

16:29Like, you know, 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. It's 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.

17:23And 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 the 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.

18:13So I think that's where that comes from. That makes a lot of sense. It's a very good and forward thinking way of looking at things. 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.

18:50Start building smarter, more reliable agents today. Visit postman.com slash SED to learn more. 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? 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.

19:32So 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, Angular2 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.

20:15So 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 boilerplate-y, more difficult to use frameworks. Now we're doing things like our deferral 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.

21:00And 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.

21:54Sure. 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? 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.

22:43And 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 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.

23:24So 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 at 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. 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.

24:06Here'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've got to handle making that performant 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.

24:47I think this speaks really well to at least two things. One is the shared investment in performance and clean code in service 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. Yeah, thank you. I think we agree. The Angular team actually really likes Svelte's syntax.

25:24And we actually 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. And it was actually due to user feedback that we ended up switching to the at syntax. But yeah, like I think originally the concept behind Angular templates was that it was just HTML. And the truth is it's, 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 attributes syntax.

26:14Because 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 continuing forward on that you also mentioned signals earlier jessica what are signals 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.

26:56Oh, 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 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.

27:42but 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 we're also talking a lot with the solid team and proposed this idea of us using signals.

28:29Signals are essentially a reactivity primitive where you can create a signal and you put your value in that signal. And any time that signal changes, you get kind of a... 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. So 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. So it's kind of a whole graph of reactivity. But the key factor is that it is small and fast.