Brandon: [00:00:00] I would like to see more collaboration across the frameworks. Vite is like a shining example of what happens when you have like a solid foundation that everybody can use and we can have these discussions about features that we're building or features that we want without, Hey, my thing is better than yours
[00:00:16] Introduction
Andrew: Hello. Welcome to the DevTools FM podcast. This is a podcast about developer tools and the people who make them. I'm Andrew. And this is my cohost, Justin.
Justin: Hey everyone, uh, we're really excited to have Brandon Roberts on with us today. Um, this is kind of a fun episode, uh, Brandon and I actually share an alma mater. We went to the same college, which is a small world.
Brandon: Very.
Justin: so that was a, that was a fun learning experience. Uh, so Brandon, you've done a lot of really interesting stuff.
Justin: So you're the creator of analog JS. Uh, we're really excited to talk about that. Um, you've done some, uh, Work [00:01:00] around maintaining NGRX. Uh, so we're excited to sort of dig into that ecosystem a little bit Um, and you're working at opensauced. So we had uh, brian douglas on bdougie on A little while back and it was a super fun episode and really love what you're building there So excited to talk about that too before we dig in.
Justin: Would you like to tell our listeners any more about yourself?
Brandon: Yeah
Brandon: the good intro in there. Uh, I always tell people you can follow me on Twitter, Brandon T. Roberts. Uh, I have fun on Twitter. I block people sometimes, but generally it's mostly in fun. So, uh, that's mostly, uh, most, the most, uh, ideal place you can follow me. I'm on, you know, GitHub and things like that.
Brandon: I don't know if people actually do anything with people, following people and get up, but I'm on there. I'm on LinkedIn. I'm on all the places. Uh, but yeah, it mostly find me on there ranting about something, uh, sometimes. So,
Andrew: That that's actually a good segue. Uh, the place you work at is a place that's trying to make GitHub better. One of the things that GitHub does suck at is why would you follow people? Like [00:02:00] they don't even surface a good way to use that information.
[00:02:03] Open Sauced Overview
Andrew: So, uh, for our listeners who might not know what open sauced is, could you explain it a little bit and then tell us about something cool we've shipped lately?
Brandon: yeah, so, uh, open sauced is an insights, uh, platform into open source where you can learn all about insights into different things that happen in open source. Uh, you can find out trends. Uh, we have, uh, pages where you can see analytics on individual repositories, as well as, uh, another thing we call workspaces, uh, where you can.
Brandon: See all the workspaces that you're interested in and get some analytics on those. Uh, but yeah, we provide actionable insights, uh, into open source, whether you're a maintainer at a company, open source, first company, or even a company that uses a lot of open source and you want to gain some insight and see, you know, what are, what does health look like?
Brandon: What is, you know, a good, uh, open source project, uh, look like, and we can provide all those stats and things that you're looking for there. [00:03:00] Uh, so yeah, those, that's what opensauce is in a nutshell. You can go to opensauce. pizza, of course, uh, love the domain there to find out more information about that.
Brandon: And, uh, something we've shipped, uh, just recently, uh, here is, uh, what we're calling the, the Oscar score, uh, which is an open source contributor rating where you can find out. Uh, information about if you're new to open source, if you've been in open source for a while, you can actually see your impact, uh, what you're doing and across different areas.
Brandon: So that would be something that, you know, people can actually go and check their own, their own score. And, uh, you know, you can kind of think it's not necessarily like a credit score where it's, it's, uh, but it is, uh, does have a sliding scale there just to. See what your impact is and, uh, see where, you know, what, what kind of things that you're doing to contribute to open source and help, help to help open source in general, move forward.
Brandon: So excited about that.
Andrew: So that probably takes in more than just like your contribution graph, right? It's like [00:04:00] looking at everything.
Brandon: Yeah, it definitely takes in more than, uh, well, it's not just started, but definitely not just based on stuff. I don't, I don't even. Think it factors in repos that you start or anything, but it takes a lot of things in like your PRS is probably one of the biggest things people look at, but also factor a few and other things in there, as far as your engagement with other people and, uh, just generally how you interact in open source and all those things kind of, uh, build up that, that score that you have.
Brandon: So, and it's, it's something that builds up over time. So. Uh, if you're, of course, if you're relatively new, uh, you may, you're going to have some work to do there, but, uh, it's, it's, I think it's a good enough time window that you can see, you know, what a good, uh, what a good, a good particular rating looks like, uh, something to expire, expire to an open source.
Andrew: So using open sauce, can I like see trends that are kind of happening on get hub? Like over the past few weeks, uh, there's been a movement called E 18 E, which I [00:05:00] think is like ecosystem cleanup where you can see a bunch of different people like swapping out packages and targeting very specific things to update.
Andrew: So can you from like a high level see that from open sauce?
Brandon: Um, I think we have some, uh, if I'm not mistaken, we do have some end points to kind of surface, uh, repositories that have, uh, A lot of activity or are there like training and things like that based on, you know, contributions and things like that. Uh, but that is something that we've kind of seen in our data.
Brandon: We aren't necessarily surfacing that today, but we have been able to see, dig into the data that we have to see trends like that, as far as, uh, repositories with a lot of activity, different things like that. So, uh, one thing that we do have on open source is repository pages where you can actually go into a particular repositories.
Brandon: You can see. Uh, pull requests, contributions over, you know, different time spans. And, uh, also see a few things, uh, that we've, uh, some more [00:06:00] insights that we've talked about one, when those things being like yellow coders, we call them where people who just push domain as opposed to doing pull requests, uh, cause sometimes there are repositories out there from the data that we've seen that, uh, They don't look like they have a lot of contributions, but that's because, like I said, YOLO, the main person is pushing to main and then the other people are doing pull requests.
Brandon: Uh, I think the, the repository we were looking at was PG vector was like the main contributor was just, Hey, he just pushes commits to main. And then everybody else does PRS, but so it looked like they didn't have a lot of activity, but in fact, it was just that that person, a particular person was the maintainer and they have been maintaining a project for a long time.
Brandon: So they kind of know the ins and outs. They're just kind of, uh, going forward with that. So things like that, little nuggets like that, you can kind of glean, uh, from there, uh, on those repository pages. And then we're kind of sprinkling those throughout the platform [00:07:00] also.
Justin: It's fun it makes me wonder if there could be like a repository Like maturity score, you know, almost. Cause there's like certain things that matter. Like, oh, do people use the PR flow? Um, are they, do they have CI set up, you know, are, are reviews actually done? There's like a lot of stuff. Is there a license?
Justin: Is there a readme? You know, all these things that go into like, is this like a mature
Brandon: Yeah, we are surfacing some of those things too. Like what license are they using? And, uh, we're, there's another thing we call contributor confidence. Uh, and, uh, Brian probably talked about this also, but, uh, where you can see what's the likelihood of somebody starring your repo or forking in and actually coming back and making a contribution and things like that, but yeah, I think those are, those are good ideas.
Brandon: Also things you could. Uh, people, you know, different, different insights mean different things to different people. So, uh, some people will look at the Yolo coders like, Hey, I have to do that. So I have to do that for releases or things like that. So, uh, it just depends on the [00:08:00] perspective of contributors and maintainers, I think.
Justin: Given that y'all are sort of building, uh, Almost like an analytics and insights company around like this work area, like open source software. Um, I'm sure you've had exposure to like a lot of data just surrounding how people are using, uh, open source projects or contributing to them or whatever. I'm curious from your perspective, what you think some of the biggest issues are in the open source space and maybe to sort of add on to that, uh, what.
Justin: What sort of problems y'all are seeking to solve by providing, you know, your solution.
Brandon: Yeah.
[00:08:40] Challenges in Open Source
Brandon: So for, for me, I've, I guess I've done this a couple of times at this point across different, different projects, but, uh, the biggest issue I've seen, uh, that has kind of more or less impacted me in the project that I worked on is, uh, was part of its funding because the, the biggest, one of the biggest [00:09:00] issues that is that people just inherently want everything in open source to be free and they want, You know, it takes time.
Brandon: It takes resources, um, for people to work on these projects and myself included. And there has to be a way, uh, some sort of path that we can go to make that process easier. I mean, we have things like get up sponsors and you can kind of basically go on the, into like pitch mode and, you know, ask people to donate to your project, or then you get some, you get enough adoption to where, you know, It becomes, you know, a critical part of people's infrastructure, but still, they can still just take that and just use it for free.
Brandon: Uh, with, even without you knowing or without, you know, ever like donating or anything like that. So being a, having a, some sort of way to connect maintainers to companies, uh, to people. To be able to maybe start that conversation, I think is a big part of that. [00:10:00] And part of what we do in open sources, uh, we could help tell that story.
Brandon: We can help, you know, see the adoption over time, see that you're contributing to a piece of critical infrastructure to even at more at a contributor level, or even at a, like a maintainer level, someone who's an open source first company, they can see, you know, the projects that are depending on their On their, uh, see who's depending on their project per se.
Brandon: But as far as even contributors and people coming along, those are, those are the type of problems that we're looking to solve, uh, as far as surfacing that information in a meaningful ways. And even the, some of the, the companies that are doing open source today, they're like, we're doing open source. We got a lot of things out there.
Brandon: We don't know what to do with all this information that we have. And. We're looking to solve that as far as showing, giving them, like I said, actionable insights and things that they can actually take back to their stakeholders and say, Hey, you know, we're, we, we got a steady stream of [00:11:00] contributions. We know that these companies are kind of using our project and everything.
Brandon: So how can we better. Better reach out to them or, you know, find out who are, you know, who our key contributors are to see if you're, you know, open source first company and you, you know, you're building with open source contributors. Maybe you want to hire those people onto your team. Uh, we're not a hiring platform by any means, but, uh, you can actually see, you know, who those, uh, who those like.
Brandon: Um, called tastemakers, tastemakers and like influential people in your projects are as opposed to, you know, people who, uh, come by and submit a PR and then like you never see him again. So there's a different ways you can slice and dice that to see, uh, that type of information. And those are the type of things.
Brandon: That we want to, that we're working to surface in a more meaningful way, not just like the top level metrics, like everybody looks at stars and things like that or downloads. But, uh, if you look, you can definitely glean more information looking further into that, that data. So,
Justin: Awesome. Andrew, you want to take the next one?
Andrew: ~~Sure. ~~Switching gears [00:12:00] a little bit. Let's talk about some of the open source that you help maintain.
[00:12:03] Ad
Andrew: We'd like to thank our sponsor for the week, Mux. ~~Mux is a great tool. ~~Mux is a super cool platform that lets you enable video in your app easier than ever before.
Andrew: From experience, I know that integrating video at scale with all the bells and whistles that you might want is hard. You have to think about hosting. You have to think about video formats. You have to about streams. You have to think about changing quality for different network conditions. There's just no end to the improvements that you can make to a video hosting platform.
Andrew: That's where Mux comes in. Mux makes it super simple to do all the things I just said and so much more. They have APIs that allow you to upload, host, and stream video in any way that you want. This week I'd like to highlight their awesome player. The player comes,
Andrew: the player supports all those things I just listed and is super customizable.
Andrew: By just using a web component or even a react component, you can add nice full featured video players [00:13:00] to your apps in seconds.
Andrew: You can then customize those players with CSS and the themes that ~~they provide. Can, and the themes that they provide can match mo in the themes ~~they provide fit most situations.
Andrew: You can tell their expertise here 'cause they've thought of all the details. If you go through their docs, they've even thought about things like lazy loading the players and making sure the page doesn't shift while the players load. if you want to bring this video expertise into your stack, head over to mux.
Andrew: com to check them out. you tired of hearing these ads? Become a member on one of the various channels that we offer it. With that, you'll get the episodes a little bit earlier, and you won't have to hear any of these. But if you don't want to do that, you can also head over to shop. devtools. fm where you can pick up a hat, a shirt, maybe even an apron for this summer's cookout.
Andrew: With that, let's get back to the episode.
[00:13:41] NGRX: The Reactive Angular Library
Andrew: Uh, before we get into like your big personal project that you've been working on over the past few months, let's talk about NGRX. So what is NGRX and how did you find yourself to be the lead maintainer on it?
Brandon: yeah, so, um. NGRX is, I call it the OG and I'm one of the OGs on NGRX at [00:14:00] this point. But, uh, NGRX is a set of libraries for building reactive Angular applications.~~ Um,~~ Angular, mainly state management is, is pretty much our bread and butter there. Uh, the project was founded by Rob Ormald, who used to work at Google on the Angular team.
Brandon: Uh, and he started this project. Project separately while he was on the Angular team, but as a separate project. And because he kind of saw what was happening or how Angular was being built at the time and what kind of, what they kind of needed at that point in time. And, uh, so he started the project and then we were building something, me, my friend, Mike Ryan, uh, we're building something internally that was very similar to what NGRX was out in the open. We figured what we, um, the thing we built there, we can open source it. Uh, it was, uh, one of those things that kind of stay where we, where we left it. So, uh, but we ended up starting to contribute to injure X and, uh, long story short there. We, we, uh, We [00:15:00] started contributing, Rob saw what we were doing. He invited us to come on and start contributing more.
Brandon: And then we, we basically took over the project from there, uh, very early on and kind of shepherded, uh, it creating different libraries to build on top of the, the, in the, the base package, which was Njeric store, um, which was based on the Redux pattern. Um, so we took some of those, those features and continue to build injurex into, into what it is today.
Brandon: And the team has grown, has grown across time. And, uh, the project is still, uh, uh, being heavily maintained and even our usage is still growing to this day. So, uh, very, very proud of what injurex has, has become over the years. It's been, uh, I don't know. At least what is eight, maybe eight years at this point.
Brandon: I think that we've maintained the project. So definitely it's come a long way
Justin: That's a really good run. Um, so just sort of like digging into it a little bit more. Uh, I'm not super familiar with the project. Uh, so you'd [00:16:00] mentioned having a sort of like similar modeling as Redux. When I heard NGRX, I was thinking, uh, RxJS, like the observables, like library. Is there any relationship between those or is it like very much just like pattern sort of in a more Redux style?
Brandon: now. Yeah, they're, they're actually directly related. Uh, we depend on both. And depending on, yes, depending on your, your viewpoint, you may see this as a good thing, as a bad thing, but it is Redux and it is RxJS. And we mix those two things together. And a cohesive way to manage state in Angular, uh, using, and Of course, RxJS is built on top of observables, uh, which have been discussed, uh, you know, back and forth and even maybe even make it to the, into the browser at some point.
Brandon: But, uh, yeah, Nginx is a combination of those 2 things, um, to manage state. So, uh, we still, As far as the Redux pattern go, we still model things after events and use actions where we [00:17:00] dispatch to a store and combine and take that state. And we deliver that state to components using observables in Angular, or even more recently using like signals, uh, in Angular, but yeah, you still use that same like Redux pattern and we've built around some APIs on top of that to make it less boilerplate y, uh, which is a thing that people associate Redux with a lot, so, uh, That's how it's, and it's built on top of like Angular primitives.
Brandon: So like it's well integrated with how Angular works and each version gets a major release with the version of Angular and, uh, very, like I said, cohesive experience there that we wanted to want us to do with, uh, ngRx and, uh, we just released a new, uh, package there, uh, for ngRx and Angular signals. So, uh, we, this is a slightly different spin on what we've done before with the Redux pattern.
Brandon: So. The injurex signals package is another state management library, but it's based [00:18:00] around like the new world of angular today, where it's just mainly, mainly focused around signals. And then we, if you want to bring RxJS and you can, but you don't have to bring it in as opposed to injurex. Uh, store, which is, uh, it's, it just comes like package together, but it's more optional with, uh, with the injure signals package.
Brandon: So we just released that package as our first major, uh, stable release of that. Um, uh, team member and Marco standing Mirvich worked on that for about a year, at least, uh, before we actually released it as stable. And we just, like I said, we just released it as stable last week. And it's definitely got a good, a lot of good reception there.
Brandon: So, uh, It's, it's, like I said, it's different in how, like the model, the mental model of the two libraries work. Uh, but both of them are, at the end of the day, help you manage state, uh, more intentionally, uh, in, in Angular apps, uh, in general, and using signals.
Andrew: It seems like signals were mentioned and Angular [00:19:00] somehow added them like the next day, like they were in an official, official release so quickly. Uh, from your viewpoint, what, what style of state management do you like better? Or do they like both have different use cases for you?
Brandon: I think that they both have different use cases. Uh, Angular has gone a long time with, uh, using Angular and NJRCS have, you know, gone a long way with using RxJS as like the pattern for managing state. And what I think it has its merits as far as managing state of like events over time and things like that.
Brandon: But, uh, the learning curve was one big thing that, uh, that we were able to That Angular has always struggled with. And I think with the introduction of signals and having that as a first party option in the framework, I think that's probably the biggest thing. Angular has always used observables, but it never felt like it was like a first party.
Brandon: Like they fully integrated with them. It's like some, it was always like a 50 percent kind of thing. Uh, [00:20:00] and with signals, I think it simplifies a lot of what people need to do, what people can do without having to reach for RHS. But if they want to, to reach for that at some point, uh, then they can, because they can't, Uh, like rebuild the entire framework without RxJS in like a week or so.
Brandon: I mean, maybe they could, but, uh, they haven't, they haven't done it yet. But, uh, yeah, signals are, signals are practically everywhere, uh, at this point. So, uh, the fact that they were able to build those in and even if they make it to the browser too, that'd be one more thing, uh, that, That's not necessarily built in the Angular specific way, which I think, uh, ends up as a win for the platform, the web platform itself, which I'm excited about that too.
Justin: Yeah, that'd be really interesting. So. The, the difference between like observables and signals is like signals are sort of discrete, uh, like there is an event. Maybe you can listen or there's a state change. You like have a [00:21:00] signal that is sort of corresponding to some value. And then observables like change over time.
Justin: It's like you're adding things to a stream that you're listening to, um.
Brandon: Yeah. The, yeah, the outside of that's, yeah, that's the biggest difference between the two. There is something in RxJS where that behaves sort of like a signal, but, uh, just the characteristics of how you get data out of an observable versus a signal signals is more, uh, at the end of the day, a signal is just like a wrapper around a value.
Brandon: And then you can call some function to, or call some method to set that value and then call it as a function to read it just to synchronously. I think that's, that's the biggest thing. Signals are synchronous all the time. Like an observable can be synchronous or it can be asynchronous. And I think that's part of, you know, Why signals are just simpler in that way.
Brandon: You can just read them whenever. And the part when you bring in and start bringing in things like effects on signals, that's one thing you get into that async behavior [00:22:00] and some of the more nuanced things of it. But, um, yeah, signals, you can just read it. Whenever, and it'll just give you that value because it already, all those things happen synchronously.
Brandon: And we talked about like NGRX, uh, also it manages that same state in that way. Everything about managing state is NGRX is synchronous in the moment that you, but you get the value of it through an observable. So that's when you get into like the, the asynchronous parts of it. But, uh, yeah, it's, it simplifies how you, how you interact with data and how you. How you can read that data as far as rendering goes. Like when you get into like side effects and things like that, I think it's, that's when, uh, more things come into play. But, um, at a, at a fundamental level, they serve, they serve different purposes.
Justin: Make sense. Cool. Um, so maybe let's switch over and talk about, uh, another open source project that you're working on.
[00:22:56] Analog: The Next.js for Angular
Justin: Uh, so you have a project called Analog.
Brandon: One might say I'm addicted to [00:23:00] open source projects. No,
Brandon: that
Justin: at a good company for it.
Justin: I'm sure you have a really, really good score.
Brandon: Yes. Well, I, I check my score every now. I don't take my score every day, but, uh, but yes, I do. I do check the, to make sure that where we, where we are in the landscape of, of open source projects also.
Justin: do you, do you get a, do you get an email saying, Hey, you're, uh, your open source score has changed.
Brandon: Oscar score is going down, what are you doing? No, we haven't gotten to that. We, we don't wanna make people, uh, fidgety about their scores. We just want them to naturally, naturally do what they do. And, uh, and then the, the score will kind of reflect that over time. So, yeah.
Justin: Okay. Uh, would you be interested in just like telling us like what, uh, analog is sort of why you built it and, um, yeah, how it's used.
Brandon: Yeah. So I have many, many different pitches for what analog is, but the, the one that seems to resonate people with the most is, I call it the [00:24:00] next js, uh, for angular. Uh, and Next. js is, you know, a kind of a bucket term for a meta framework these days. Uh, so in like Vue, they have Nuxt and Svelte has SvelteKit.
Brandon: Um, Qwik has QwikCity. So there's these other ecosystems that have their own version of what a meta framework is. And Analog is that, is that version, is that meta framework for Angular. And, uh, for, I always, when I talk, people ask like, you know, what's a meta framework? I, I. Explain it in terms of, uh, it's more or less a set of features that I can see, like, commonly used across the board, like file system based routing, uh, SSR, server side rendering, static site generation, API routes.
Brandon: Uh, those are all things that are kind of built into a single cohesive package and, uh, and like I said, Angular is a framework itself. And so we're not building everything from rebuilding everything that Angular does from scratch. Uh, [00:25:00] we're building on top of some of the things that Angular does, uh, well, and then putting those together in a way that you can pick it up and build something like a full stack, a solution, or even a single page app, uh, using these features, uh, like I said, in a cohesive way and have some developer experience on top of that too.
Brandon: So, cause Angular already has. A lot of these pieces already, they're just, you have to assemble them. And the meta framework, I think, is it isn't, isn't a good spot because we can build on top of those things on top of those primitives provided by the framework and, uh, and like I said, build different use cases based on that.
Brandon: So.
Andrew: I'm kind of surprised nothing like this existed in the Angular ecosystem. Was there, like, any type of, like, static site Next. js like framework for you to use?
Brandon: Uh, no, not specifically, there was, there have been a couple of projects that have come along the way before analog, uh, was, so there was, uh, Angular [00:26:00] universal, which was another, uh, Angular universal was always more centered around server side rendering. So it was being able to run Angular in the, on the browser and on the server.
Brandon: Uh, so it was, it had been developed for a long time. I think, um, uh, his name escapes me now, but, Patrick Stapleton was one of the original authors, uh, him and, uh, Jeff Welpley and a few others, uh, started that project because they wanted something similar for that in Angular, like a server rendered Angular solution.
Brandon: And so that one was developed for a long time. It ended up turning into what today is Angular SSR. Uh, so they kind of revamped some of those pieces of that and they brought those first party into the, into the Angular framework and then, uh, There was another project, uh, called Scully, which was solely focused on static site generation and the JAMstack.
Brandon: Uh, so it would take your Angular application and render it to HTML files and you could ship those to a [00:27:00] CDN or those sort of things, but it didn't have There was no backend solution that was built into that. So, um, analog is probably one of the, the first, or I'll say the first one that kind of brings both of those two things together, like the, the front end and, uh, they call the, the BFF, the backend for front end, uh, style of.
Brandon: Framework there so that you can have more or less, most of what you need, uh, depending on your use case, uh, what you want to build out of the box where you have API there, you can, you know, have your server integrations there and have your, your file system based routing, um, as opposed to having to configure those routes manually and things like that.
Brandon: So, um, yeah, it was, I had looked at those projects before and definitely got some inspiration from those. But analog itself was meant to serve. And I think one that's has been missing kind of in the, in the ecosystem, Angular ecosystem for a while.
Justin: It's cool to see that you [00:28:00] used, uh, Vite for this, um, which is becoming increasingly a popular choice for building metaframeworks. I think mostly next is ironically actually the big outlier here. Um, So I'm not really well versed on the Angular build system, but I know that Angular CLI is used a lot of times when developing Angular projects and it has some sort of build tools rolled into it.
[00:28:25] Challenges and Solutions in Integrating Vite with Angular
Justin: So did you have any challenges, um, in integrating Vite? Uh, I mean, was it like helpful? You know, yeah, just curious about your, your experience and using Vite and Angular.
Brandon: Yeah. Uh, I jokingly say I built analog out of spite, uh, because it had, it was a lot of the things that I wanted to see in Angular that weren't, that weren't there yet, and I, Uh, like you mentioned about Vite, Vite has like basically taken every framework, meta framework, uh, like by the stranglehold [00:29:00] and, but not by the stranglehold in a bad way, but they have offered up like these APIs in a way that you can build these types of meta frameworks on top of it and like focus on the things that those frameworks want to do.
Brandon: And I thought that was really, and even the ecosystem that comes along with it. Uh, so I, I thought that was really valuable because when I started on analog itself, I was thinking of like webpack is stable. It's been around for a long time. Do I want to use that or do I want to use something else? And like, Vite was kind of in this like transition phase to where more people were starting to adopt it.
Brandon: So. Um, I wanted to use that. I wanted to use Vite as like the foundation for the, for the meta framework itself. Um, so that was kind of how I got started there. And from there it was, as you mentioned, Angular has its own build system. You know, they don't necessarily want you caring about how the build and config and all that works, which I think is, is good.
Brandon: Um, But they, they more [00:30:00] or less have a different stance on like giving you access to like the config or even back in the day when it was built on top of webpack, uh, giving you access to the config to do more custom things. And I wanted to kind of. Have a different take on that. So the biggest part of integrating with, with, um, Angular and V was like, how do I get a plugin started for V that will like connect Angular and V together?
Brandon: So, uh, that was, that was the initial thing was just how did I get the plugin off the ground, uh, so where the two things will work together, because I know like at fundamentally V heavily relies on single file compilation. Yeah. And Angular's compilation today is very much more global where it needs to look at all your files.
Brandon: And, uh, because it's built on top of the TypeScript compiler. Uh, so it has to operate like under those, those bit of constraints there, as opposed to, uh, like React and Vue, they have a [00:31:00] compiler that can, you can just, you know, transform a single file and just kind of pass it through. So, uh, which leans into what, how Vite works and, Everything like that.
Brandon: So kind of building those two things and getting those to work together, uh, was the initial step. Uh, but I knew that if I got the plugin working with how the V ecosystem was kind of continuing to grow and the tools around it, I knew that it was going to open up a lot of opportunities to build more things.
Brandon: On top of that. So, uh, yeah, I had to learn how somehow the Angular compiler works. I had to learn how somehow V works as far as plugins, uh, had to work around some of the things to, to get the two to kind of mesh well together, uh, to get to a place where it was like fast enough. Uh, cause, uh, Angular has Angular, Angular CLI did.
Brandon: Eventually start using Vite as a dev server, but they're still using like ES build. It's still using ES build on both sides, but they use Vite as a dev server and then ES build [00:32:00] to do the production build. So, but I wanted to like go all in, go all in on Vite because I feel like that was a good bet, like on the ecosystem, uh, to get something like that working.
Brandon: So that was how, how I kind of got started, uh, as far as the plugin goes. And then just seeing how. Every tool out there has some sort of V integration or things like that, that we could kind of build on top of, uh, I knew that was going to be big. So that's how, that's how, that's what kind of fueled the initial, the initial work after that.
Andrew: As Justin said, a lot of different meta framework authors are choosing Vite to power their meta frameworks. And I think along with that, they've built a bunch of tools to help make that easier. I was going through the docs and I saw both Nitro and Astro mentioned.
[00:32:46] Leveraging Nitro for Server-Side Capabilities
Andrew: So how do, how do you use that to get, uh, analog out the door?
Brandon: Yeah. So, um, yeah, once again, I knew that building a meta framework was going to be a lot of work, uh, and I was looking at different ways on [00:33:00] the server side of things to, for the, like the API side of it. So I was trying to figure out whether it was going to like hand build everything from scratch, as far as.
Brandon: Integrations with different, uh, servers, like of course, expresses like the well known, um, package out there that people have used forever. And then these are other ones like Hono or or NestJS, uh, for APIs and things like that. But I wanted something that was well integrated with it. And I was looking at.
Brandon: As I was kind of looking around for different packages, Nitro kind of jumped out at me because it's the same engine that Nuxt uses for its server engine. There's other metaframers have come along and started using Nitro also, uh, like Solid Start. And, um, there's, uh, TanStack Start, I believe, uh, is using Nitro now.
Brandon: But the biggest things for me for Nitro was that It had like a pluggable JavaScript API that I could, I could just bring into Vite as a plugin and build some things around that. And [00:34:00] it had the. Like the server side story and the deployment story out of the box. So, um, nitro is what we use for the API routes, uh, in analog, and it also powers like the deployment and service story.
Brandon: So that's why we were able to support like a lot of these different deployment targets, like right up front, because nitro has these different presets, you know, based on whether you want to deploy to Netlify or Vercel or, you know, cloud They have all these things out of the box that support these different targets or bun.
Brandon: If you want to use bun, like they have these different presets and everything. So that was one thing I was looking to, uh, do or looking to support without having to like rebuild the whole world again. Cause I knew that was going to take probably more time than I wanted to. So, uh, Nitro has definitely played a big part, just as much as I'll say a part of.
Brandon: Analog as Vite has because Vite handles the, you know, the plugins and bringing everything together, then Nitro kind of gives you that same [00:35:00] experience on the server side of things. So, uh, being able to use that and getting some support from the, the Nitro team, uh, Daniel Rowe and, uh, Pouya, uh, definitely helped, helped me in the early days of answering questions and, uh, seeing what we could do there to try to get it working together.
Brandon: Uh, cause it, it definitely works a little bit differently across different Uh, meta frameworks, but it's flexible enough to, to support those different use cases, which worked out for us.
Justin: I really love to see this kind of convergence. Um, I mean, using the, using Nitro, um, just trying, like, it's funny cause there's not really as much difference between these meta frameworks as like you would think. Um, they all kind of try to do similar things and there's like some pretty large maintenance burdens and developing these things from scratch.
Justin: So it is nice to see a lot of reuse here.
Brandon: Yeah, I definitely, I definitely saw that as, as a bonus being able to, because [00:36:00] then in, in the, in the same way I get to say, Hey, we support all these things out of the box, you know, already, uh, and it's because it was like the typical open source model, like we're standing on the shoulders of giants, not to be cliche, but Um, they have already invested a bunch of work in how Nitro works.
Brandon: And one of those things that they, one of those things that they had, like as a goal of Nitro was that it was, you know, agnostic of any other tool, uh, developer tool that you can use. So, so that you can drop it into to anywhere, if you know how to, you know, configure it, then it'll work out of the box to give you like a core set of features, um, that you can use.
Brandon: And I've been. The nitro plugin that's in analog actually will work just in a, in a vanilla V app also. So you could take the API routes and you could take the, the server side rendering and the deployment and drop that into like a regular, uh, V app where they use as [00:37:00] reactor solid or something else. And, uh, you could get it working there too.
Brandon: It's just, if, if you know where to like plug in the, like the entry points for like the server integration of it. Uh, it'll work in those environments too. And I did, I did that intentionally because I hadn't seen a Vite and a Nitro plugin out there that does that specifically. So I figured if we're going to get it working there, then we could still have an option to, to kind of spin that off if we needed to.
Justin: Um,
Andrew: It's so cool how like it took for cell like hiring the react team, having a whole next JS team iterating for eight years. And now we're at a place where I could sling together a few packages, write my own framework and have Andrew JS like probably pretty quickly.
Brandon: Yeah, for sure. They, they have invested a lot of, a lot of resources into next and, uh, I'm sure they have their reasons why, but. Uh, like I said, bet, I don't think betting on the, [00:38:00] what everybody's using as a web ecosystem is, is a bad bet. So, because, uh, like I said, the V team is, uh, has, they listened to a lot of the feed, they listened to the feedback that we have as far as what we need in meta frameworks.
Brandon: And there, even Vita is continuing to evolve just based on how they've grown and the needs that, uh, with these, uh, New solutions that have come out, like even supporting like rex of server components and, um, these new server function that everybody's like building in those sorts of things, all of those kind of playing to it.
Brandon: So, uh, yeah, we'll see. I think it's interesting to see how, how next, um, how, how that ends up going. Because like I said, everybody, they're kind of building an Island, I would say as far as their own build tooling goes, uh, and they may want to, you know, controls some of that, but. As far as the rest of if everybody else is able to like move along more quickly, then we'll see how that kind of shakes out in the end.
Justin: Yeah, I think some, in some ways they have just like [00:39:00] the weight of a lot of historical decisions and, you know, that has a lot of momentum and, you know, redoing a lot of that stuff would be hard, but at the same time it's nice because they also in some ways have been, you know, Tastemakers for the ecosystem.
Justin: And they're like, Oh, here are the kinds of features that we expect. And now we, as a community get to say, all right, they've done it the hard way. And now how can we do it?
Justin: It's slightly more interesting.
Brandon: It's like, thank you very, thank you very much. We will like, we will take those features also. So everybody can use them without, uh, necessarily having to deploy to a specific place or, but things like that. Yeah, like I said, I'm excited to see they, they've. They've proven that you can't rebuild Webpac in two years, ,because it's taken, uh, it took, web Webpac has been around for I don't know how long, and, uh, they're still, they're still at it.
Brandon: So with Turbo, turbo Pack and everything. So even other tools, like I just saw a, a couple days ago, like RS Pack [00:40:00] had a, their, their own version of, uh, next JS built on RS pac. So even there, like trying to chase and trying to build something quickly to. To kind of get into that space, uh, at least to show that it's possible to do, which I think is, which is pretty interesting to, to see.
Justin: So, um, when, when you're talking about like integration with angular and Nitro, so it's like nature is sort of helping with like server side rendering and. Static site generation and stuff. But like, were there any challenges just like getting Angular to work well with that? Um, I mean, sometimes there are like assumptions about, you know, what code should be included and maybe that's some of that's like internal to Angular and whatever else.
Justin: So it's like, did you, uh, yeah.
Justin: What were your hardest
Justin: challenges there?
Brandon: ~~Yeah. ~~
[00:40:46] Innovations in Angular Component Authoring
Brandon: I did have to wrestle with, uh, Angular some, and the, the good part about it was some of the parts in Angular have evolved to where I didn't have to wrestle as much, uh, one thing that has made a big difference with [00:41:00] Angular, uh, as far as analog is concerned is, is standalone components. Uh, there's a concept in Angular that's.
Brandon: Sort of legacy now called ng modules, uh, to where you had to put these components in an, in an ng module so that they could be aware of each other. And they kind of flipped that concept around and made it to where components, uh, pipes and directives can. Be standalone and that you just bring them into where you want to need, where you need them, uh, inside a component and make them available directly there.
Brandon: So that was one thing about it in the, the standalone components. Um, and we mentioned about Astro earlier is that was one of the things that allowed the Astro integration to come along because, uh, like I said, having to use. ng modules was just like another barrier of trying to use Angular components within Astro.
Brandon: So the first step was. Can we get Angular working within, within a V [00:42:00] plug in? So that was kind of, like I said, marrying those two like compilation ideas together. And then from there, it was, how can we see if this will integrate with other ecosystems? Cause that's a part of what analog is also is opening Angular up to other ecosystems, because. Angular has always been about, I call it the Angular way. Like you do things a certain way you stay with it, with Angular recommended tools. Uh, you keep the blinders on and then you, you can live in this sort of pseudo paradise, I would say. Um, but there are some places like Astro came along and they were like, Hey, you can bring your own UI framework, uh, components and things.
Brandon: It's like, okay, so that's cool. I would like to have some of that also, but, uh, some of the things in Angular didn't lend them, lend themselves to do that. And standalone components kind of opened up that door, uh, to be able to do that. So the V integration and [00:43:00] also Astro moving to V that was a big unlock.
Brandon: Also, they were using like snow pack back in the day. And they moved off of that because they saw where V was going and they saw that they could integrate with it. Um, so then moving to Vite, uh, and then the plugin, getting the plugin to work was a big challenge, just trying to get those two things working together.
Brandon: And then trying to integrate that in with Astro, uh, so that you can use Angular components within Astro projects, uh, was, was, uh, an early integration, I would say, because they've started providing those integrations pretty early in the life cycle of Astro. And trying to build a plugin that worked, you know, reasonably well, that you could use Angular components with, it wasn't like the next step of that.
Brandon: So that integration came out of. You know, these different ecosystems kind of evolving on, on, on their own and enabling some of these things. So, cause like I said, some of these things wouldn't be possible in analog if it wasn't possible in [00:44:00] Angular. So, um, Angular has changed along the, along the years to be able to be a little more flexible in that way, to let people like me, me and other people in the ecosystem build stuff on top of it.
Andrew: Um, so speaking of module formats and component formats, you guys have your own custom one that you integrated. So can you detail what SFCs are in the context of analog and why you built them into the framework?
Brandon: Yeah. So, um, As I mentioned before, Angular is opinionated in the way that it does things as far as how you build components. And, so components in Angular use TypeScript. Uh, use TypeScript, you know, top to bottom, uh, components use decorators, uh, but they're not like actual decorators. They're just like annotations on the component that they use for the compiler.
Brandon: And so to construct the Angular component, you have to go through this thing. You have to explain what a decorator is. You got to explain this decorator metadata, explain what selectors are and things like that. [00:45:00] And. With. Angular evolving in terms of, you know, becoming faster, integrating with signals, just becoming more lean with his APIs.
Brandon: I wanted to see what that would look like, uh, in the context of, okay, what if, what if we, you know, not. backward compatibility aside, you know, Angular's history aside, what if we like re imagine what an Angular component could look like, and that's what the analog SFC is, it was, um, looking at different frameworks, how angular works, uh, the minute you change something about how template and works in Angular, everybody says, Oh, it looks like react.
Brandon: And I was like, well, they don't, they don't even work the same as far as a rendering model goes. So the The SFC, it looks, it's more like a mix of, uh, Vue and Svelte as far as the syntax for authoring goes, but it works like an Angular component under the hood because we compile it, [00:46:00] we compile it in a way, or we convert it in a way that the Angular compiler knows how to turn it into JavaScript.
Brandon: Um, so it was, it, we, when we initially rolled it out, we called it the dot NG extension because it was, it felt like a natural fit there, but it did cause some friction in the, in the ecosystem. As far as people thought that it was an official Angular, uh, concept that it was coming to, we're coming to take away your class components.
Brandon: And then they were like, no, that's not what, that's not what it was for. So we ended up changing the, the extension to dot analog, uh, so that it'd just be a little more clear. Uh, delineation there. Um, but the idea is the same. It's still an experimental feature today. Uh, it was, it was, it's what I would like to see Angular component authoring, uh, change to, if they could change, if they could change without like breaking the entire ecosystem.
Brandon: So the SFCs. Uh, as opposed to having like [00:47:00] decorators and TypeScript classes and all that, uh, you have a script tag where you can define your TypeScript. You have a template tag where you put your HTML and a style tag where you put your CSS, uh, or SAS or whatever. And, and you still get all the benefits of Angular.
Brandon: You just don't have like the mental overhead of trying to construct these components, uh, in that particular way. Um, Yeah. And it, it got is, it's still being well received. People are still using the, even though I've shouted from the rooftops that it's experimental and everything, but, uh, people have definitely liked the format and, uh, will it ever make it into Angular?
Brandon: I don't know. My, my gut reaction is that it probably won't, uh, just because. Um, the format that they have today, I think there's going to continue to improve that and continue to improve that authoring format. And even if they do introduce something different, introduce another authoring syntax, I think it may look a [00:48:00] little slightly different.
Brandon: So, um, but this was, uh, something I think could live in analog, uh, pretty reasonably well and allow us to kind of play around with that and see what, what that, what that potential future could look like.
Andrew: Um,
[00:48:14] Future Directions for Angular and Front-End Frameworks
Andrew: so wrapping up here a little bit, uh, you've done a lot of work to like, kind of build out the vision of the Angular ecosystem that you want. But what, what is one thing that you still think the Angular ecosystem could improve?
Brandon: Uh, my, my wish is that, um, besides, of course, if you, if you give me one thing to ask from the Angular ecosystem is, is to reboot the component authoring and we've shown that that's possible with the analog SFCs, but if we're looking at anything else, um, I think. That Angular should be moving into more of a full stack, uh, framework.
Brandon: Analog is showing analog is, is already [00:49:00] there with how we've kind of built all these things together. And not saying they have to do that today, but I think they should move in that direction. And it was part of why I started analog in the first place. Uh, because Angular, like I said, today has. Lots of parts and pieces that you can build on your own.
Brandon: But if we're, I think the definition of a framework is kind of changing in that way. And people that want people want you to give them more tools and things, uh, closer together across client and server. So, um, it was like, what's old is new again, but I think for. Angular to continue to, you know, uh, have a stake, you know, in the web space, they need a solid story around like a full stack experience, uh, even, even outside of, outside of analog itself.
Brandon: Cause a lot of people are just going to choose Angular because it's maintained by Google. They, they, they have some sort of comfort in that. So, uh, [00:50:00] having that story being out of the box that people can use, I think is, is pretty compelling. So if there was something besides the component authoring, I think continuing down this path of kind of blending the client and server together is what I'd like to see continue to improve.
Justin: Maybe to build off of that, um, sort of as we wrap up here, we always like to ask a future facing question and you've got a lot of open source experience, specifically working in like state management and now sort of building out a meta framework for angular and. Sort of watching the, the trends over the last several years.
Justin: What do you think the, the future, uh, front end frameworks either, you know, from the meta framework angle or from the state angle or from both, like, what does this future look like for us? Or what would you like to see?
Brandon: Yeah. I would like to see more collaboration across the frameworks. I think like Vite is like a shining example of that, of. What happens when you have like a solid foundation that everybody can use and we can have these [00:51:00] discussions about features that we're building or features that we want without, Hey, my thing is better than yours or whatever.
Brandon: I mean, we're still going to have those conversations, but, uh, for me, the future is collaborating on those things. And I think building some sort of standards. Around these particular feature sets that we have in these different ecosystems, like even the features of meta frameworks. I mean, whether you want to use those or not, I think is a separate discussion, but, um, like there's still a story I think to be, to be told around how front end framers handle server functions.
Brandon: Cause everybody has like their different. They're different way where we use, you know, use server here. And then we use something else over here. They kind of mean the same thing. So I would like to see some convergence on this. Some of these ideas. And then, because that way we get to move to whatever the next thing is after that, uh, which is, um, like server components or server only [00:52:00] components.
Brandon: Those type of things, uh, are things that I would like to see us have more discussions around or even signals in the browser, I think is one that's kind of jumped out of nowhere. Uh, and gain a lot of traction. So if we get signals in the browser, then it's available to everyone, whether you're building a framework or not.
Brandon: So what are we going to do with that? Like the future is the future of front end frameworks. Everybody uses signal primitives and effects and everything. And then. Uh, if that is the case, then what, you know, how are we going to like solidify the story around, around those things that we don't have to build our own way or build separately now because they're just supported in the browser now.
Brandon: So, uh, those are some of the things I would like to see in the future, uh, front end frameworks. Um, from my, from my point of view, I'm a big, like. Application. I call it like application infrastructure person. Uh, uh, not so much less like CSS and things like that. Uh, because [00:53:00] the people who do that are amazing.
Brandon: So, but I like to see, you know, have these different tools and things that help us just ship things, uh, faster and, uh, and have a nicer developer experience around it also is a big thing for me.
Justin: Nice. That's really awesome. Yeah. I can't help, but to agree. Um, I think that, you know, shining examples, Vite and, and Nitro and, um, roll up ES build. There's a lot of these tools that, uh, are getting leveraged all over the place and I'm excited to see it. I think more solid primitives, uh, helps us all, you know, build better applications.
Justin: So, uh, yeah, I, I, I hope that that future does come to pass.
Andrew: I can already people hear the people on Twitter complaining that we have a new iteration of all our frameworks again, ~~but the, ~~
Brandon: Hey, they're going to do it, they're going to do it anyway, so we might as well, uh, get some of the things that will, that will outlast some of the frameworks while we're at it.
Andrew: True.
[00:53:56] Closing Thoughts and Reflections
Andrew: And with that, that wraps up our questions for this week. Thanks for coming on, Brandon. This was [00:54:00] a really fun dive into all things Angular, something we haven't done all that much on this podcast. So thanks for coming on.
Brandon: Yeah,
Brandon: sure. Thanks for
Brandon: having me.
Justin: Yeah, to echo that, thanks again, Brandon, uh, uh, you know, so funny that you, uh, are in the same town that I went in college in. So if I'm ever in the area, I'll hit you up, maybe we can grab a beer or something, but thanks for coming
Justin: on.
Brandon: please please do.
Justin: Cool. Sounds good.