Angular merger with Wiz with Minko Gechev === Paul: [00:00:00] Hi there. And welcome to pod rocket, a web development podcast brought to you by log rocket log rocket help software teams improve user experience with session replay, error tracking and product analytics. Try it for free at log rocket. com. Today. My name is Paul and joined with us once again is Miko Gichev. He is the engineering product and dev rel lead Over at Google for Angular and we're going to be talking about quite a few exciting things today they recently had a talk at ng conf and you should go watch the talk if you're interested They have real good energy on stage because there's exciting stuff We're gonna be talking about Angular merging with Wiz if you used Wiz it's very exciting time to hear that We're gonna be talking about signals new cool kid on the block in any case excited to talk about what's coming And what you guys have recently shipped. Welcome to the show, Minko. Minko: Hi Paul, really happy to be here. Paul: Yeah, and Minko, he's a regular guest on our podcast. So if you'd like what you hear today, and you want to learn more about the history of Angular and his team, go check out some of our previous podcasts. And I'm sure we'll be [00:01:00] continuing keeping up to date with you guys as time rolls on. Minko, Just really quickly, let's jump into it. Can you elaborate on some of the recent developments in Angular? We call out some of them, we got signals, we're merging with whiz. And that's probably the big thing. So merging with whiz, right? Minko: Yeah it's pretty massive actually. We started working on it about a year ago and you don't hear too frequently frameworks merging. actually I can share a little bit more about WIS as well, because it's not a popular framework. It's actually an internal Google framework. Paul: please, because I actually myself don't know anything about whiz. So enlighten me. Minko: Yeah. WIS is an internal Google framework. It is used by thousands of engineers inside of Google. It is mostly targeting consumer products. So it is very highly optimized for low latency, specifically for performance. And it has been used by probably most of the products that we rely on every day, like Gmail, Google search, YouTube, Google drive, Google photos, all these Google products that I personally [00:02:00] use every day and it has been in this space, like existing in Google for about 10 years now or so the focus has been on performance. And obviously it depends very much on the goals of the application as well. Like for example, performance in Google search is critical and the use was very effectively there. You can see that, opening Google search is instantaneous. Over time, a lot of people have been using WIS and the developer experience of WIS has been not as friendly, let's say as Angular. So people using WIS have been wanting some of more of the Angular features. And so on the other side of the spectrum, Angular has about a couple of thousands of developers inside of Google as well. And a lot of them have been wanting a lot of the performance features of WIS. So both teams, we started working closer together and we started figuring out how we can get inspiration from each other. And that's how this merger is happening. Actually, it's going to take a long time, but we're going to see the benefits immediately. We're already seeing them. For [00:03:00] example, YouTube mobile web, a hundred percent of the YouTube mobile web traffic is currently using Angular signals with WIS. Paul: So when we're saying merging whiz is going to, in essence, like stop being worked on as its own entity, and it's going to become part of the Angular product moving forward. Minko: It will be like a very long process in which we'll be slowly merging individual features. And until the time it makes sense. Also for us, the highest priority is just to build the best framework for developers. So if it's at certain point, we figure out that there are some features that don't make sense to be merged and they can co exist then we are just going to continue doing that. But overall, the goal is for both frameworks to become one framework and to open source all of the WIS features through the Angular brand. Paul: did the push to allow these technologies and frameworks to converge come from, more of a leadership position of saying like, Hey like, from a product perspective, these belong together, or did it come more from [00:04:00] wanting to cherry pick certain things as an engineer? You're like, Hey, whiz does this? And I wanted an angular. Minko: Yeah. I'll say a little bit of both. It's mostly just seeing the requirements converging, the requirements for both Angular and WIS converging and developer just needing the same things over and over again, and we look at Angular's developer satisfaction survey and we see that server side rendering is one of the biggest opportunities for us. So that's one of the reasons why we're exploring partial hydration right now. And working that closely with WIS, we can talk about partial hydration maybe later. And so WIS, they do the same developer satisfaction survey and they see the developer experience on their end can be improved and they can have better reactivity story, let's say. So that's how they, we started talking together and decided to explore this. Paul: And the other thing that I have on my little sticky note to talk about here is material three, right? I feel like I've used material but that's a different thing that we're talking about for the sake of the angular roadmap right here. So can you talk to us a little bit about [00:05:00] the scope of material three and why that's a really big deal for the people who are using the product? Minko: Yeah. So Material 3 has been out for a while mostly for Android though, and for JavaScript and for the front end development, it wasn't sure really what does that mean because it has a very wide, very broad set of design tokens that we have to define and figure out what do they mean for the web. So the Angular team was working pretty closely with the material team so that we can define these design tokens. And through a lot of iterations updates, the current set of material components, make them way more customizable and ship experimental support for material three. In Angular, it has been exciting. I, in fact, over the past couple of years, I've been getting questions from the community. When is Angular finally going to support material three? Because there are all these community libraries that. support material three and it was hard to say well, they support like an estimation of material three, just because there is no really material three [00:06:00] for the web right now. Yeah. So we're happy that this move forward as well. It took a long time. It was a lot of work for the Angular material team and Yeah they did a great job. Paul: UI stuff is really exciting. Even if you're not like a hardcore front end person, being able to like whip someone together and get the feedback is really nice. Are there any particular token sets or components, refreshes that you yourself, you thought are really sweet. We should look out for. Minko: I really liked the whole thing. It is on material. angular. io. We updated to Material 3 now, the design, and it just looks pretty smooth. I really like it. No particular components Paul: Okay. Refresh overall from Inko. So what was the website one more time if people want to go poke around? Minko: it is material. angular. io. Paul: Material dot angular dot IO. Gotcha. That's great. We got a kind of like a bird's eye view of the updates and what the team's working on. I'd love to dig down a little bit now into one of the stars of the shows, which is signals. This has been a [00:07:00] ever so popular and ever so increasing way to put reactivity into applications. And personally, I haven't used signals a lot. But reading about them, it reminds me of an observable from something like RxJS. So could you enlighten me a little bit about specifically, what is the signal in the web specification? And how are you guys leveraging that? Minko: Yeah. We can look back all the way back to the design patterns book with the small talk and they have some kind of like observable, they had an observable pattern and conceptually it could be somehow similar just because you're observing a value over time. And when the value changes, you're performing certain action. That's pretty much it. And Solid popularized this pattern really well, specifically Ryan Corneado. He has been a very big advocate for signals over time. We, in fact, consulted with him on the Angular signals implementation. We wanted to make sure that we learn from his experience and, we're really grateful for this. Actually. We have a really good [00:08:00] collaboration there with signals in Angular. We can perform very fine, like updates with very fine level of granularity. So rather than, signals are mostly helping where we, let's say you update your component state and the updates need to be reflected in the view. And there are many different ways you can achieve this. Like for example, React has their virtual DOM where they're performing this reconciliation, where you're comparing component trees and patching the difference. In Angular, we used to do something similar, but rather than comparing component trees, we just traverse the component tree and compare the state with the previous version of the state. And we patch the difference. With signals, we can wrap the state in a signal and read it somewhere in the template. And when the signal changes, we can go directly to this part of the template and Updated or schedule an update for only this particular part of the view. So we don't really need to perform any global checks [00:09:00] this way. Yeah that's part of it. We together with this though, we wanted to improve the ergonomics of Angular with signals more. So we introduced also signal inputs. To the framework and this way just enables your component to receive data, similar to like in React they're called props, so in a similar way as you're just passing data and this data is wrapped in a signal so that you can observe it in a similar way with an effect and be very truly reactive. These are some of the improvements we did there. And this plays really well in a very interesting way with fine grain code loading also, that is one of the biggest wins that we're getting from the partnership we're merging with or merge with WIS. Paul: You said fine, green, Code loading. What, talk to me about that. But what is that, what is a fine grain versus a coarse grain code load? Minko: Yeah. So traditionally when you render [00:10:00] an application on the server, the server is going to return like the render HTML, going to get, this is going to, the browser is going to receive that, parse it, create the DOM from there. Just going to find all script references, download all the JavaScript that you have for this page, execute it and hydrate your page and make it interactive. And if you have a lot of JavaScript, It could impact your total blocking time. And from there, it can impact a lot of some Core Web Vital metrics, specifically the INP, the interaction to NextPaint. And like people also tend to start rage clicking at certain point. Imagine you get the page rendered, but the JavaScript hasn't hydrated the page yet. So you just start clicking on the page to do something and nothing happens until. Eventually the sole script gets executed and the page becomes interactive. So that's what traditionally happens with hydration and. Let's say non fine grain code loading with something that was introduced long time ago and QUIC actually [00:11:00] made, like it's trying to make currently popular in the open source communities. it varies on different levels. Let's say QUIC call sets, resumability, a slide variation of this could be partial hydration, for example, where instead of hydrating this entire componentry and downloading the entire JavaScript associated for your current page. You wait for the user to start interacting with the page and you figure out the minimum amount of JavaScript that is responsible for handling this interaction. You download the JavaScript from the server or from your CDN and you hydrate only this part of the page and you replay the event. So this usually provides significantly better interaction to NextPaint metrics and makes your page more productive. Yeah. More responsive, faster. Paul: Continuing to talk about signals here, like one other feature that you guys were showing in the talk at NG conf was the APIs that you folks are offering. And signals they can be used. It's my understanding like you can leverage the powers of signals and in a [00:12:00] variety of different contexts, but making them ergonomic and easy to use and wrap your head around is arguably more than half the battle sometimes because if it's not ergonomic, people aren't going to use it. And having a value that you may be listened to and, what you guys are putting out, you can even play with it. push values and via the signal channels really neat. In terms of listening to a reactive state and then updating wherever it might be. It reminds me of something of Svelte. And I'm sure if people have used Svelte with the dollar sign, you just make a value. And you can throw it in your markup and it'll change like that's a really ergonomic API. And it's something that folks loved about Svelte. In the talk, there was it was evident that you guys put a lot of thought into this into what's coming out with Angular right now. So can we talk a little bit about, for example, the query API and how easy it is to use and maybe two or three of the other ones that came out? Minko: Yeah. One of the APIs that we introduced this around querying the view so that you can get, Elements, I guess in, in [00:13:00] react and equivalent probably would be a ref probably, I guess you to get like reference to a specific DOM element or to a particular component in anger, you're abusing the so called view queries. And since these. The results of these queries, they can change over time. They make sense to be signals too. You can just wrap the signal, read in an effect. And every time when the signal changes, you'll be getting an update. So that's pretty convenient. Something else that we introduced is a so called model input, because sometimes you need to have a signal that you can read them, right? Let's say you have a checkbox on the page and you have a component that uses this checkbox. And you want to update a boolean property in the parent component when the checkbox toggles. So when the internal state of the checkbox changes, you want to update this boolean property. You can do it with passing a callback to the checkbox. And when the value changes, you involve [00:14:00] this callback and this updates the parent property. That's an option. We introduced something that removes the boilerplate. So you don't have to really do that. It handles this. Complexity free automatically, these are the model inputs. You just declare a model input, you bind to this checkbox check property. And it synchronizes the state between your parent component and the child component. So these are, I'll say these are two of the most interesting signal APIs that we introduced lately. Paul: Yeah, binding, like just native binding. In Angular feels like really novel, right? It's something that I've made a simple app in Angular before. I've never used anything like that, particularly like through signals. So and when you're saying you can bind to the modal, it's in its own dialogue sort of state. And it's completely separate from everything else on the page when you bind that input. Minko: Here, I guess I made model specifically. We call it the model input because it's a readable, [00:15:00] writable. You can create search bindings with any UI component. Could be a checkbox. Could be a model. it could be a model that a dialogue could be like anything. Yeah, Paul: Anything readable and writable. So it's in it like any, Gotcha. Minko: Yeah. Any UI component out there. it's pretty neat. Yeah. I've been using it a lot lately in my projects. Paul: Because there's just something that is definitely really strong about being able to have short, code snippets that you can just throw in there. And as a developer, when you get to that point where it's like, when you're running, and it's really difficult at first, and then you start going, like 10 minutes into your run, you're like, Wow, I'm like breathing differently now, because I'm just not even thinking about it. That's a magical place to get to. And that's something that I know, like Svelte has at least done for me personally with the binding and the reactive elements. but here we have it in like an enterprise grade framework, not that spells like not enterprise grade, but just like speaking historically, like Angular has been used for a lot of these heavy hitting applications. So really fantastic to see it coming through there. Minko: Yeah. We've been getting some inspiration from so as well. We updated our control flow, [00:16:00] for example, and actually so in order to see whether we are building the like the best signal APIs, we started working with, we run some user studies. So we just found developers with different backgrounds and different levels of experience and using variety of frameworks, like React, Angular, Svelte, and we asked them to implement a simple application using Angular signals. And we saw that all of them actually struggled with just iterating over a list of items. So we figure out we'd be really opinionated about you always like your template always being valid HTML. But if people are struggling to iterate over a collection, maybe we should revisit our control flow. So we did that. We implemented a new control flow and originally the design, the syntax was inspired by Svelte specifically. there are a lot of cool things happening in the community we get some inspiration from, we ended up implementing different control flow syntax. Actually, someone commented on our RFC and proposed an alternative syntax. And we collected like thousands of responses comparing [00:17:00] the original proposal that we had inspired by Svelte and the community proposed one. And people ended up liking the community proposed one. So that's what we moved forward with. But was a great starting point for us. Paul: One of the huge things that I'm hearing from the story that you sharing with me is the team is really putting heavy weight on user feedback. Like you're listening to comments, you're actually sending it out for testing, you're pivoting the roadmap based on what other normal devs are talking about. Minko: Yeah, Paul: destined for success, if that's how you're doing it. That's really great to hear. And Minko: yeah, that's how we drive the roadmap developers surveys, feedback from conferences social media, even makes a big difference, it gets a little tricky sometimes to filter the filter like there are certain biased opinions. There are always people on social media who are more vocal than others and making sure that the representation. Kind of the feedback we're getting represents our community has been the thing that we pay the most attention on because [00:18:00] it's really hard. Paul: right before we step into some of the rendering stuff, because folks, frameworks, and the rendering strategies, super important. Everybody wants to know about that. We're going to talk about that in a minute. Last thing I just want to double click on with the signals is the talk you had I forget the gentleman's title, but he was, working on the YouTube applications and he came up and he was talking about these performance improvements that were just like pretty mind blowing. 'cause usually like when you have a performance improve, it's very marginal. But there's like FPS upgrades and just like the normal usage of for example, like the YouTube application when you're using it. Do you think that a lot of developers can expect to reap similar benefits by moving stateful logic into signals just by virtue of like how they're implemented? Minko: Yeah. I would say likely developers are going to experience major performance benefits with signals over time. we are still evaluating actually how the signals performance scale. We don't really know for certain and YouTube is currently actively [00:19:00] using them in their products, including smart TVs and also mobile devices, lower end mobile devices. So far the results that we're getting are really impressive and we'll see how they're going to evolve from here. I'm pretty optimistic, can't be certain until we really use them at a massive scale. Paul: Of course. So yeah, let's get into some of the rendering stuff now right before we do. So I want to remind our listeners that this podcast is brought to you by log rocket. So it doesn't matter what framework you're really using. If you have a DOM tree, and you have events going through there, you can probably leverage the capabilities of log rocket to find and build a better app faster and ship to your users and actually build what they want. So you can do things like have AI search over like patterns and in erroneous things that are happening. So you can find and. solve issues faster, he can get heat maps and all sorts of other cool stuff like full session replay. So if you want to spend less time in the debug console, more time building, head over to live rocket. com today and try it for [00:20:00] free. Minka let's talk about rendering you mentioned a little bit at the beginning, we can talk about Hybrid or the partial rendering that you guys are thinking about specifically those server side rendering. It's like the poster child of 2023 and 2024. How are you guys thinking about server side rendering and build time, pre rendering Minko: Yeah we did some improvements in our build pipeline there to just improve the overall server side rendering. Let's say hybrid rendering story. By hybrid rendering. I mostly mean when you're using like client side rendering with mixture of SSG, let's say, or pre rendering and server side rendering. There are just so many different names for this in the Paul: so many permutations, right? Yeah. Minko: Yeah. And we've been usually calling it pre rendering for our SSG or static side generation, because just sounds a little misleading. It's not a, it's still a dynamic web app, so it's not really a static site. But. Yeah we did some updates first on our build pipeline because we wanted to make sure that [00:21:00] just. You have good experience when building applications with SSR, when you have to build your client and the server. So we moved to V there and use builds. We saw some significant performance benefits. Let's say Vanguard. They're pretty good finance, pretty like big financial institution. They saw about three times faster builds after we updated the build pipeline there. So with this, we also observe higher adoption of Angular server side rendering. We looked at HTTP archive and we saw that there uh, compared to version 16, version 17, there were 30 percent more people, I think, or 37 more using with server side rendering or pre rendering. So this worked out pretty well. And the other improvements that we have been doing there are mostly around. More fine grained hydration, because that's where we see that most of the difference comes from. We have prototypes of streaming as well. We just didn't consider it to be the most impactful at this point. And [00:22:00] that's why we're moving forward with partial hydration that is coming up later this year. I'll say probably June, July. We are going to have a couple of demos that we're going to share soon. Until then there, we're using this primitive from WISC called JS action. And what it does is when you get your page into the server rendered, you don't load any JavaScript, you just inline this small script of JS action, which is a very tiny library, which just waits for you to click on a button somewhere, let's say, or engage with the page, like start typing or whatever. And it's captured the events. At the body level. So it waits for the event to bubble up and captures the event there. And based on the identifier of the element that you interacted with, it figures out what script it needs to download so that it can hydrate all of this part of the page and make it interactive. It has been pretty exciting to see that in Angular, [00:23:00] especially because originally we didn't design Angular with this in mind. Back in the day, that was not really a requirement. And making it work already in very like natural way was cool to see, and yeah, we're going to have more details about it and demos coming up soon. Paul: So you're essentially like taking the problem of identifying where in the tree and what to load out of. The virtue of like where it's structured depth wise and you're saying like, let it bubble all the way up and I'm going to use just a little bit of JavaScript to figure it out. And it's going to save me down the line because I don't have to get all this junk in there when I don't really need it. Minko: exactly. That's what happened. So it Paul: And it's just like a one liner you throw in there. Minko: Yeah. So we actually made it play really well with some primitive that we introduced in version 17. We introduced the so called deferrable views. And they allow you to wrap a page, like part of your page and specify, let's say on viewport. This way, this deferrable view, this is going to be lazily loaded only [00:24:00] when like a piece of, the DOM enters the viewport. So it just literally two lines of code actually could be, I don't know if you count the braces or not, but it is add defer on viewport with some loading indicator. And when the loading indicator enters the viewport, we just The actual code and we render it and we made this work with server side rendering as well. So if you wrap, when you're server side rendering part of your DOM tree in a deferred block it will be rendered on the server, but we're not going to download the JavaScript on the client until you actually interact with it. And, you know, like a very frequent question that I'm getting is, when you start interacting with it, you need to go to the server and you need to like download this code and replay the event. So this can call some latency and that's true ifit can. So that's why also there are different heuristics that we can apply. We can preemptively like prefetch parts of the page that are likely to be needed. Or alternatively we can just like prefetch, like everything in a service worker, but we are [00:25:00] not losing any events and there is no really any blocking time involved with this full application hydration. Paul: one thing that it sounds like Angular and the team is really pushing on here is developer experience as a whole. You got the really polished signal API is coming out. We have things like you're making it really easy to affect the way that like the hydration of JavaScript happens in your application without really having to like, crack the nut if you go to other frameworks, sometimes, and you want to look at pinpointing, like how you load things, and maybe you have you're going to islands architecture or something like you do have to know a lot, there is an ever increasing barrier to entry to being a truly full stack person and understanding the client server relationship. And it's really nice to see. that your team is focusing on making this palatable for people, even if it maybe is a newer topic. Would you say that this isn't like a first class citizen [00:26:00] focus for the team is developer experience right now. Minko: yeah, for sure. And backward compatibility and incremental adoption as well. We can do many things that would be really exciting, but there will not be incremental adoption and people will have to rewrite applications. And that's not our goal. We want to make sure that everything has incremental path to adoption and we gradually evolve the framework, and focus on like smooth learning curve as well. Paul: And speaking of the learning curve, are you having the team work on anything specifically in regards to developer onboarding, like not just accelerating and growing the teams and usage through that, which exists, but like net new. market share and onboarding. Minko: Yeah, there is a website we announced in during like version 17, but it has been, we intentionally didn't want it to get indexed by Google search yet because it was still a work in progress. So in about two months, the default [00:27:00] learning journey and documentation website for Angular will be at angular. dev. And you can give it a try right now. It's out there. We have an interactive learning journey that is going to take you through the, from the concepts of Angular one by one significantly simplified learning journey compared to what we previously had on Angular. io. I'm really happy with it. It uses web containers. So thank you StackBlitz for building them. Paul: Yes, the other I mean, we're thinking back to spell. It's not like exactly the same, but they do something similar. And it's a magical experience. That is a great learning experience. It's the fastest duration, not dealing with the local environment. Like it's fantastic. So angular. dev. So it's up now, I could do it now. Minko: Yeah, you can check it out. We have a new design there too. And there is a fun scroll animation when you start scrolling. Let Paul: folks, angular. dev. If you want to check out A new suave interactive tutorial style. That's fantastic that you have the team putting this out right now. Looking down the [00:28:00] roadmap. We already mentioned one thing in relation to the hydration and being able to optimize the events bubbling up the tree, but anything else that you can share with us, Minko, but what's coming in 2024? Minko: me quickly look at the roadmap. to make sure that I don't miss anything major. we have focused on developer velocity or developer experience. And Angular with signals and making sure that Zonges could be turned into an optional part of Angular in the future that's number one. And it's going to take us a good amount of time to get there also. So also performance and how, having hybrid rendering from the start for people who want to use it. That's also really high on the list. One thing that we're really opinionated on is hybrid rendering is definitely a great idea. It's good to have server side rendering and pre rendering or SSG. But we also want to make sure that. You're not locked to having this because just sets higher requirements on your hosting environment. You need to pay for a compute rather than just having a static [00:29:00] CDN somewhere. So we're going to enable it by default, but we also want to make it easy for you to opt out of it. And another kind of major thing that we're looking into is improved authoring format. We are not going to make any major changes for now. We would like to make gradual improvements. Based on what has been a lot recently from other changes in the framework. For example, standalone components. So we're going to iterate on the altering experience there to make it even easier for people to create Angular components. Paul: those are three huge ones like growth, organic growth of the ecosystem by letting other people create components is a big one. Minko: Yeah, Paul: right? Yeah, like I'm bound to creativity. So Minko: Yeah. Andwe have planned our release events also. So it's every release we made this tradition to have streaming of the release events on YouTube and they have been pretty fun. We got 400 watching the last release event and we had like almost no drop rate, like 5 percent drop rate. So people watched there for two hours, which I was [00:30:00] grateful to see. It was so cool. Yeah, Paul: few releases that happen on YouTube, like or talks, and it's nowhere near 4400. So you guys are doing something, right? That's pretty great. Minko: that was during the the stream actually. We, I think now we're maybe at a hundred K or so. 141, 000 people. Yeah, it was cool. Paul: Wow, that is cool. Congrats. Thank you. So once again, if you want to check it out, it's angular. dev. And Miko, if people wanted to, in particular, just keep up to date with you. What socials can we share with folks so they can get the latest on angular and if not Just what you're thinking Minko: I'm on Twitter. I might handle there or X. My handle there is M Getchev, M G E C H E V. And I'm on LinkedIn as well. Same handle there. Also blue sky and master on all of these. Paul: Same handle m Minko: Same. Yeah. Luckily that's like a SEO optimized name. So Paul: No, that's awesome. It's good to remember. It's easy to remember [00:31:00] m gateshift everywhere And miko, it's been Awesome having you on it's great that we have these like scheduled here on pod rocket over and over again because it's like we're on this arc of the new angular and it's really neat to keep up with you guys so looking forward to the next one when we have you on and yeah it's just been a pleasure Minko: also, yeah. Thank you for having me, Paul. It was great chatting with you.