Paul: Hi there, and welcome to PodRocket. I'm your host Paul, and today, we're joined with Minko Gechev. Welcome to the podcast, Minko. Minko Gechev: Hi, Paul. Paul: So, jumping right into why Minko is here. He's the head of product over at Angular and we're going to be getting into Angular and the new version 15 stuff that's come out. We're going to talk a little bit about the state of Angular and I'd love to pick your brain about where the product's headed and what we have to be excited about. Yeah. As the head of products, what is your involvement with the team? What are the types of decisions? Do you help lead where the product's headed and what does that role entail? Minko Gechev: Yeah, that's pretty much it. I work closely with our engineering team that is developing the framework and develop operations, which technically, I'm still managing and documentation to just set a common theme based on the feedback we get from users and decide what Angular would look like a couple of years from now. Yeah, just make sure that we're following this direction, going after it with some manageable steps that are reducing the risk for developers and for the product. Paul: Have you been in the product lead role for Angular for a while now or have you been with the group and slowly been progressing up? Minko Gechev: I guess I've been mostly involved in engineering capacity over the past many years now. I've been involved in Angular in some ways since 2012. Back then, it was Angular JS, and I was part of the community. So, I was writing a lot of codes in my spare time for fun to build modules that people were interested in and speak about these modules at conferences. After that, when I joined the team, I was really interested in Developer Relations because this aligned really well with my interests. So I kept doing what I was doing in my spare time as a Google employee and doing developer relations, I get to write a lot of fun codes, for example, building your DevTools. I also get to talk to a lot of developers at conferences and online. We're running different surveys and communicating with folks on social media. So I got to understand developers pretty well, also being an Angular user and a React user before that for my startup. I got to get some good understanding of the framework's landscape. Yeah, recently, actually that's about 10 days old role that I'm at right now as leading the product. Paul: 10 days. Wow. So, you're really ... Do you feel like you're still sinking your teeth into the whirlwind of what's going on in the plan or because you've been with the group for so long, you're like, "Okay, I understand what's going on"? Okay, you're shaking your head to the latter, so maybe more of the latter. Minko Gechev: Yeah, I've been doing that work in some capacity for a while now, and now, just things are a little bit more formal. What also happened is that I expanded the scope of my role a little bit, so I'm supporting some internal frameworks as well. Yeah. There is a lot of things to learn. There are so many design documents that I want to read and so much experiments that I would like to make. So, that's what I've been doing most over the past two weeks. Paul: Got you. So, version 15 just came out. So, that came out in the thick of you really formalizing your new position, right, as the product lead of Angular version 15? Minko Gechev: Pretty much. Yeah actually, I think it happened the week after. Yeah. Paul: Yeah, and Minko also has ... there's a YouTube video of him giving a talk on Angular as well if you want to go check that out. If you want to get more into details, version 15 in particular. But okay, so I've read some things about version 15 and what's happening. We're getting new image tags. You guys are working on some server side rendering stuff, right? What is the thing that you're most excited about in the new future set? Minko Gechev: Yeah, the thing that I'm the most excited about will be probably the least glamorous one. It's just better error messages. That is the least exciting feature, I guess from public perspective because, well, just your error messages are getting better and nobody really loves error messages. But that's something that is impacting our developer experience every single day for dozens of times. So I find this one to be particularly exciting and impactful. One of the features that shows where the framework is hitting the most is us graduating standalone components from developer preview. Now, the APIs are stable, which means that we will not be breaking them. We will be keeping them, evolving them, following the same schedule as the rest of the Angular's API. So, every six months, we're releasing a new major version in which we may introduce some breaking changes and make the updates as smooth as possible without minutes scripts for automation. These two together with the directive composition API, thinking more about it, which is an API that allows you to reuse code. You can think a little bit about it as multiple inheritance in a way or using different mix-ins but without the bad parts because we are introducing power support in Angular that makes sure that you're not getting all the headaches that you'll be getting with multiple inheritance. Paul: So, yeah, we got it. Directives are still a foreign thing in my head, so I'd love to hop into details about that a little bit more in the future. But error messages, yeah, those are huge. I mean, let's look at the Rust community really quick. The reason why Rust is so awesome, I mean, one of the number one things is that compiler. It'll scream at you but awesome stuff. It screams music. So you really know where to look as a developer. I think that's going to be huge from, as somebody who's toyed with Rust a little bit, it was really useful learning the framework. I mean for people getting into Angular, I'm sure it'll be highly impactful for those people because getting an error message when you can't even get a circle to spin on the screen is huge and telling me exactly where to look. Yeah. Was that like a multi-person endeavor, because you probably needed a visit. Minko Gechev: Yeah. Paul: Yeah. It sounds huge. It sounds like you need to visit. Minko Gechev: Yeah. Well, we worked with Chrome DevTools to enable this. What makes me the most excited about this feature is that we enabled it for Angular obviously, but also for other frameworks as well. It's very common to get an error in your application and to see one call frame that is related to call that you created, that you altered, and all the other call frames are framework related. In the React's case is going to be something around the reconciliation that happens. You're going to see some fibers there. In Angular, a lot of the Angular's run time and together with Zone Jest and RN Jest potentially if you're using it, and it's super cryptic. So, we had to work with Chrome, develop a plan on what exactly we can improve together. They had to get an understanding of Angular and we had to get an understanding of parts of how Chrome DevTools works and figure out whose responsibility is to fix what and just get the work done, which happens surprisingly fast. In about a month, I guess, we got everything up and running and we were able to make it to announce this part of version 15. Paul: Awesome. Well that's exciting to look forward to. Another thing you guys have coming is the image tag, right? That's something... Minko Gechev: Yeah. Paul: Yeah, the image... Oh, so that's a directive. Okay. So, what is the big bang with that one? Why are people so excited about it? Minko Gechev: Just to give a quick background on what Directive is. Directive is, you can think about it as just some type script code that enhances the behavior of an HTML element. So, in this case, you have an image and in the code that is associated with this image, the image directive, we are guarding you from making some common mistakes. Let's say when loading images so that we can ensure that you're getting the best coro-viral metrics, so the best performance you could get. We're also giving you some hints like looking at your image and if you're not pre-loading it but it is part of your largest content paint. Let's say we're going to give you a hint and say, "Oh, it looks like you haven't preloaded the domain where your image is coming from." Maybe you want to do that as part of your index of HTML. So, that's just one example. We are also preventing you from getting regressions for cognitive cloud shift. Which means that when your application loads, it's possible in some applications that the image just expands and gets bigger, which is pretty annoying. So, we're trying to reuse this number, the cognitive cloud shift. There are a bunch of different optimizations that the image directive does and that's another example. We couldn't do that alone because even though we are experts in web development, we're not really experts in how browsers work. That's not our job. So, we worked with Chrome on introducing this feature as well. Paul: It reminds me of being an XJS user of the image tag in XJS. It safeguards me from a lot of things. It makes it easy. Minko Gechev: Yeah, it's the exact same thing. Yeah. Paul: So, do you think there's any features that you're looking at right now that maybe other frameworks don't really emphasize that you're excited about or things that might carve out a new field of excitement for people looking at Angular version 15 or the next iteration of this version that's coming up? Minko Gechev: Yeah, I'll say the directive composition API is something that is just in... We have a compiler that does all that magic. I'll say maybe Svelte can implement something similar because of the compiler that they have but it's just like a constraint of the language and since we are adding extra semantics to JavaScript through our compiler, that's cold reuse pattern that is unique to Angular. The things that we are planning to do from here are just make the Angular change detection faster and easier to use. It is already fast, pretty fast. The call that we're generating is very optimal. The challenge for us is that we are running this change detect a little bit too frequently, otherwise we have reduced the memory consumption. We are reducing the CPU cycles that are needed to perform change detection over the entire componentry. What we're doing now is to make sure that we are running the change detection only when really necessary and we are running it only over the affected components. So these are some of the things that we haven't been doing efficiently. That's part of our reactivity effort where we are exploring what will be the most optimal reactivity pattern for Angular itself. This will lead to significant improvement over the application's performance and also would allow us to figure out dependencies across the different components at run time. So we can eventually look into a more granular, lazy loading by automating this lazy loading after the application has been server site rendered. Paul: Does this relate to the possibility or resume-ability I should say, of that's being toyed with right now in the space? Minko Gechev: Yeah, well, we have been having presume-ability at Google for about 10 years now. There is a framework that I'm actually working on right now in my fraction of my time that powers a lot of technologies. A lot of web apps like it powers Google Photos, Search, Drive, and many others. We're pretty familiar with the space and it works really well for these products. So, we would like to see whether, because it's all trade off, it provides great loading of the webpage but also set some constraints on how you're developing your application. You can do things that are really scopes to the individual components and you have really well defined rules that you need to follow so that this cost splitting can work because JavaScript is a very dynamic language. From one component, you can mutate global state and this is already going to break this resume-ability. So, we are trying to evaluate the trade offs. We want to make sure that we're heading to the right direction, whether resume-ability or partial hydration or just regular hydration is the right thing to do. That's one of the other thing one, another project that we'll be looking into in 2023. We're looking into activity, seeing how this impacts the hydration story of Angular evaluating what hydration or resume-ability pattern is the most suitable for the framework and for the users, of course. That's... Paul: Right. Yeah, in the end. It sounds like you're, and correct me if I'm wrong, but it sounds like your team is in a really good position right now to objectively evaluate what the best direction to move in for this interactivity piece is. You're talking about, yeah, should we focus on resume-ability, should we focus on this or that? Do you feel like you're in the state of being very malleable and listening to feedback. The decision hasn't been made yet and you're still scoping it out for 2023? Minko Gechev: Oh yeah, absolutely. We are constantly looking for feedback. I spent a lot of my time doing that and enjoy chatting with developers for sure. It depends, yeah, the direction will have to depends on a lot of factors for sure. Feedback from developers, it's number one. We also make sure that we have a smooth transition path. Maybe not the whole Angular is going to work, let's say with the most efficient hydration strategy. So, we would likely enable for some subset of use cases. Also, we have very close collaboration with this internal team that is building the Wiss framework or dimension earlier that has been to increase your mobility for close to 10 years now. We would like to see how we can learn from some of the lessons that they have learned over the years. So yeah, it's a very interesting space. Alex Recabbel and Jeremy Alburn from my team, they recently did a talk, Angular design review 10 years later. That was a unique opportunity that the framework has been existing for over 10 years now. It was Angular GS, now it is Angular. But this has first, great implications on the learning that we have had over years and also shows some commitment. We would not evolve the framework in some crazy direction that pushes users away. So we need to be careful in the decisions that we're making. Paul: Yeah, it's great that you're listening. It feels like slightly less opinionated than some other frameworks that are like, this is how we do it, because you're in the state of deciding it's a really good time for people who are going to be interested in Angular. Who want to use it to actually give you feedback and help influence the direction. I'm just asking about resume-ability. I'm really curious about what the current Angular team is thinking about because Mishko, we had him on PodRocket episode recently. He's working on the Quick framework and Mishko helped write Angular. He's the guy and he's all about this resume-ability concept now in the Quick framework. And it's like, this is how it's done, this is how Quick handles things, this is how it picks apart the dom. So, I just wonder if you guys are going to move in a similar direction of really embodying that development style or yeah, I guess you're still deciding which way to move? Minko Gechev: Yeah, I would say that's for sure very important for one aspect of building a framework performance. Initial load time performance is definitely important for some applications. There are also other things that are important. Developer experience is a really important piece and accessibility is a really important piece as well. Tool link is also another important piece. So finding the bonds between all these is critical. Definitely also depends on what the goals are of a framework. If the goals are to reach this super performance use case for loading an application, that's definitely people could be using something that is really highly optimized for this use case. For example, in the Google's world, we have search, which is obviously it's critical to do it as fast. It is using Wiss, this other framework that is really well optimized for resume-ability and initial all time performance. It even doesn't do server site entering in JavaScript because a variety of reasons but one of them is performance. This means that we need to be able to compile templates to another language so that we can perform faster server side rendering. There are just a lot of trade offs and very much depends on the goals of the framework. I'll say, resume-ability is powerful for initial law time performance as Google and Mishko's proving right now. And there are many other things that are important for developers. Paul: Yeah. Okay. So, you're really got to consider the whole basket of things. I think a lot of people that are still getting into web development that maybe aren't opinionated yet, that's music to their ears. That they're still a place where their opinions can be heard and listened. So, for the speaking of people using Angular and embodying the framework, I think in the past five years or seven years or so, we've had some people stray away from Angular or companies, bigger groups in general. I'm curious why you think that is Minko? Minko Gechev: Yeah, for variety of reasons. I've seen that also... Well, I've seen both cases I guess, if you look at MPM, Angular has been growing Cobora over this whole period of time. So, this means that there were more people coming to Angular rather than people leaving Angular. We could have done better job in definitely in some aspects. After we released Angular, we spent about three years rewriting Angular to implements, let's say, a new rendering and compilation model. And in the meantime, we didn't ship any significant features people have been asking us for. So, I'll say that's pretty much on us. We shouldn't have done such projects which wasn't really too well scoped. That's... Paul: Unbounded, sort of? Minko Gechev: Yeah. It had a scope creep, that was... We initiated, before I even joined the team, I remember being, meet up looking at this preview of the project and I was super excited how small the Hello World application was. But the Hello World application was small but there were all these other factors that we needed to think about as well. I'm not sure we spent enough time into doing that. And yeah, that I would say that's big part of the reason, this perfect Ivy, which now is paying back. We are finally able to take advantage of Ivy, but it took us three years to go through a stage and this frustrated some people, for sure. In the meantime, folks were using View Engine, which was the previous version of Angular that we were not really maintaining actively. It was working, it was stable, but it was not providing the features that people were asking it for. And even though it looked like the exact, it looked exactly like Ivy because we tried to keep the exact same public interface. The internals were different, so we weren't able to advance both versions at the same time. And since 2020, we finally shipped Ivy. That's the one good thing that happened in 2020 with Covid and everything else. So, yeah, now we're evolving Ivy and will be growing the framework from here. Paul: But you feel like the Ivy project was necessary to give you the platform to build this new feature set off of? Minko Gechev: Oh, I'll say it was necessary. It just turned out to be a way bigger project than we were, the team was originally anticipating. Paul: Got you. Minko Gechev: Because we're committed to preserving backward compatibility and that's not the case for all the frameworks right there. Even though everyone is doing their best to keep their framework backward compatible, just not everyone has this one repository with thousands of applications that are keeping you honest at your back. That your application is backward compatible because sometimes we fix a bug and we break a test in the mono-repo, which means that we have made a backward incompatible change. So, we need to plan the changes that we're making at Angular really carefully. Paul: So, do you think that if people might have been confused at the direction of Angular, whether it be from the Ivy project or whether it just be from decisions with all these new frameworks coming out in the past five years, if there's somebody that might identify with being in that boat? Would now be a really good time to look at Angular with version 15 and reassess and say, okay, if I'm building something, is this something I should restart with? Because I'm a React guy. I came into web development and at my age when React is really taking off. So, I'm wondering, do you think now's a good time for me to go back and go read the docs again and say, what's up with Angular? Should I hop into it? Minko Gechev: Well, it depends on your preferences. Everyone has their own. People feel really strongly about syntax often. I see how in the React community people really love functional programming and it has definitely, it has the simplicity associated with it and it's good for tree shaking and stuff. If someone is really attached to this functional style of programming, maybe it's not the right time for them to have a look at Angular right now. If they would like to explore another more opinionated approach, they should definitely have a look at Angular. And the changes with it in version 15, they're like a stepping stone for other set of features who'll be developing in 2023 and 2024. The first one will be reactivity, so change station will become way faster. We should come up with some benchmarks to be able to back up my statement but pretty confident in this. And from there, we'll be revisiting also server site rendering. We have had support for server site rendering since, I believe 2016, but it has been... A lot of opportunities for improvement there, for sure. Developer ergonomics, I would say it's not great. So, there will be another set of improvements in server site rendering in 2023. In 2024, we will be revisiting Gwalarates too. Whether the current way we're developing components is still the right way relevant for the current state of the JavaScript app system. Our class is the right way to go. Should we use strings as templates? Should we use HTML templates or something else? We'll be looking into this and clearly the voice of the community will be really highly appreciated here. Paul: So, 2024, there's going to be a lot of maybe developer experience and syntactical reassessment of the framework? Minko Gechev: A lot of syntactical reassessment for sure. Paul: Got you. Minko Gechev: That's the current plan. We'll see what happens with the recession. Paul: Yeah. Who knows? Yeah, we'll see. We'll see what happens. Right, of course. Are you guys working with any other exciting groups that are bringing features to Angular or vice versa? Minko Gechev: Oh yeah. Yeah. That's another very exciting part of my job for... I've been organizing some tech talks for the Angular team so that we can learn from each other. We had, as guests, Ryan from Solid. I really love solid js, by the way. It's one of my favorite frameworks for sure. We had Rich Harris from Svelte. We had Evan You who gave us a talk about vite that inspired some updates in the Angular CLI. Also we're working really closely with Chrome. As I mentioned, Chrome is one of the main influencers in the webspace, I guess. We worked on this improvement in the debugging pipeline and also the image component. We'll continue working together in 2023 to improve server site rendering. Yeah. Constantly working with Firebase. We had really fun collaboration with Tensorflow js that I led a year ago where we explored how we can use machine learning to predictively, pre-fetch, JavaScripts or content from our webpage. Paul: That's wild. I've never heard of that until this podcast. That's really cool. Minko Gechev: Oh, I did that before I joined Google for an experiment. I can share it, maybe in the links. Paul: ML-powered Lazy Learning. Minko Gechev: Yeah. And that's in JS and with Tensorflow, we built something a little bit more let's say, robust, which is also a little bit harder to use. Where we take data from Google Analytics, based on this data through a pipeline of transformations, we build a Tensorflow JS model that we run in a service worker. Which tracks where the user goes and based on the information, we make a prediction which resources they'll need next. So, we pre-fetch them and put them in the service worker cash. Paul: That's wild. Hey, so if anybody wants to look at that, it's Guess-JS for any listeners on GitHub. You can go search it up. Minko, do you post online about updates and decisions that are being made within the Angular team? If anybody wanted to follow you? Minko Gechev: Yeah, I would recommend them to follow the official Angular account, which is like twitter.com/Angular. We have been very active on YouTube recently as well. So, check youtube.com/Angular. For my personal takes, which are not necessarily always representations of what the Angular team thinks, you can check twitter.com/mgechev. M-G-E-C-H-E-V and I guess, that's it. Paul: That's it. I guess that's it, folks. Just some funny stuff right there. All right, Minko, thank you for your time and hopefully we'll get some people excited about version 15 who are listening to our podcast today.