Corbin: I had taught at a bootcamp. The students were amazing. Love the faculty. Faculty, amazing. Um, and then the business was like arguably swindling people in my opinion.
And I was like, that's not cool. Why are we doing that? Like my family is not super well off. And, and the money I've made in tech has been transformative to my life, to my family's life and I wanted to help provide that for other people as well.
And I was like, why do I need to be teaching at a bootcamp? Why can't I just, I. Be teaching out in the open and, and, and try to provide resources that'll help people.
Andrew: Hello, welcome to the Dev tools FM podcast. This is a podcast about developer tools and the people who make 'em. I'm Andrew, and this is my co-host, Justin.
Justin: Hey everyone, uh, really excited today to have Corbin Crutchley on the podcast. Uh, so Corbin is a principal, front end developer at GitHub Star and a teacher. Uh, so Corbin, really, really great to have you on. Uh, before we dive into the interview, would you like to tell our listeners a little bit more about yourself?
[00:01:02] Intro to Corbin
Corbin: sure. Uh, first of all, thank you so much for having me, Justin, Andrew. Uh, it means a lot. Uh, very cool. I, I'm a, like you said, GitHub star, uh, principal engineer. That's the boring stuff. I collect retro video games. I have something like 40 video game consoles, um, from like every era. See, I, I always get that face from, from everyone.
They're always like, whoa, you have, okay. Uh, I'm a music fanatic. Uh, like I, I think I have like 10,000 songs downloaded and 10,000 more on Spotify. Um, and, uh, I like to teach people, it's like a passion of mine. I'm writing a book about it.
Justin: just with something to interject here. Also, I just love your energy, like I love your energy since you first got on the call, it's just like, it's been very uplifting, so I am super excited
Corbin: I appreciate that. Thank you.
Andrew: yeah, you gotta be careful with that music addiction. It'll move to vinyl and start taking up all the space in your house. I know, I know From
personal
experience
Corbin: I, I have like shelves of it and it's not even started and I'm like, I, this isn't even active. What am I doing? Like it's dangerous.
Andrew: Okay. So I, I think a good way to start this episode is, uh, introducing how you and I met. 'cause I think it's a good primer for like, the type of work that you do. So how, how did we meet?
Corbin: Yeah. Uh, so we, uh, well, I, I joined on a project, uh, called Plop, um, which was actually is, was it plop? Did I start? Uh, it's so intermingled, so I apologize if I get my timelines a little wrong here. Um, but I started working on an open source project called plop, um, which was a c l I like, like tool generator.
And it had some dependency on like, P N G J S or something like that. And one thing led to another, and now I'm also like working and, and, and helping maintain a project called Node Vibrant, which is like a color extraction library for a different project that I have. Um, so already you're starting to see a little bit of a pattern of, like, I, I, I do a lot of projects and I like, love open source, and I try to like, um, I, I jokingly say that I am like a salmon.
I, I love upstream. Ha ha. And, um, that's a terrible joke. Uh, but I, uh, along the same lines, I was updating dependencies. And I noticed that, uh, Jimp JavaScript image manipulation program, uh, didn't have TypeScript typings at the time. So I thought, how hard could that be? I, you know, I've written Typescripts before and I started working on them and, um, Andrew, a k a hipster smoothie, uh, on GitHub and other socials, um, was the maintainer of the project and was reviewing my pull requests and I managed to break prod like five times.
It was awesome. And he was super patient, which I deeply appreciate. Uh, and eventually we got there with some of the most convoluted types, script types I've ever written. It was great.
Andrew: Yeah. And now Corbin helps maintain the jimp repo. So it was a good story in the end. Uh, I, I think that experience speaks to a lot of the conversations that we've had in the past where, uh, I was actually thinking of you during a few of them, uh, where adding TypeScript types to a JavaScript library through d t s files is like, A world of pain, especially when the maintainer wrote the most generic plugin, a p i, that you could possibly write.
So I, I applaud your, your fortitude with those issues. For sure.
Corbin: I, I, I remember like freaking, 'cause I remember like, like when I started working on the TypeScript typings and like, when, when we were like, okay, cool, we're we're good to go. We're gonna push 'em. I was like, on a lightweight vacation and like, I just distinctly remember freaking out being like, I've just ruined my reputation.
Like by destroying this super popular, we got like 30 GitHub issues in like the span of like five minutes it felt like. So I'm like melting, like, oh geez, here we go. I've upset someone dearly. You know, like someone that, that, that's great. And, and, and, you know, super supportive and, uh, so, so I really, really do appreciate your, your patience and your support through all that.
It, it was quite an ordeal that I put us through.
Justin: This is a fun gathering. So we've all three met through open source projects,
Andrew: Yeah,
Justin: power of open source
Corbin: how did you and, uh, andrew meet justin.
Justin: auto. so yeah, when Andrew was uh, into it, he was working on the auto release tool and I tried to write a crappier version of it myself and then my coworker Orta Therox was like looking around and he found auto first and he's like, Hey, maybe this thing would work.
And we sort of got involved and yeah, started just working on that and chatting with Andrew. And then, you know, one thing led to another and here are we yeah.
Corbin: I was just gonna say, it's so cool, like how. Everyone in open source seems to be relatively like decent. I mean, I mean, I think that's kind of a prerequisite for the role, right? Like in order to be like an open source maintainer, you have to be able to sift through a lot of issues.
We call them, you know, like, like literally what we call them. But then also there are issues amongst the issues. Um, so it's definitely cool to see how the open source community is able to like, come together and just have a conversation and, and connect and, I don't know, it's just such a cool environment.
Justin: Yeah, I think a fun thing about open source is that the incentive structures are so different than when we're working in like production level code, right? So when you're working in a company is like you gotta make money. So you gotta work on features that are like, you know, giving users like this specific value that they're paying for or whatever.
And often an open source. It's like there is some of that for sure. 'cause people like start creating issues and like, hey, this thing is broken, or I don't want you to do this thing. And you know, there is some. Service in that aspect, but like sometimes it's just like, this is what I wanna do today and you just like work on it.
Just 'cause you can.
Corbin: Yeah, it's, uh, so many of my open source projects are like, why did you do that? I liked it.
[00:06:35] Ad
we'd like to thank Ray cast for sponsoring our podcast. raycast is an app format. That's like spotlight, but with superpowers. Besides just quickly opening files, URLs, or apps, and provides clipboard history, window management, a schedule overview and much more. It also has a super clean react based API for creating extensions. And an extension store to distribute your own custom extensions
one extension I've really been enjoying lately is the Spotify extension, right at your fingertips. You can control Spotify without even leaving the app. You're in. One of the cool things about Ray cast extensions is they just don't extend the command palette. You can also create extensions that live as menu bar apps also. So the Spotify app also actually lives in my menu bar. So I don't even have to open raycast, has to use it.
You should also check out raycast pro with pro you can take advantage of raycast AI to do a whole bunch of cool things throughout your computer. You can summarize text in any app or translate text on the fly.
It also gives you access to their cloud sync, which helps you keep all your Ray cast setting sync across all your computers.
To learn more. You can visit Ray cast.com or you go listen to episode 38, where we interview the CEO Thomas about the product.
Would you like to advertise with dev tools, FM, just like this. If so head over to dev tools, FM slash sponsor to get started.
Want to skip the ads and get straight to the content, become a paid subscriber. And one of the platforms where we support it.
Andrew: Yeah. So speaking of your other open source projects, like what other things do you maintain because, uh, you're definitely one of the personalities that, like once you notice the avatar in the name, you're like, oh, I've seen that guy on a bunch of issues.
Corbin: one of my favorite, the super tangent, before I answer the question itself, one of my favorite interactions in person. I was at a, a meetup here in Sacramento and uh, after I had given my talk, someone came up to me and was like, Haven't I seen you somewhere? And they were like, looking through their phone and they were like, oh, yeah.
And they like showed me a GitHub issue where I had like, made a couple of comments and I was the author of it or something. I'm like, that's, that's me I didn't think this would happen. But that's me. It's uh, it's surreal to, to be recognized that way. Um, yeah. So iop, I maintain. Um, a new project called House Form, um, only because I'm, I happen to be staring at that on my second wander.
Um, I maintain a project called, uh, I mean maintain jimp now, uh, maintain, uh, node vibrant, really poorly. Uh, I maintain plop a lot better. Um, I maintain, uh, few odd and end projects, c l i testing library, um, uh, T S U till whatever the name I called it Helpers, T s u, till Helpers. Um, but the big one that I maintain is, uh, uh, an open source publishing platform called Unicorn Utterances.
Um, and it's like on the surface it's just a blog. Um, but we've been growing it a lot lately. It's where I'm gonna publish my book for free. Um, we have a Discord community with like 1300 people, which is a decent number. Um, so it's a, a pretty cool environment to be able to, to help maintain.
[00:09:27] Unicorn Utterances
Andrew: Uh, yeah. Let's, uh, before we jump into the projects a little bit, uh, what, like what is the purview of unicorn utterances? Like, what, what's the goal with that
platform?
Corbin: Yeah. Uh, so truthfully, the, the, the way that I started it was that I didn't know there were other things like it. Um, and uh, my background is that I had taught at a bootcamp, a coding bootcamp, and I love the students. The students were amazing. Love the faculty. Faculty, amazing. Um, and then the business was like arguably swindling people in my opinion.
And I was like, that's not cool. Why are we doing that? Like, the people were just trying to learn to, to like, you know, like my family is not super well off. And, and the money I've made in tech has been transformative to my life, to my family's life. Um, you know, uh, and I wanted to help provide that for other people as well.
And I was like, why do I need to be teaching at a bootcamp? Why can't I just, I. Be teaching out in the open and, and, and try to provide resources that'll help people. Um, so I started writing a blog and it turned into a community and it turned into to what's gonna be a massive rewrite here, wrapping up soon.
Um, and that turned into a book. And, you know, so we have like 30 people that are contributing to the project. Um, a lot of people that are in our Discord chat chatting daily, and the goal is to, to help teach people to, to ideally maybe even have our own bootcamp in the near future. Um, so
Justin: That's so awesome. That's so awesome.
Um, it is interesting that like bootcamps or, or like teaching these, these very, uh, positive for society, things like teaching can become somewhat exploitive. You know, it's just like when people like know, understand, it's like, oh wait, there's this huge demand for this.
And then it like, turns into like these, you know, like puppy mill style coding factories where they're just like pumping out like folks who are barely able to sort of, you know, are barely equipped, I guess, to really survive out in the industry. And, uh, So it's, it's, it's refreshing to, to see folks approaching it with more empathy for sure.
Corbin: And, and I think that that's the part that really bothered me. It's not necessarily that like, you know, if, if you're coming out of a bootcamp, super junior, it's like that. That's unfortunate, but at least like, you know, so long as there's not a huge expenditure or whatever, you know, like you can keep learning, right?
The problem that I had is that this bootcamp in particular was telling people, Hey, come join our bootcamp and we promise you a job. You will have a job in the job market. And, and I know students that were taking out loans to do these classes and putting their livelihoods on the risk because what they see is they see a path out from the, the, the, you know, situations they're in.
Whether that's financial issues, whether that's, you know, um, ex-convicts, whether, you know, and, and these are wonderful people that are wanting to do better for themselves, for their families. And here's this organization that's kind of like, oh yeah, of course we have work lined up for you except for 90% of you.
You know what I mean? Like, that's the unfortunate reality is that like, You know, there, there is a challenging environment getting into the industry, and that's not to be taken lightly. And you need to communicate that upfront if you're gonna be taking people's money to educate them,
Justin: So how does the community aspect help with that? Uh, so, uh, you've got, you know, a blog and content that you've written there. Um, is there, are you trying to sort of funnel people into like discord or into places where they can like, help, you know, engage with people and like answer questions and stuff?
'cause a lot of self-learning journeys, the really hard part is like, who do I ask when I get stuck?
Corbin: right? Yeah. So, so we predominantly, uh, co-locate on Discord. Um, I try to host office hours, although admittedly like working on my book, that's been kind of dropping a little bit. Um, I can't guarantee the timeline of this happening, but here's like the, the broad goal of like what I want to do with my book and what I hope can, can happen.
Um, I would love for my book to. Like help people learn, of course, on their own, whether they join our discord or not. But I also want to, and this is like something I haven't really talked about publicly before, so sneak peek, um, but I want to potentially start like a, like a bootcamp of sorts where like every week we get together and we, we like walk through one of the chapters of the book.
It'll be like a eight to 12 week program where we just complete the book in, in one go. And then at the end of it, we want to offer the opportunity, Hey, do you want to teach the next cohort? And if you do we'll, we'll, we will add you to our partner program. We'll help promote you as much as we can. We'll, you know, we'll you, we have a LinkedIn that we can help you like, you know, grow a network as well.
Um, but the idea is that I would love for us to turn into. Um, kind of what that, that that bootcamp had going, but in a free, totally volunteer based manner that, that was like trying to remove as much of the, uh, bad as possible, so to speak. So that's our, that's our like, big thousand foot goal. So just taking the small steps to try to accomplish that and see how, how it works out.
Andrew: That's super cool. yeah, nice goal to have, uh, and that it's free is awesome too.
Corbin: Yeah.
Andrew: There's so many paid for resources. Like when I, people ask me what to learn, I kind of feel bad sometimes sending along like a one to $300 course on how to learn this particular technology, even if I think it's really good.
It's like, that's such a, it's a lot of money for someone who doesn't
have it.
Corbin: Right. And, and I think that that's a big part of it is that like, I, I learned from, from Kenzie dog's, uh, testing JavaScript course. It's a fantastic course. I, I tried to get my company, in fact, didn't just try, I got my company to pay for a bunch of licenses, you know what I mean? Um, I'm not against paying resources by any means, but I felt it important for me with my background of like, Hey, I, I didn't have any money to, to put into this.
I didn't, you know, I, there was times in my life that I had to pick between the cereal and the milk, you know, like I didn't have a choice there. So I wanted to try to help provide a, a platform to let people that were passionate about this but didn't know where to go, a, a journey that they could learn in, in a fairly linear manner.
Um, and apply those skills in the real world.
[00:15:19] OSS Projects
Andrew: Awesome. So, uh, let's transition back to like, uh, the, the libraries that you maintain. Uh, one that I think is really cool and uh, ties into what you just said is testing library, uh, testing library for React is, uh, it's become the go-to method of testing things. You test like a user, but you actually made, uh, a library to test CLI in the same manner.
So could you walk us through what, what
that was
like?
Corbin: Yeah, so, uh, I was working on plop, which is a C L I tool, and we had released. It was one of the two point something releases and it just happened to break everything. Like, like literally would not start on Linux, wouldn't start on windows. Just, just failed. And I think it ended up being something silly. It was like line in coatings and I was like, this is so silly.
Right? Like, like why can't. Why can't I just spin up a C l I run that darn thing and then tell me if it works or not. Right. Hey, wait a minute. You know what I mean? Like I had this moment of like, what if we just do that? Like what? Like let's do it. So I was looking around and I found some options. Here's some options there.
And I was like, honestly, I'm just gonna like procdot exec and see how that works out for me. And one thing led to another and I was like, you know, I really want to be able to query what is shown in the C l I and I, I only know of one a p i that I've been a fan of for a long time. Uh, so I just kind of ran with it.
Um, I figured there was enough of the a p i that it was well enough to find that that applied, um, and just kept tacking on it.
Andrew: Yeah, that's, that's super cool. I feel like a lot of people think like, oh, how could people make tools? How do you like have this grand vision for a thing? What we found through talking to a lot of people is it just starts with playing around with something. It might not be the first version that hits either.
Like, we just talked to the tamagui guy and he's like, this is my fourth iteration of this same concept. So like a, a lot of open source battles and APIs and learnings are hard fought and you have to like do the time to get to the point where it's like, oh, I actually, I have something that's like cool and like
unique.
Corbin: Mm-hmm. And it's funny you mentioned that like there, there's that like shifting goal of like the a p i, right? Like until you figure out what you want to go for, you kind of just gotta keep kicking the ball in towards the general direction. Right? Um, especially with c L I testing library, you know, the, the original testing APIs are meant for the dom.
So it's wait for something to be shown in the dom. So there's a bit of like, how do I convert that to be like, I, there's tools that I need that are not available, there's tools that I don't need that are available. What do I and don't I make available? Um, so I actually went through probably like five or six major or s changes before I hit like a a 0.1 alpha.
Um, and I think that if you're in that stage of like a p i development, the one piece of advice that I would give is make a choice. Like, as silly as that sounds like sometimes, like we can get stuck in our heads trying to make a decision and like really mull it over forever and ever and ever. But sometimes if you just stick to one, see how it goes and shift based off of that experience, it, it can be quite transformative.
Justin: Yeah, absolutely. There's, there's a lot of momentum and especially when it's open source and especially when you're like trying to scratch an itch. There's a lot of momentum behind these things. And if you get stuck in analysis paralysis or get bogged down on, like, trying to come up with the perfect a p i, it's a great way to kill the project.
And they're like, burn yourself out on it and you're like, oh, I don't want to, I don't wanna work on this anymore.
[00:18:40] HouseForm => TanstackForm
Andrew: So going down the list, we're going to the, you're probably the, your biggest open source personal library to date. Uh, you mentioned it earlier, it's called House form. It's another react form library. So why did you choose to go down this route?
Corbin: Uh, yeah. Well, why, why would you go down the route that everyone has walked down at least a hundred times? I asked myself that a lot, to be fair. Um, so I, I, I had my company work on a spike. Um, I went to one of my juniors and I was like, Hey, we need forms. Our forms are in one of our applications, atrocious, right?
Like, they're, they're just not acceptable. We've gotta change it and we've gotta change it. Today, the two that I've heard of, Uh, is Formic the one that I used when I was at Hilton? Uh, and then the other one was, uh, like react hook form, right? And, and like, not that I'd used it, but I'd like heard of it, you know, have fun.
Welcome to Spike Land. Uh, would you like a spike, please? I don't know. You know. Um, and he came back and he had this amazing presentation. It was like, this one's controlled, this one's uncontrolled. There's, there's final forms, there's this, and it like, just laid it all out on the table and I'm like, this is super, super good work.
Shout out Nick. Um, and I remember like seeing all of his research and his key takeaway was like, These are good tools, but there's none that stand out to me that solve our exact needs. Like we have a really, really custom UI that has really, really weird validation requirements from the business. And if we want to, and it has to support React native, so it has to be headless and support, like custom UIs and all this other stuff.
And if we want to go that route, we're gonna have to tweak any of these tools that we use. Um, uh, in addition, at the time, formic was in a kind of questionable maintenance status, um, which I had written a blog post about. And, and again, I. We don't like, like in open source, you don't owe anyone anything, right?
So this is not like a criticism of Jared, not a criticism of, of anyone that, that's working on Formic. Um, and they've brought it back. So this, this criticism is invalid. Um, and sometime in February I was at staying with my dad, who, uh, had some health issues and, uh, he's doing fine, but, but he, uh, he just had to keep going to work for, for like a week.
And I was like at his house, nothing to do in Virginia. And I'm like, why don't I just see how far I can get on this problem? Like, like I have an a p i in mind that I want to, to explore that I think would work really well. And then boom, next thing I know I have build version one and documentation and a website and I kind of went a little, uh, uh, wild on it.
Justin: That's
awesome though.
Andrew: that happens. I have many a project where I go wild for 95% of it and then, uh, usually don't ship it. So it's good that you shipped it in the end.
Corbin: Yeah, the bad news is I'm killing it.
Andrew: Oh, no.
Justin: tell
us more.
Corbin: So I, I like house form. And then Tanner Lindsley decides to drop a, a like GitHub guest of the a p i that he's gonna be using to build tans stack form. And it's better, it's, it's amazing. It's better. Uh, so I started talking with him. We, we went to a hackathon together. And I was like talking with him. I'm like, Hey, you know, like I, we talked a little bit online about this.
Uh, I would love to see this. And you know, like I've been working on my own and you know, we got to talking. And it was funny because Tanner's awesome and in the span of a 30 minute conversation, it started from like, I don't know, you know, like your a p I has has pros and cons, but I'm not sure here's why.
You know, safety fault, super justified explanation, right? And by the end of the 30 minute conversation when we're paraprogramming, he's like, all right, you convinced me we're gonna change the a p i to what you're working on. Um, so I'm actually working on Tanstack forms. Um, it's a little slow in the running because I'm trying to wrap up my book.
Um, but once I have a little bit more time, I'm gonna really like, like hit the ground running and make sure that there's like, like migration guides. There's like, you know, um, a similar enough a p i that you can kind of convert from one to the other. Um, so I'm trying my best to, to work with, uh, Tanner to create Tan stack forms.
To be What House form? Couldn't be.
Justin: Well, that's really exciting.
Corbin: Yeah,
Andrew: yeah, that's, that's another great facet of open source is prior art. Just like I, it's hard to explain and like justify to someone what open source is when they're not a developer. They're like, wait, so people just put it online and you can go read it? And it's like, it's such a simple concept, but it's, it's fueled so much innovation.
Just like being able to go like, oh, I like this thing. How does it work? Break it open. And then you have the new shiny thing that, uh, improves on It makes it modern, but like those past ideas carry and it's really cool to see that your just like form library that you've created on your dad's couch while you were doing nothing is now probably gonna contribute to one of the bigger forms
libraries that'll
be out once, once it's been released.
Corbin: I know, like I, I thought about that for, so like, and, and that was such a weird hackathon because like you, you had to be invited to it. And, and here I am and, and I'm invited to it because of house form. And here I am, I'm like, I built this thing in like five days. What are you all doing? Why am I here? And you know, it's like I got to talk to Mark Erickson, maintainer of Redux, and I got a, like, I, I was just like, what am I, why am I in these rooms?
I don't belong here. You know what I mean? Like, like these are some of like the best engineers in, in the industry and I'm able to talk to them. That feels wrong,
Justin: Well, you definitely did belong,
Corbin: I appreciate that.
[00:24:03] Being a (GitHub) Sta
Andrew: Yeah, I think, I think, we've had a similar experience on this podcast sometimes where we're like, oh my God. Like starstruck a little bit.
So speaking of stars, you just became a GitHub star. What is a GitHub star and like,
what does that actually entail?
Corbin: Yeah. Uh, I always struggle to answer this question because like, you know, I, I, I mentioned that I don't feel like I belong in a lot of these rooms. Uh, and the Stars program is definitely one of those areas where it's like, oh man, what a, what an all-star cast, haha the pun aren't gonna stop, you know? Um, so the GitHub source program is a GitHub calls, like, like uses the terms like, like, uh, uh, community leaders and, uh, influential engineers or, or whatever exact terminology they use.
Um, and the idea is that, uh, if you contribute to like enough open source projects, uh, big enough open source projects, and you remain committed and you're able to, to help, uh, lead a community, you know, big or small, um, you're a GitHub star. Um, there's 88 of us, I think, like, like there were just two of us, including myself, that were added.
and, uh, yeah, we, uh, in, in, in practical terms, we, uh, Hang out in a, a community chat and we, we act, it's pretty quiet actually. We, we chat about a couple things here and there. Um, but, uh, other than that, it's a good way to, you know, get feedback, um, from the people who are, are pretty active on gi uh, GitHub and, uh, hopefully make the platform better.
[00:25:30] Deciding to Write a Book
Justin: That's really awesome. Um, I, I guess, you know, thinking of like influential people, uh, there's not a whole lot of people who in their life write books and I, I'm curious to hear a little bit more about yours, about like, you know, just more details about it, but sort of before that I want to hear about like how you thought that like, oh yes, I wanna write a book.
Or like, oh yes, this is like, an obvious sort of thing to do, or, or whatever your thought process was for getting there.
Corbin: So I started with Angular, and I remember my boss at the time was super supportive of me. 'cause I, I, so he had found me through my open source projects and he saw that I was in the city and he was like, Corbin, come on in. You know, I was like a 17 year old. And he was like, come into the office and, and like, let's, let's interview.
And I remember, I, I had never done Angular before. Never really done web dev before. So I, I followed a tutorial and I showed him the tutorial and I'm like, look, I, I, I followed it and, and I don't know what I'm doing. Uh, please hire me. And he did. I don't know why he hired me, but he did. And, uh, he, he kind of threw like a month at me where I was like, go learn as much as you can.
Have fun. Uh, feel free to expense if, if it's within a reasonable cost measure and just learn as much as you humanly can absorb and then go from there. And I did, and I think that really trained how I learned, like software engineering is this idea of like, Okay. I have to absorb it like rapidly. I have to absorb it, you know, like, like the industry moves quickly, especially in web dev.
Like, we have to get on top of this. And I remember I was starting to look for another job after a couple years at that company, and I'd only done Angular before and I was like, I hear this React thing is popping off. I hear about vue, I, you know, I hear about these other technologies. What are they? So I start learning them and I'm like, yo, these aren't that different.
Like, like they, they have differences, don't get me wrong, especially nowadays, but like, you know, back when it was class components for React, you know, you, you could kinda learn things here and there and get by. Um, especially from Angular, which also used classes. So I started keeping a little notebook, um, in GitHub gist, actually a private GitHub gist of a comparison table of which syntax did what in each framework.
And I don't know, it had like 30, maybe 35 rows by the end of it. And I had managed to get a job at Hilton doing React after that. And, you know, Built a few projects using vue just for fun. And as I left that bootcamp from the, from, from earlier story, I started writing and my first blog post was about like angular internals and, and how to read the source code and how it works.
And then I started writing a little bit about React as I got more involved with this. And next thing I knew, I'm like, I've written the length of a book. Like, I've written like, like, I think now it's like 150,000 words. And I'm like, why don't I just write the, like, I, I've always been wanting this guide that would help you learn one framework from another framework's purview.
Why not write that? Like, that doesn't exist anywhere. Like nowadays we have, um, component party, which is awesome. Shout out component party, but that's not really a step-by-step guide, you know what I mean? Like, that doesn't teach the fundamentals, that doesn't teach the, the concepts. It's just, boom, there's a syntax.
So I just figured why not? Let's see how far we can get. Now I'm getting ready to publish the thing.
Justin: That's really awesome. Um, so like, tell us a little bit more about the structure of this. So you're, you're sort of guiding, uh, readers through not just comparisons of frameworks, but like how to build components and things with different frameworks and how to map their mental model from one framework to the other.
So, uh, like which frameworks are you covering generally? Curious about that. And also do you have like specific parts of the book that are just like, oh, well before we start talking about frameworks, let's talking about like the component model or something and like what these things are, or do you, do you really just try to focus on the aspect of like, here's this framework that you may know and here's the mental model and then here's how we convert it
to like this other framework
Corbin: yeah. So
great questions. Um, Let me give like a super quick pitch for the book, answer the first common question that I get usually, and then kind of lead it into what we're talking about. So, um, the, the book that I'm writing is called the Framework Field Guide. It's actually a trilogy of books because I don't like myself very much.
Uh, and the trilogy teaches React, angular, and View all at once. Um, some people ask the question like, okay, well does one book teach one and then the next book, no, no, no. We teach React, angular, Vue in the first book, and then we teach the ecosystem like next js and, uh, Redux and you know, like any of the, the, the community tools in the second book.
And then in the third book, I'm, I'm rewriting the frameworks from Scratch and teaching you how to do it. Um, so that's gonna be the trilogy. The first book is, is the one that, that I'm talking about almost launching. Um, so I, I still have quite a bit of work ahead of me. Um, and to your point, The, the first book is really meant to be, you've maybe done a for loop in JavaScript.
You've maybe done an if statement in JavaScript, and you've done some H T M L and c s s. And even if you haven't done those things, I provide resources that are in the prerequisites chapter that explain, you know, what, what it is that you need to read beforehand. Um, and from that point, I start talking about the component model.
Um, I introduce how to render, you know, input, outputs. Um, but like, you know, I try to focus on the, the conceptual aspect of it rather than the syntax. And I think that that's the only way that my book was able to work is that, like the three have very different syntax and some different underlying methods.
But the fun fundamental, like nuances are fairly similar, right? Like, if you're dealing like one of my chapters, uh, uh, you may know lifecycle methods, right? This idea that like when a component renders so on and so forth. But that's not really what lifecycle methods are for. Lifecycle methods are for side effects, right?
So let's not talk about lifecycle methods. In fact, I barely even use the word lifecycle methods throughout the whole book. Instead, I talk about side effects and side effect manipulation and what a side effect is outside of the concept of a framework. And then I bring it back into the framework. And here's how you add an event listener manually.
Here's why you would want to do that. Here's how you do cleanup. Here's what happens if you don't do cleanup. Here's how it'll actually impact your production code. Now, build your own thing yourself. Um, and that's the type of fundamental, like, like concept building that I want to focus on in these books.
Andrew: So as you're going, are you like actually building with each framework?
Corbin: Yeah. Yeah. So at the end of, so, so I have code samples, right? That, that, that are in each of the three frameworks that show you how to build whatever I'm talking about. And then at the end of each chapter, I have a challenge that'll recap what you've learned in that chapter and all the previous chapters, uh, and will let you build a practical application, the same application throughout all chapters.
And then you'll have something working at the end. Um, the, the challenge there is of course, how do you keep one application going through the whole thing, which has been fun, uh, to explore. Uh, but I've managed to do it somehow.
[00:32:43] Framework and Egg Problem
Andrew: I, I feel like the challenge would also be, since the second chapter you said is meta frameworks. If you start from a place of no meta frameworks, like getting react set up and like rendering on a webpage, it's not the simplest thing. And so you kind of have this like weird chicken and egg problem where it's like, I wanna use the batteries included thing that just gets me going, but I, I don't know what I'm doing.
So like how how do you, how do you contend with that?
Corbin: So I really struggled with that. Um, the other, the other challenging one is how do I deal with backend, right? Like, if I'm not introducing backend tools, how do I deal with like the fetch a p I do I use someone else's a p i that might break and then overload their, you know, like, that's not cool. Um, so I've made two kind of controversial decisions in this book, um, which is how you pitch a book for sure, right?
You talk about all the bad things about it. Uh, the first one is that I don't introduce build tooling at all. I don't talk about v don't talk about Webpack, don't talk about just none of it. Um, instead I'm deferring to web IDEs. Um, so, you know, like, like here's the syntax. Get it up and running. The build tooling will come in the second book, right?
Um, which is a weird decision. That's a chicken and egg problem, just like you're talking about. But I thought it made more sense to start with the, the concepts rather than here's a hundred pages on how to set Webpack, uh, which is, I could do that, but I don't know that you'd wanna read that and get started with it, you know?
Um, the second controversial decision is that I don't use fetch or X H R or any kind of network request anywhere in the book. At least the first book, second book will be just littered, which is absolutely like every chapter everywhere. Um, but I wanted to make sure that that. You unders, not, not you, but the, the reader understood that you can build an application without a backend.
Now you're, you're limited, of course. Right. But if you're just trying to learn and you want to understand the fundamentals, the, the best way to do that is to look at it in its entirety, but on its own, in my opinion. You know, you get the whole picture without kind of muddying the water of where the, the lines are and, and what is what.
Um, so I, I really tried to focus just on the frameworks themselves as opposed to the, the holistic web development picture.
Justin: That's really cool. I mean, I, I think this is a good choice because, um, there is a lot of distraction in the ecosystems about just getting set up. Uh, so if you're trying to learn a framework and you're trying to learn meta frameworks and you're trying to learn, build tools and you're trying to learn all these things, it can be, I.
Really paralyzing. And so, uh, sort of a follow up question just about the format of the book. So I, I mean, I'm assuming that this has to be sort of digital as, as a, a medium, or does it question mark?
Corbin: So, uh, it is digital and uh, I mentioned earlier it's free. You don't have to sign in. You don't have to log in. In fact, we don't have a login system. So I don't know, like our most, our most tracking is some simple page analytics. So, you know, um, outside of that, uh, I am planning on doing a physical release.
Um, what I've done is I've written the whole book in markdown. With some special compiler flags embedded in the markdown. Um, and we're just gonna render each of the tabs as headings, right? So any, anytime you see a React heading, um, you'll know that, that you're focusing on that code snippet and then angle and view.
Um, so we will have a physical copy at some point. I've gotta figure out the logistics of that. Um, and this is my promise to y'all. Any prom, any profits that I make from, uh, the, the physical copy will go right to charity. Whether that is girls Who code, whether that's, you know, any, any organization that, that can help people learn how to code, um, charity profits will go to charity.
Justin: That's really awesome. That's very good of
you.
Corbin: I, I'm adverse to money. I'm, I'm just allergic to it. No, uh, unironically like, like I, I'm very, very privileged and, and fortunate to be, um, in the career that, that I am, and, and I make, I. I, I'm fine. I'm comfortable. Why? Why do I need the extra whatever amount that could go towards helping others, you know?
[00:36:46] Framework Comparision
Andrew: So, uh, let's talk a little bit about the frameworks themselves. So, uh, you've mentioned that they're similar in a, a few different respects, but like how are they similar and then, I'd say a little more interesting, like how are, how do they differ the most? Like wh which one has like
goes the most off the beaten path.
Corbin: Yeah, so I, I think that this question is really interesting. I've done a few podcasts where I talk about this, and every time I talk about it, I feel like the ecosystem changes, you know what I mean? Um, like, like our understanding of hooks change and evolve over time. But then like Angular will just be like, here's signals.
Have fun with that and make me wanna rewrite my book. Uh, that's gonna be fun. Um, so what do they share? Let's start with that. Um, obviously the component model. Right. So, so you have the ability to, to componentize. Um, the, the way that my book introduces it is that each website is built out of scaffolding, which is H T M L.
It's built out of styling, which is c s s, and then it's built out of logic, which is JavaScript. Right? Um, so if we think about a component and it's most like, like pure form, it, it's really just consolidating those three and allowing you to modularize how you apply those three. Um, with, within that, that, that idea of being consolidated.
So you can mix and match and you can move a sidebar off to the side and it should just ideally work in an isolation of everything else, right. Um, The, they share input output systems. They share some method of dealing with side effects, as we talked about earlier. They tend to share reactivity, which is when you change something in JavaScript state, it'll then be reflected in the dom.
Um, they share, you know, some form of rendering mechanism, whether that is a virtual dom, whether that's an incremental dom. There is some method in which your code is then processed to be shown on screen. Right? Um, you know, that that's, I, I feel like I, that's like 90% of it. You know, the rest is, is implementation detail and additional concepts.
Um, but they, they have high component hierarchy. You have the ability to access children. You, you know, like you really are able to do very equivocal things. Maybe not exact, but very equivocal things, uh, throughout all three, um, at least of, of the frameworks I'm talking about. Um, they're differ. They differ pretty broadly, uh, based on what of those topics we're talking about, right?
I, I hinted at one of them, which is the incremental dom for Angular versus a virtual dom for vue and, uh, react. Uh, there's the difference in how, you know, uh, the, the explicit re rendering of, uh, react versus the implicit, uh, reactivity of vue versus the whatever zone JS is doing in Angular. Just patch all the things, it's fine.
Um, so it's definitely interesting to see that that contrast between those, even within that similarity.
Andrew: uh, did your journeys through, uh, these three frameworks change? Which one was your favorite? Like did coming in, were you like an angular boy
and now you're a vue kitty?
Corbin: Yes, exactly that. Yes, you nailed it. Um, that's so funny. Um, prior to the options a or prior to the composition APIs, sorry. Um, I was huge on angular. like angular, everything. You know, like we, we, we gotta get a zone js and, and all the things. Um, and then the composition a p I came out and I was like, Ooh, that I like that.
That's really good. Um, in particular, I really was a fan of the ability to move code out of vue and still have it be reactive and, and do computations and, and computed and whatever else, you know? Um, I ended up even building a backend framework using vue. That no Dom. Instead we render to the c l i. It, it was weird.
I don't know why I built it. It, I, it sure was a decision, um, part to server even. We would like literally build components and then you render the components and it'll instantiate and endpoint that you can then hit and get a response from the C. It was super weird Anyways, um, so I, I got really involved in view, got kind of obsessed with it, and now that anger's introducing signals, I'm kind of leaning back that direction.
And ironically, I have the most experience in React, like the most professional experience in React. So, uh, I really have dipped my toes a little intensely into all three of them, um, in one form or another.
Justin: That's awesome. Uh, I mean, do you, do you think that this,
I mean, I, I would assume that the answer to this will be yes. But do you think this vue into each framework is, is helpful in. I guess building a better intuition about like what makes a good framework or like, you know, so, so there are tools that come out where there are fe certain features that'll be like, oh yeah, this is like really interesting, but maybe their rea reactivity system is not great.
Or maybe they have good reactivity system and the templating system's not great, or, you know, they're, they're like always trade-offs that we have to navigate, I guess. Do you think that this helps identify trade-offs a little more, or is it just like, just helping
build a general
intuition about like approaching frameworks?
Corbin: So, No. And then yes, uh, no. It, I don't think it helps at least me identify frameworks, pros and cons. Like, like I can, I can look at like Solid JS, right? And I can be like super intuitive reactivity system, uh, that they, they're, they're docs have fluctuated between really good and, and challenging in some ways.
Um, which they, they have a, a great team that's working on it. Um, but performance, like, I know it's amazing. I don't know that it, it's gonna impact my work as drastically as, as I think most people interpret it to be. But I don't know if that, like, I don't know if that's an opinion. I don't know if that, you know what I mean?
Like, like, I don't necessarily know that it impacts your ability to be able to build a framework, which ironically I am doing. Um, but like, it, it definitely, the, the way that I'm leaning Yes, though, is that it absolutely helps you understand how to build your applications better. Because let's say that I like
I'm in React land and it's all I do, right? I might understand like, okay, the, the context a p I can cause some performance issues because it doesn't have a use select hook, right? Which is like a little bit of a fine grain like example, but, but it's something that has actually happened a couple times in, in the applications I've built.
But then you can turn around and go, Hey, doesn't vue, have this proxy model where you're able to like reflect an a p I? And, and what I did is I actually took that idea and I built a, a, like a Jotai. Um, like a p i where you can build atoms out of these proxies and use them to selectively re-render parts of your ui.
And I'm not saying you have to go build your own reactivity system or anything like that, but just thinking about the way that applications are architected, how unidirectional data flow tends to apply across frameworks. Um, you get a better understanding of what works and what doesn't work within the context of building an application.
Um, more than I think it does, uh, help you understand the framework nuances, if that makes sense.
[00:43:42] Building the Frameworks from Scratch
Andrew: Uh, yeah. So f framework nuances. Uh, the third chapter in your book has me particularly interested, 'cause like meta frameworks are, are fun and all, but, uh, that's, that's just using tools. In the third chapter, you're like, like ripping open the tools, right? And like actually figure out like, oh, how does react kind of work and how does Angular kind of work?
So how has that journey been? And like what's, what's kind of been the hardest
toy version of a framework that you've done so far?
Or I bet you probably haven't done 'em yet,
Corbin: Yeah,
Andrew: oh,
Corbin: no, I have actually, '
uh, that's how I'm confident that I'll be able to write the third book. Um, and just to be clear, that is the third book, not the third chapter. Um, if that's my third chapter, I'm going really fast.
Justin: They're just really long chapters.
Corbin: it's a, it's a hundred thousand words, uh, chapter. It's fine. Um, I just wanted to clarify. Um, so the virtual dom is really interesting. Uh, but then again, so is like Zone J like how do you patch,
Andrew: what is zone js? I have no clue.
Corbin: okay, so zone js is angulars current. They're, they're, they're talking about going to a zone list model with signals.
Um, but zone JS is. I I, if you think about side effects, side effect is just taking, uh, a, a, a measurement of an input and an output, right? Mutating outside of the context that you're within, right? So all input outputs can be defined as a side effect, um, because you're not within the system itself. If you type in a key on your keyboard, you are the external force.
If you're seeing something on screen, your screen is the external force. There's some external force that is being applied, right? So Angular was like, Hey, we know which inputs and outputs the user can have. We are on the browser. What if we became the browser? What if we patched every a p I that could ever input our output and use that as our change detection mechanism?
It's a little like I, I'm, I'm abstracting a couple of layers here, but that's effectively what it is. And then they have like a, a task management layer so that you're able to like, Detect, like, like, okay, this input happened here, so we should localize the, the, the change detection within the, like, it's, it's super interesting from an architecture standpoint, and it's also probably why the performance has like Peter Tottered between good and and frustrating at times.
Um, and it's been a fun building, but it's hard to explain, uh, at a high level in code, if that
makes sense.
Andrew: it it seems crazy.
Corbin: It's, it's like sci-fi, but it's not sci-fi and it's in code, uh, and it works for some reason
Justin: I think it is an interesting point, and it is interesting to note that side effects are often the things that lead to the most complexity in frameworks. So if you think about React, a lot of the complexity in React is like they want this sort of like algebraic type system or whatever, you know, this like, like they wanna do side effects in a very particular way and, you know, suspense and all that sort of like bloomed up from, from those ideals.
And it's, it's just an interesting observation. So like zone being a, a rather larger of complexity and angular and suspense and, and related features and react, um, you know, why signals get a lot of attention not just for state management, but for like their impacts and handling side effects and stuff like that.
So it's, it's just. Interesting note and I would be really interested to see if you cover this and how you talk about it in the books. 'cause this is like a really, really, uh, it would be a fun topic to compare all
of the frameworks and how they think about side effects
Corbin: yeah. So, so side effects are actually the longest chapter in my book. Uh, they're, it's like 10,000 words, uh, because they're just that complicated. So, so I'm gonna, Justin, I'm gonna take your words and I'm gonna morph them a little bit to make the, the side effects even more predominant in the
context of a framework. So, so, so let me start with a question or two. What is the predominant use case of a framework ignoring componentization, which we could argue is like the big one, but like, outside of that, what is the big, big benefit that most people attribute to a framework?
Justin: standardization, making it easier to maintain.
Andrew: Okay, but look, why not use jQuery? Right? Like, like why, why not build your own, like, like DOM implementation? What are you getting from having a framework that, that like
Corbin: jQuery might not offer?
Justin: Well, when you use a tool like jQuery, my opinion is you end up building a framework of sorts, right? It is just like you have these patterns that you apply to how you build products, how you build UIs, and a framework like
comes with opinions about those patterns.
Corbin: Right. And one of the things that I've noticed when you do build your own framework with J query, and, and this is in my opinion, why these three frameworks took off the way they did, is that you end up with re renders. Right? And those re renders tended to not be very localized. They tend to re-render huge parts of your ui, which cause performance problems, right?
But we were talking about side effects as input, outputs, right? What's rendering,
Andrew: and output.
Corbin: what is showing something to the Exactly. So the entire point of a framework, not just part of the point, the entirety of a framework is dealing with side effects. Whether we're talking about the rendering a p i, whether we're talking about the side effects, a p i, whether we're like, like every part of the framework that's involved is a side effect, which is like, you know, you don't think about side effects that much when you get started with program.
At least I didn't. Uh, so it's like kind of fascinating to come and realize like, oh, everything's a side effect. You know what I mean? Like, like this kinda like
fascinating ideal of, of engineering.
Justin: Yeah, I mean, I, I think it is, like, I'm often reminded that one of the most important aspects when building software ever is thinking about data structures, uh, how you structure your data because it ultimately does have impacts for things like side effects. Uh,But there are these fundamental concepts, data structures, side effects, you know, that are so deeply ingrained and such a, like they are the core essence of how we or what software is, um, that we spend a tremendous amount of engineering effort on just these topics, you know, because they are so pivotal
to the whole software world.
Corbin: Yeah. and and I wanna know if this is just me, but I feel like when I started learning programming, no one talked about what a side effect was. No one talked about like, like, yeah, there was, there was data organization, but I. Maybe this is just because I came from like a, a kind of self-taught journey. You know, like I, I, I kind of dropped outta high school.
I didn't really do the college route too much. Um, so maybe it's just because I, I lacked that formalized education, but people would talk about pure functions and then never explain what a side effect was at a high level. And it was just this abstract idea that everything has to be pure without any context provided except for like, math papers that I'm not gonna be able to understand because I didn't do that.
You know what I mean? Um, so I, I wanted to make sure that, that when I was writing the book, I'm, I'm introducing concepts, yes, but one, I'm introducing them as linearly as possible. There's no chapter that references something that you haven't learned already, if it's not what you're actively learning. And then two, that I'm not going so far into the computer science world that I'm like losing my audience of people who may be learning for the first time.
Justin: Did you had to build a, a, like a topographical sort to like figure out what topics should be,
uh, introduced first,
Corbin: yeah. It's,
it's, uh, it's a weird feeling to be like, Hey, by the way, we're gonna talk about the VDOM in the third chapter because like, like, like if you look at it from like, ignoring that context, you're like, what are you doing? Why are you introducing a timer before you're introducing inputs, like user input?
And it's like, well, there's justification for it, right? Um, but it's, uh, I had to rearrange the book a lot. I, I would write a chapter and be like, no, that belongs here. No, that belongs to here. Um, so it was, uh, quite the challenge to
build out this way
Justin: this is a fun topic. We talked to Josh Goldberg back in episode 35 about this exact thing. It's like, how do you figure out like what goes where? And he was like, actually, I made a tree and I sorted it.
like,
Corbin: Yeah, Jo Josh is fantastic at, at, at articulating concepts. Um, he and I did a live stream where, where we were building, um, a es lint plugin for, uh, house form. Yeah, actually, um, and the way he would explain things was just so intuitively ingrained. Like it's very clear he has a mastery in in that, uh, study.
[00:52:12] What to Start With
Andrew: and what a performer. Um, if you've ever seen a, a talk by him live, he gives. Some, some of the most fun talks out there, the, the things he does with a type system. Crazy. Um, so, uh, after all these explorations and writing a book, uh, which framework do you think would be the best for a beginner to start with instead of all three?
If, if they couldn't do all three at once.
Corbin: So, so I have, uh, a very tempted take on this, and it's whatever one you pick. Uh, that's, that's my actual opinion. Um, you can learn any of the three. Uh, reasonably like, like within an earshot of each other, right? Like you, you can, you can, I don't know why you said earshot, but you, you can take a stone, you can throw a pebble and, and it'll land in the lake of the other, you know what I mean?
Um, I generally prefer vue as a personal preference. Um, if I had to teach someone, it would probably be vue just because I think that that, um, you know, one of my complaints kind of tangent, but it'll loop back. One of my complaints about Java is that you, in order to introduce a hello world, you have to have a static class.
And then you have to like, what are we talking about static methods for at, in a hello world, right?
Um, and I think there's, there's a bit of value
in being able to say, here's a reactivity system. Ignore the dom. Here's how this works. Right? And I think that's valuable. Um, That said, I think that there's also, if you introduce a concept like, like I did in my book and start with components and talking about the, the fundamental nature of the web, and then you go into the, the aspects of the framework, there's also another intuitive learning path.
Um, my recommendation to learners, and this is gonna be really weird coming from someone who is writing a book about three different frameworks, is pick one framework and master it. Like really dive deep, learn, learn the APIs as as deep as you can, and then start to explore. Um, the challenge that I see a lot of newcomers start with is that they'll, they'll try to kind of learn everything all at once, and the, they lose the conceptual mapping because they're focusing on the syntax very heavily.
And I think that if you reverse that pattern and you stay with one syntax to learn the advanced concepts, you'll
be able to keep up a lot better.
Justin: And there's also more to learning a framework than just learning the framework. You have to use the framework. It's the application that is important. It's like building the products that give you the generalized principles of like, oh, here's what it means to build a website or a web application, or whatever.
Ever. And then I, I think it's that deeper learning or, you know, there's often these division between should a, uh, someone who's starting out just learn HTML and JavaScript, like raw, uh, H T ml, JavaScript, C s s, just like raw out of the box. Or should they like learn a framework. And you know, my thing is just like whatever gets you the fastest to building something.
'cause it's like at the start, that is the most important thing. And you'll figure out the bits and pieces and how everything plays together. But the important thing is building the momentum, establishing a context, and the, the sort of patterns will start, you know, revealing themselves to you.
Corbin: For sure. For sure. Yeah.
Andrew: The biggest thing I took from college was, uh, the, the catchphrase for the college. It's learned by doing, and it, it's been, it's been true throughout my entire career. The best way to learn is just to do, do, do,
Corbin: yep, a hundred percent.
[00:55:31] Corbin's Framework
Andrew: So speaking of making your own things and writing your own, uh, stuff to learn, uh, you wrote your own framework, so, uh, how was that experience and like what were you trying to accomplish with your framework?
Was there a certain a p i you were
going after or was it just purely for learning?
Corbin: Um, so. let me start by saying what I wasn't trying to do. I'm not trying to create a viable framework that anyone else should ever use. Uh, that's definitely not what I'm doing. Um, so this, this was actually a bit of a fun challenge. Um, a couple of months ago, a friend of mine and I were having a vc, um, in, in Discord, just chatting, and he was like, Hey, what would your framework look like?
I'm like, I don't know. I'd probably reuse J S X, you know, pull a, pull a quick, pull a, you know, like reuse existing tooling, maximize your, your whatever. And he was like, no, no, no, no, no, no. What happens if you had to start from, like, if you just had nothing else? And you just had to start from scratch. Okay.
Let's see. So I started tinkering with, with, um, like signals. 'cause I, but, but like a, a mutable signal. So, so you can just sit there and be like, something dot value plus plus and order to re-render. I, I tried to make it super local. I tried to avoid my own templating language by reusing H T M L, which I really like.
And next thing I know, I have this like, strange amalgamation of like solid js and like, um, what is the other one that, that comes to mind? Um, uh, what is it called? It's gonna bother me. Hang on. Um, starts with an s doesn't it? Ah, I can't remember it.
But you're, you're able to,
Justin: spelt
Corbin: not, not Spelt I don't remember.
It doesn't matter. Um, but, but you know, you can just add tags into your H T M L and have it like re-render immediately. I. Um, so like, it's, it's funny to me that, that I've ended up building 18 other tools into one tool when trying to avoid following any particular syntax. Um, so mostly it's just for fun, but I think it'll help me, um, really conceptualize what it means to build a framework in a very natural way, as opposed to, I have an existing course and here's how I would follow it exactly to a t.
So I hope that, that by writing my own framework, I'm able to not just learn myself how the internals of a framework would work. Um, 'cause you know, I've read, read enough of the source code of, of the three frameworks I'm talking about. Uh, but to be able to go beyond that and, and teach writing your own framework in a much more natural way as well.
Justin: I really love that. Uh, I, I love what you're doing, uh, and I love this encouragement because I. There's a lot of times that people don't teach this sort of, I mean, we, we generally don't teach this sort of stuff enough, right? So, and, and the times we do, you know, and if it's done well, it becomes like a very big thing.
So I, I think of the crafting interpreter's book, which is like such a phenomenal book and you know, it, it is so great because it, like, the way that it approaches it is just like pretty practical and you know, it gives you a lot of like, good information. And anytime someone's trying to start something like this, they're like, how do I even do this?
Like, what, where do I even start? And, you know, building the momentum to even just like getting the mindset is so hard. So a lot of people drop off, you know, of like, of the potential people that could be writing frameworks and that could be experimenting ideas in the space. It's like, We get a very small subset and you know, we should be all grateful that people are experimenting because I think our frameworks are so much better today than they have been because of the iteration and the experimentation and you know, all the things that came before.
But opening up the possibility space, having more people like understanding what it takes to build a framework and like thinking about the trade-offs or whatever is, is great for the entire ecosystem. And if you can like make this first step for someone to like, oh, I get it. Like I, I see how you go from nothing to like something that is a framework, then that is a tremendously valuable
sort of educational leap to make.
Corbin: Wow. For sure. And, and one of the interesting things that I thought a lot about when I started Unicorn utterances is this idea of like, there's so, so many resources out there for newcomers and there's even a pretty healthy number of resources if you know, like, you know, if you can read source code, you can go and, and read this source code of the frameworks.
You can do this and you know, so, so there's this end of the spectrum way over here and there's this spectrum way over here. What if, what if you're learning, you know, what, if you're trying to grow into your first senior role or, or, or become that principal engineer, you know, like, what, what are you, what are you supposed to do?
Where do you follow? What, what journey do you take? Um, and, and that's why I wanted to make sure that, like my first book, I'm, I am very happy with it. I hope it helps people learn. Um, but really it's the third book that, that like, makes me wake up in the morning and go, okay, we've gotta write that next chapter.
Okay, we've gotta edit that. You know, we've gotta do whatever. Because it, it's, it's that book that I think is really going to make it all worthwhile for, for, for me.
Andrew: That's awesome. Ex excited to see, uh, it all all be
completed. I know you have a mountain of work ahead of you.
Corbin: only a couple. Yeah.
[01:00:26] Spicy Takes
Andrew: Okay. Uh, now that we, we've talked mostly about your book, uh, I wanna get some of your thoughts on the future, uh, and the present. So right
now, what's your spiciest web dev take?
Corbin: All right, so, so I talked a little bit about this on Twitter, um, but my spicy dev take is that, uh, we need to stop making code as dry as it's dry being don't repeat yourself. And I think we've taken this mantra way too far as an industry. Like we, we talk about like dependency injection and you've like, not that it, that you can't use dependency injection well, but people are talking about like, you need to dependency, inject and invert the control flow and do this.
And the, and it's like, I could just copy and paste this like two or three times and we're good. Like, is it re like, leave a comment telling me where the other three are? You know what I mean? Like, like I really think we under utilize copying pasting techniques as, as engineers. Like, I know we're lazy and we want to be able to update things, but what if the easiest way to update something is to just type it thrice, you know what I mean?
Like, I, I think we overuse it, uh, for sure.
Andrew: Yep I was, I was similarly in that same situation. Just recently I was refactoring something and I got to the end and it was like, oh, this com, this whole like thousand line component now has to work with a completely different data type. And I was like, no. And it just, the whole code would've just been spaghetti mess.
And I was like, I think we're probably gonna change this in the future. Control C, control V. Change the type, fix the problems. Only have a hundred lines. Now look at that. And, uh, yeah, I don't repeat twice. I, it don't repeat three or four times. Maybe like once you get to three or four, you, you found like a, a thing that you need to put somewhere else.
But like, if it's, if it's two to three,
you, probably don't need to.
Corbin: Yeah. Yeah. The, the, the best use case that I found for this is at my day job. We are currently converting from one version of an a p i to another. We're like, we rewrote it in a totally different program language, but we still wanna be able to support the old a p I for a period of time until we end up with the new code base, right?
So we have entire screens that are copied and pasted and, and the first intuition is like, why would you do that? What's wrong? Until you realize that I can just now R M R F any file that has Dash V one and just be done with the old code base entirely. Like, just not have to worry about it even a little bit.
So like, yeah, we have two apps running at the same time and just conditionally switching. But like, is that a problem? Like, if it's gonna make a way more stable use case and it's gonna make transitioning easier, like that seems like a huge dub, you know?
Andrew: Definitely agree.
Justin:
[01:03:00] Future of Frameworks
Justin: Okay. Um,
so
I'm again, so incredibly excited that you are writing this book. I think the juxtaposition will be a really great educational resource and, and give learners a different angle to think about frameworks.
Um, So when you're thinking about frameworks, having gone through and spent so much time with these, uh, I'm sure you're really plugged in with like kind of what's going on in these dis different ecosystems. What do you think the future of these frameworks are individually and maybe how that plays into the future
of how we develop products on the web?
Corbin: Yeah, so it's, it's always interesting. My, my earliest talk, not earliest, but one of my really early talks was about React hooks, and it was like, here's React Hooks. And I ended the slide by being like, here's the future of you. They have this composition thing that they're kind of whispering about, and they have the angulars, I don't know what Angular is doing.
They're doing something, you know, because at the time I really didn't know, um, It's, it's so interesting to see how the framework authors have communicated with each other, how the ecosystem has evolved. Um, in particular, I'm really excited to see solids influence on both Angular and vue, um, both with the vue Petit program, um, and the, uh, uh, angular signals.
So Angular seems to be moving away from zone js and towards a, a zone less future of signals, which is pretty cool. Um, I'm really excited to see how they deal with interop between R X J Ss. There's a lot of conversations that are like, they're the same thing and it's like, no, they aren't, but there should be some level of interop between them that I'm excited to see where the, the Angular team goes with, um, vs.
New rendering pipeline. Seems like it has massive performance benefits, which is really exciting, especially if they're able to keep a fairly consistent a p i from what was there before. Um, and then of course React has fcss and, and like they're going all in on the offscreen a p I and trying to make sure that side effects are, are handled properly and, and kind of like this, this, uh, Like mathematical kind of way almost.
Um, I think what we're gonna see in the future is a lot more communication between the authors. It feels like, like a couple of years ago, at least from the outside perspective, um, it felt a lot more like, you know, they were working over here, they were working over here. There wasn't. A whole lot of communication and now it definitely feels like, oh, I've seen those people talk online.
I'm sure there's more going on behind the scenes. Right. Um, and especially with like versal taking ownership over next jss and, and having some stake in React and having spelt on the, you know, like the, it just seems like the ecosystem as a whole is not necessarily converging, but, but entering into a much more cooperative era, which is really exciting.
The way that I hope it goes in the future is that we take that cooperation and are able to kind of like alioop that into an, uh, a win for newcomers, right? How can we keep our APIs simple? How can we keep our APIs documented and how can we keep our learning resources up to date and, um, helpful.
Justin: I was gonna mention this earlier, but I, I think it's really fascinating how, um, I think the front end eco ecosystem in particular has evolved so, so, so rapidly. So much faster than a, like a lot of the paradigms before it. And you know, I think that's in part from a open source, uh, being more natural in the frontend ecosystem, uh, because like view source, it just kind of like in, in the blood of the thing, right?
And, uh, it's from people borrowing ideas and just like iterating on things and building all these new frameworks and like doing all this new stuff. I think that, that like has been really key to this rapid evolution. And, um, I don't know, it's just an idea that was sitting with me. It's just like there, it would be really interesting for someone eventually to write a book about the history of like the web and specifically
about how the software evolution that it goes through.
Corbin: One of the things that
I'm writing about right now is actually the, the history of node js and how it came to be, you know, like we had JavaScript on the server back in the, the nineties of
all times. Right. Like with Netscape. Yeah. Like, isn't that what you know? And, and it wasn't until I. We had this, this common JS conversation and like, like everyone's like, oh, common JS is just the module system.
No, it was like a huge thing that that was getting started in, in 2008. So it's, uh, there's a lot of history about development and in particular web development that I really think we've just lost. Um, I, I, I'm excited to see that, that we've kind of entered a little bit into that historical record keeping in stuff like the, the React documentary, and I wanna say there's one on spelt
They, they, they're doing good stuff. I, uh, so I'm, I'm excited to see more, um, context preserved.
Andrew: The, the first time Justin's tried to nerd snipe a guest into writing a book right there.
[01:07:54] Tooltips
Andrew: Okay, so my first tool tip, this actually kind of relates to where we started the episode, is photon. Photon is an image processing library for the web built on wasm. So, uh, the thing about Jimp, uh, the JavaScript image manipulation library is that. It's JavaScript and that means one of the goals of the project is everything's JavaScript.
So that means everything from the encoders to the decoders to the image manipulation. And that works in some cases. Uh, but you can imagine it not working in all cases 'cause it's JavaScript and all of those encoders and decoders are open source re-implementation. So they're never gonna be perfect. Uh, when, uh, Corbin and I were thinking about like, how do we take the gym project forward, like web assembly like comes to mind, obviously.
And then, but once you say, oh, we're putting web assembly in the JavaScript image manipulation project, it's like, is that, no, they're not the same thing anymore. And so like, As I as like an ideal. We just said no, no web assembly because it just doesn't make sense in this project. Where it does make sense though, is in a new project and I think, uh, projects like this will definitely come into prominence because like image manipulation is some something people wanna do and they wanna be able to do it in an isomorphic way in whatever environment they're in.
And web assembly is the obvious, uh, go-to technology for that. And so I'm really excited to see that somebody's TA taken the step to create a library that you can actually use in the same way that you would jimp. But it's probably like 10 times better when it comes to speed and like bugs and edge cases.
So if you've needed a image manipulation library in your JavaScript,
I'd go look at photon. 'cause it looks really interesting.
Corbin: did you also hear that Sharp, just ported to
web assembly?
Andrew: Yeah, exactly. So like, in my thinking about it, like I got, I got all the way to the place where I was like, The best route forward really is just making image magic into a was module. But like, I think the problem there is that image magic is like enormous. So like, yeah, putting that into a web assembly binary is probably a non-starter.
So I think like a new greenfield project that's like thinking about this in a web first way is the way to go and cool to see.
Corbin: Oh yeah, for sure.
Justin: If somebody can build this in an ex tism module or something, then you could, you know, share it across
project.
Andrew: Any platform anywhere. Next up we got Mm. Page
Justin: Yes. mm.m. Page. Uh,
so I. Uh, I think like a lot of people, I have this nostalgia for like the GeoCities era of the web when people's homepages were grossly not responsive and probably lacked a bunch of accessibility, but had a lot of personality. It was like more of an expression of who you are and people were doing just, you know, weird stuff with H T M L and they're just like trying to dump all their ideas and their creativity and it was like more this like, kind of weird, interesting reflection of who this person was.
And, and now I still love blogs and I feel like everybody should, you know, take time, build a personal site, build a blog, and it doesn't matter if you use a template or a framework or whatever, just do it. The most important thing is doing it. Um, it's, it's valuable to have that expression out in the world.
But also I really love it when people just do weird stuff and they have fun with it and they express it. And as someone who does a lot of web development, I understand that even if you do it professionally, it is hard and there are tons of decisions and it can be really hard to get started and you can get discouraged.
So, mm. Page is this project from sort of semi indie developer? Um, I think it might only be one person or, or very few people working on it, but it's a sort of wizzywig, you know, uh, visual editor for just building a weird sort of geocity style. Like, I'm gonna slap things on the page, think of the webpage as more like a canvas that you're adding text and images and stuff to.
And it's really simple and. I just, I just love it. So they have this, like, you can go on and there's this discover feed where you can just like browse through like different people's pages and it's so cute and it's so fun and just like seeing how people have expressed themselves and I don't know, I, I think it's great and you should play around with it.
That's fun.
Andrew: Yeah, it's cool to see tools like this. Ire a, a lot of people from my generation got their, wrote their first H T M L and c ss s on MySpace, and I feel like, I feel like that just doesn't exist anymore. Like, I don't know of any platform, maybe Tumblr, but like, that's still not this generation that would like enable you to just like fiddle around with some bits and like maybe even potentially get into programming.
So it's, it's cool to see, uh, projects like this.
Corbin: Oh yeah, I, I remember one of my very first, uh, web experiences was there was some like kids game that I was playing and I remember like, oh, it's a storefront. I wonder if I can change the price by editing the H T M L. And sure enough, I would go change the attributes and it would let me buy things for free.
And like that was so much fun to just destroy an ecosystem of a small game. Um, but, uh, you know, it's, uh, it's definitely cool that the, the want to be creative will definitely inspire you to like, go further in your career. So I think projects like this are exciting.
Justin: Yeah,
I, I strongly, strongly believe that reducing the barrier, even if you're experienced, like make it easy. Make it easy. Always work on making it easy. 'cause if you make it easy, you can do more. You have more space, more energy. So yeah,
Andrew: Next up we have the G P D. G p d win MAX 2.
Corbin: Yep. So first of all, the the, this website is amazing. You gotta love the comic san s. That's how you know it's a professional product. It's, it's good stuff. Okay? Um, so check this out. This is my laptop, right? First of all, it's tiny. Second of all, it's got a game pad on the inside. Like it's got a Xbox controller built into this tiny 10 inch laptop.
Like, what? Who, who does that? Why'd they, it's like they married a steam deck in a laptop. It's terrible. It's great. I love it. I bought it.
Andrew: This is the coolest netbook I've ever seen, but not with
not with the netbook power. It's got the good stuff in it.
Justin: yeah specs are really impressive.
Corbin: it's got like 32 gigs of
ram and a ryzen processor or something crazy like that. Like
Justin: Terabyte hard drive.
Corbin: they didnt have to go this
hard.
Justin: ISo they spend all the
budget on the hardware. That's why you get the comic sands.
Corbin: Yeah. That's why the, uh, the, the hacker like, like screensaver there. Oh
yeah.
Andrew: That's, that's funny. They, they couldn't afford a font license.
Corbin: Yeah. Uh, so, so I've, I've been really, uh, having fun with that. I've been replaying Tony Hawk lately, like, like the old ones on my, on my G B D. Um, and it's like such a fun experience to go like, play the game on lunch, break and then come back and be like, oh, I'm typing some document now. And like, very weird
Justin: Wait, does it have an Oculus hookup to it directly on the hardware.
Andrew: It has an OCU link. Yeah.
Justin: That's crazy.
Corbin: Right. Like you can just hook up an E G P U to this and have like a gaming desktop.
Like why did they go this hard?
Justin: Oh, wait, wait. No, it, it is got stylists
input too.
Corbin: Yeah. It's like a touchscreen. I'm telling you, you guys, sleeping on it
Justin: What, What, who who built this? Who did this?
Corbin: It can play, it can play Elden ring, and that's the most upsetting part
Andrew: I've been trying to play Balders Gate three on my m M1 MacBook, and it's okay. It's not very good.
Corbin: Yeah.
Andrew: Um, okay. Next up. Uh, this is a tiny little library that popped on my feed called generat Routed. Uh, what it is is a plugin or something for Vite that allows you to have a next JS pages directory like experience.
Uh, it currently works for React and Solid, but since it's in vite I feel like you could easily extend this to like whatever framework you want. So I just think that's pretty cool that you can like, take this like concept that's been popularized by next and not use it in next anymore and potentially use it with any framework.
So, uh, if you've been looking for something like that, this is probably the project to go look at.
Corbin: that's really cool. I'm always curious about these like framework
agnostic tools and how they're built under the
Andrew: the beauty of GitHub, just crack it open, do that all the time.
Justin: It is, It is, really cool to, I mean, that's one of the things that I love about vite becoming sort of an underpinning of a lot of these tools. So, I mean, a lot of the frameworks and the meta frameworks are being built on Vite now, and, and if you get more generic tools like this, then it makes it, um, it makes a, a powerful abstraction layer to really make it easier for building meta frameworks, which I think is also another great thing to do. Just like more experimentation
Andrew: Next up we have markWhen.
Justin: This is a
a, really random one from the pile. Uh, I, I think it's kind of a fun project though. So this is a markdown syntax for describing a timeline. Uh, so if you think like Gantt chart or like, you know, you're trying to describe a series of events. Uh, yeah, this is, this is just a, uh, syntax for that.
Um, and it has some like rendering facilities. So it's like you, you write this like pseudo custom markdown and then it like renders out these like kind of pretty timelines for you. Um, and I just thought
it was like a neat little project. It's just interesting.
Corbin: that is very cool.
Andrew: Uh, and last up from Corbin. We have, uh, a favorite on the podcast. Favorite of mine too.
Fork.
Corbin: Yeah, so, uh, take it from someone who tried to write their own, get gooey, uh, fork is the best.
I've been hesitant
to like, promote theirs 'cause I was building my own for like a year and a half. And then I like realized that's a lot of work. I, I was building a, a get gooey for your phone, which is a terrible idea.
Don't do
that. Um, and, uh, I don't know. I was using fork to build it the whole time and loving it and it's like, it's just a good tool.
Andrew: Yeah, the, this finally got me to move over from getup. Like, I, I don't want things in my UI most of the time. And this, this UI really strikes the balance of like, things I want in my UI versus, uh, like a bunch of visual noise.
Corbin: Yep.
Justin: I love these tools, but I'm always looking for like a little bit more out of a get client. So it's like, uh, I don't know if y'all ever heard of Conveyor by Wildbit. So Wildbit is a really, I love Wildbit, the company. They're, uh, really small company and, and they have like four day work weeks and they were working on this project called Conveyor, which I think they shut down.
Um, but there were like trying to reimagine how you do product work and how that integrates with Git. And then there's another one that came out recently called GIT Butler, and they have this really interesting feature called like virtual branches. So, you know, if you've ever had like a, a, a PR, that's like getting too big and you want to kind of break it down and it, that can get really hard.
So they have this feature where it's like, not only can you break it down really easily, but you can toggle things on and off in the same branch without like doing anything. Uh, I always like want that. It's like gimme something more like, I don't know, make it. Different, easier, whatever. Also, who is gonna build the next tool to replace Git?
Like when is this happening?
Like, I
think this will happen at some point, right?
Andrew: it's one of the longest standing dev tools, I'd say like around now, like it's still the go-to and it has been for 18 years. That's crazy.
Justin: Maybe it's just a, you know, uh, some lipstick that gets, you
know, added to it or whatever. I don't know.
Andrew: Yeah. Uh, here we use graphite, but like, That like another tool on top of it. Like my brain just doesn't wanna learn it when I can, like when I can just submit big prs with my commits organized nicely.
And then last bonus, one corbin wants to be sponsored by bomb pop.
Corbin: Yeah, but, if you know anyone from Bomb pop call me, their popsicles are great.
This is like, an ongoing joke between my community is like, I just had a bomb pop on stream one day, and they're like, oh, sponsored stream. I was like, yeah, sponsor
me. Come on, do it.
Andrew: We'll get you there.
Corbin: Oh, good. good.
Justin: social clip gonna cc bump pop. This is gonna happen.
Corbin: I'm just saying, I sent them a
DM and it was like written by Chatgpt it was very cringe. It was great. I loved it.
Andrew: That's hilarious. Okay, well that wraps it up for tool tips this week. Thanks for coming on
Corbin. This was, uh, a very fun conversation. You're a
very lively person to talk to and a very know knowledgeable person, so thanks for coming on.