React vs Vue vs Angular with Corbin Crutchley

funny. I just got back from NG comp. So I drove to to Mhmm. Salt Lake City, Utah, drove back to Sacramento to stop at my house, and then drove all the way to LA. So a lot of driving reason. Oh, man. Yeah. That's wild. Good that, you were at that Scott because I I had some questions about some of the news from that comp. So,

we, yeah.

So I started as a full stack Angular developer alongside Mongo and Express and, you know, the the typical MEAN stack, back in my crew like, at the very start of NG 2, like, the the RC and beta releases.

My company was, like, very certain that that was gonna be the future, and they were totally right. So we we started there, in my career, stayed there for about three and a half, almost 4 years. And then I I joined Hilton as a React developer, and I've mostly been into React since then, but I've done a lot of side projects in Vue as well. In fact, I wrote my own Vue renderer along with my buddy, James Fen.

So just a Scott of lot of fun experimentation across all the 3 frameworks. And at one point, I was like, you know, there's a lot of similarities when I was learning 1 versus the other, so I figured why not throw them together in a single resource?

Nice.

And before we get too crazy on this, if you're experimenting with any of these frameworks, you're probably gonna want some kind of error and exception handling tracking because you you're gonna make some you're gonna make some bugs. We all do. So head on over to century.ioforward/syntax.

Sign up and get 2 months for free. You can track all of your bugs. Make sure that you're not running into anything when you are, trying to ship a software with a framework that you don't know. So you mentioned Hilton.

Is that, like, the hotel the hotel company? Yeah. They they have a pretty big in house software shop, surprisingly. I'd imagine so. Yeah. What what was that what's that like with because I imagine that's, like, heavily the type of area where if the software doesn't work, you're gonna get a bunch of people who are angry that the software is not working. Right. So JS that, like, a kind of a high stakes environment working on booking software like that? Or or is the booking software owned by Hilton themselves, or is that, like, a third party? Or

Yeah. So one of the the the pieces of software that that I was on is the the GME, the groups meetings and events team.

So one of the things that we just supported is, like, what if you could book more than 10 hotel rooms at a time? And as you can imagine, those transactions are just astronomical. Right? Now I didn't deal with the payment processing side myself, but but even if there's a bug in that workflow that prevents you from moving forward, it's kinda like, oh, we just lost this incredibly large sale. Yeah. Oh, yeah. So Big money. So Wes made sure that, you know, we had our CICD systems in check as much as possible. We had an incredible QA team.

In fact, we had dedicated accessibility teams for for each of the the groups that I was working within. So, we we really made sure that the standard of of our software was was very high. Nice. That's and what did you say what the stack was for that tech? We were predominantly using React at the time.

Because I remember Next. Js. I don't remember Tailwind as much, but that may be a a newer decision. You know, I I I haven't been there in a couple years. So Oh, yeah. Yeah. And with big companies like this, they often have, like, multiple applications. You know? Like, the Yeah. The booking

Booking anything. Or Dates, time, scheduling. I I I worked on a booking app, and it sucked. It was so hard. And that was just a basic, like, scheduling app for hairdressers.

You know? And that's like a a whole, like, a whole decimal point or two difference in in price tag compared to

booking airplanes or booking hotel rooms or something like that. One one of the things that I was tasked with is actually building out the calendar selection.

And, I mean, you have to tran you have to support 30 some odd brands because they support multiple of their brands. Oh. You have to support translations across a bunch of languages. Like, there was a ton of functionality that went into the the design system at Hilton.

and bring your firstborn.

Yeah.

Angular, View, or React. Yeah. Come on, Corbin. Why don't I give an answer for this? You wrote the book. Right? Am I allowed to pull the it depends card? No. Just just pull that 1 out of the back pocket.

Dallas.

So, I have my personal preferences.

You know, I I really like what the Angular team has been doing, and I'm not just saying that because I went to NG conf. In fact, I went to NG conf on my on my own dime because I've been a fan of what they've been doing recently.

So I'm a huge fan of Angular signals and what they're doing with stand alone components and stuff like that. Vue is absolutely up there. Their composition APIs have been kind of top of class for a long time, and it's only recently that things feel like they're starting to shake up. And then, of course, React is kind of like the the the golden child, you know, the the one that everyone talks about and uses.

Yeah. Yeah. It's definitely popular. So I don't know. I really like Vue for a lot of, like, interactive websites, you know, like like high interactivity, but but also, like, not just interactivity, but event driven UIs. Right? Either that or or utilizing RxJS's integrations with Angular is kind of my pick there. But especially if you're building static sites I mean, not that necessarily you should be using any of these frameworks for Sanity site, but if you wanna sprinkle interactivity throughout there, I think using something like Astro or Next. Js with React is kind of a pretty big win there. Yeah. Totally. So when you're diving into, like, comparisons,

there's there's probably a lot of different subareas of all of these frameworks to compare.

How do you even think about the different subareas of these things, and how do you compare things that might not be comparable between the 2?

There are 3 or 4. Great question. So when I was structuring the book, it was actually supposed to be 1 book originally, and I kept adding headings and, like, scaffolding out the the the, like, rough draft. And as I did this, I was like, there's, like, 50, 60 different headings in here. What am I gonna do? So as I kept growing, I realized that there was a way that I could divide them into 3 separate books.

The first Node is the book that just came out called Fundamentals, Framework Field Guide Fundamentals, which just teaches the API of the frameworks themselves.

No Pnpm install outside of the initial setup.

No fetch or needing an external server. Like, you're just learning the absolute basics of the framework. Right? The 2nd book is ecosystem, so, like, you know, the the meta frameworks, the the the Axioses, the the routers, the, you know, whatever other libraries you might have. And then the 3rd book will be internals, which is rewriting Reacting or Vue from scratch and understanding exactly how they work under the hood.

So that's that's been how I've been thinking about how to, like, structure the content JS that like Yeah. Like, in order to learn, say, React Router or something like that, you kinda have to understand a little bit about how refs work, a little bit about how how, you know, JSX, like, composes in different ways, how JSX is just a value. You know? So, like, it really helps to have that foundation of knowledge, which is why I started there.

The the the 2nd challenge that you outlined there is what do I do when there's a difference in each framework? Right? Like like Angular, in particular, has this concept of, like, view containers that you can add a structural directive to, and it gets really complex and messy, but it's important to know.

So what I tend to do is is in the book, there are 3 different tabs for all the 3 frameworks and allows you to switch between which of the frameworks you have. And usually, there JS, like like, some basis of reference for the other frameworks. Like, React doesn't really have the concept of directives, but you have a hook that you can return a ref from. So I try to do my best to kinda guide the user to be like, look. This isn't the same, but here's how I would do this in another framework. Yeah. And then if there's just no alternative, I I will just be explicit and say, there's no alternative yet.

You Node? Look at the other examples to get an ex a guidance of what what this might look like.

Yeah. Do you feel like the meta frameworks in these worlds are are comparable? Because oftentimes, you know, in our end, we we see a lot of Next. Js on this show.

We don't talk about Nuxt very often. And, honestly, I don't even know what the meta meta framework in Angular world is like if there is even one.

Can you speak a little bit on that?

So the MetaFramework in Angular tends to be analog these days built by Brandon Roberts.

Oh, we had him on the podcast. Yeah. Yeah. He does fantastic stuff. Analog just hit 1 ESLint o, so there's a lot of good stuff that's going on there. Then there's Nuxt, of course, and I think that Nuxt is pretty mature at this point. You know, there's a lot of like, they have the Nuxt Studio. They have the the Nuxt virtual stuff. So they're they're building a lot of really neat integrations.

So I think that there is some good competition in the space of meta frameworks, and, of course, there's even ASTRO. Right? Like like, ASTRO doesn't really fit cleanly into those boxes, but they just released their their database solution.

So there's definitely, more competition in the meta framework space than I think there used to be a couple years ago.

Oh, yeah. Yeah. So it it, first of all, it was one of my first few conferences.

So, you know, there's always that that hype and and hubbub around any, you know, conference where you're able to get to meet folks. The big announcement was that YouTube is starting to use, Angular signals, and they're they're trying trying to start merging in aspects of Angular and the internal Google framework Wiz together, which is really exciting to see, especially because Wiz has kind of like spawned some inspiration in QUIC, the the other framework that that's been released by the Angular

creator. Yep. So it's definitely cool to see a lot of the announcement that have been going on there. Yeah. Yeah. I was curious about that. So the the combination there because I I saw a lot of people saying that Wiz and Angular are merging, but I I don't necessarily think that's the case. Right? Is it is it just that they're using aspects of Angular, like the signals within Wiz applications now over at Google?

So I talked to Minko about this, who's who's one of the Anchor core members, and, Jeremy as well, who's the the technical lead at Anchor. And what they were telling me at the conference is that, like, it's not necessarily that Node is going away. It's more that they are learning resources from one another. Right? So, like, Angular has been very interactive, dynamic enterprise y, and Wiz has been much more static, like extremely high performance, low latency environments. Right? So we tend to think of these as opposite ends of the spectrum, but things like React Vercel components have really started to challenge that idea of, like, what if we had a really low latency fast application that you could then add interactivity kind of like as you needed it? So I think what what Angular team was ESLint me is that they're not necessarily merging, but they're they're learning from each other and developing out these, similar technologies that they can use to kind of move back and forth between them internally.

Yeah. It always felt weird to me that there was a internal framework and an external framework and, you know, depending on what project you were at, which one you used, or whatever you used there. So that it it only makes a lot of sense to me.

Yeah. Yeah. It it was definitely interesting because I think that there was a bit of a mismatch message between what was shown at NGCon's, like, conference stage and what was Yeah. Mentioned in Twitter.

Sure. So signals are are reactivity primitive. Right? So but let's kinda zoom out from what that means JS that, like, let's say that we have a a counter, right, on on an application that's in HTML, right, in your DOM, in your browser, and then you have a bit of state that is in JavaScript that reflects that same count. And whenever you update the state in JavaScript, you wanna reflect that state change in your browser in HTML.

So what usually happens is that you might have, like, a query selector to the element, and then you'll, like, like, enter text, update the the value, something along those lines. Right? But if I just mutate the value of count to say count equals a100 and I don't do anything to to reflect that back to the DOM, there's a mismatch there, right, between what's in memory and what's in the DOM. So what people have tried to do is they've tried to figure out the solution about what does that look like to fix that. Right? So signals are a way that that you can have a method of updating a value in JavaScript that is then able to have listeners that are are are updated whenever the value state changes. In this case, that might be the the DOM or it might be an effect.

Something that that runs whenever the state changes just kind of implicitly by the the value of the contract that's signed whenever you add a a signal on top of this.

So in Vue, that's very similar to REF, right, which is their their built in state management in Vue.

There's some differences internally in how they function, because you you have things like proxies under the hood of Vue, and Angular doesn't really have that concept. And there's different performance heuristics there, but, ultimately, they are very similar concepts in that you have a computed value in Vue, you have a ref that you update, and the computer will automatically rerun.

React, on the other hand, has much more of a manual reactivity system where if you want to update a value, you'll use useState or useReducer or something like that.

And when you update a value, you are explicitly telling it, hey. I want to go rerun anything that is is inside of this this, function or within the the listeners of that function.

I'm using listeners there for React as more of a loose term because React doesn't really have a a primitive of state that works outside of the framework.

Instead, it uses the the renderer to to track the reactivity much more than anything. Yeah. That's that's one thing that

You know, it's always a a cost trade off. The initial download of the browser versus the the subsequent downloads of each web page. Right? And then there's a there there's a challenge of of standardization.

Right? The way that signals work in, say, Angular Wes you have a a push pull Scott cold system with with the reactivity Vercel, say, like like, I'm on the TanStack team. We built out our own signals implementation called TanStackSor.

There's just a world of difference between how those 2 function, and they they have different rationales behind them, and it makes sense. Right? So it's it's definitely very interesting to see how we will standardize, but it'll also be a very powerful tool. So so I mentioned I'm on the Sanity Stack team. One of the projects I'm leading is TANstack form. And one of the the things that we're able to do because signals are are runtime agnostic, you can run them in Node or you can run them in the browser, is we can have our our, like, primitives, our reactive primitives just work whether you're server side rendering on the server or on the client. So we can do isomorphic form handling and validation, and that we get that basically for free. Like, I didn't intentionally build it out that way, but it works perfectly as if we had built it intentionally that way just because all of our our primitives were runtime agnostic.

Yeah. It's interesting that, I know that it's going to be baked into the next version of Svelte signal based Mhmm. State. So it does really feel like a convergence on that idea, which I do like. And and specifically, if it ever does get implemented browser, I'm sure in the browser or in JavaScript, I'm sure there will still be these wrappers around them in terms of, like, how that proxying works or or what special special juice they all have. But it is really, I don't Node. It's really, really, inspiring to see so many people converge around this and take different approaches, and everybody's kind of in the the same mind that it it works really well. And, Wes, you're if you like state in Svelte Node, you're gonna like it in the next release because that signal based state is is really great to work in. So, I'm I just can't wait for for that to come. Yeah. I'm I'm pretty stoked about that. I was seeing and we have a a Slack room

coming soon. I can't I can't say when, but I'm pretty pretty excited about it. And I I do wanna say to to pump my own tires here too, I have a little bit of an inside track there. And I wanna I wanna have a I got the scoop. I wanna have a course out, like, the day it's dropped to. I don't know if I'll be able to hit that, but check on the, Syntax YouTube channel for that because who Node. Right?

Yeah. So if we think about state as as a value that is stored, right, that you are able to update, There's also this bit of value in creating a a primitive that is able to take that initial state and change it in some form. Right? So, like, the most basic example might be a count and then a double of that count.

Right? You don't necessarily care about updating that double count manually because you want it to automatically be based off of that that initial count.

A more complex example might be like, man, I'm really struggling to think of a Like a like a cart. You have items in the cart. Mhmm. So so what is the total cost of all the value items in that cart? Thank you, Wes. So, you know, these ideas that that you have a reactive primitive, right, allows you to kinda piggyback off that idea and say, well, what if we use an effect? But instead of the effect being rendering to a template like the DOM, we have that effect be another bit of state that is derived from the initial bit of state.

So in Angular's new signals implementation, that's computed, so so the same in Vue. And then in React, it's more of a use memo type deal, which is kinda different because it deals with memoization, but I'm gonna I'm gonna extend a bridge and say they're they're the same. And then, of course, in in Svelte, I know that that they likely have some some similar story with runes like you guys were mentioning with Svelte five.

So it's it's definitely very cool to have that that reactive primitive be able to power more than just, cool, we're updating the dom. Well, it's Node we're updating the dom and other state and other items that then rely on that state as well.

Totally.

Mhmm.

So if we think about it, there are like, each of these frameworks shares 1 big thing in common. Right? They're component based. They allow for composition.

Right? So you might have the shopping Yarn, which the button of the shopping cart, which is in the header, which is in the application.

Right? So what you could do is you could have a global store that says something like, hey. I wanna provide the shopping cart data to the entire application and have it go from there.

Or you might have something that says, like, we have the shopping cart button and that shopping cart button only has the bit of state that contains the amount of data for the the the just the button itself. There's a couple of different ways that that you can, you know, you can go Node extreme where you're, like, super localized. Your data is just stored within 1 area. You can go super global where there's another, aspect. You can kinda go in between and use dependency injection to provide values using, like, context or provide and inject so that you can access the values between 2 different components. You can prop pass. Like, the the power of a lot of these frameworks is that they have guardrails for sure, but they have a lot of flexibility with how you provide data throughout your application depending on your needs.

Yeah. What about, like, passing children? You know, React has a concept of passing children.

The new Svelte version is quite a bit different, but can you speak a little bit about, like, what the, way to do that is in different frameworks? Are there slots or whatever and how that works?

You stole one of the keywords from me. I know. Exactly. I was gonna mention the Scott.

No. It it's it's a good highlight, though. Right? So when we build out a a bit of templating just in HTML, like ignoring the frameworks for a second, you might have an unordered list, a list item, a span, and then some text nodes. Right? So when you're doing that, you're building a tree of of structure. Right? So so you have your root node, which is your unordered list, and then you have your your children nodes and your grandchildren and whatever else. Right? You can do the same with your components.

You can have the header that has a slot or a child injection area, which allows you to then have your button that then has an icon, which then has, you know, so on and so forth. Right? And that that was the power that I was talking about earlier with these components being able to compose one another. So not only of your DOM tree, you also have your component tree, and your component tree may match 1 to 1 with your DOM tree, but then there's even concepts like portals that allow you to jump an item from one part of your component tree out to a separate part of your HTML tree.

So there's a lot of power that that we have, to be able to control, how we scaffold and, compose our our components.

So 2 of my particular favorites, because I tend to stay away from best versus worst just because I think it's all subjective. Right? I'm trying to get it out of you. I know you are. But I'm gonna remove a question that I have for you here.

Okay. So in my opinion, I I really like the the way that both React's JSX does it. And this is not specific to React. Solid does this. You can do it depending on how you use it. But Mhmm. JS allows you to pass literal values as children. So for example, in, some of the libraries I maintain, we we use that ability to pass a function.

And that function, you can then pass properties to it. You can do you can do really wild things with JSX.

Like, you can pass and add component just a number as a child, and it'll literally display the addition of 1 number and a separate number that you pass with children, which is super strange to think of. Like, instead of this component tree, it's a tree of values.

So it really requires a shift in the thought to make an API like that work cognitively.

But then there's also, like, Angular's structural directives, which are really, really Vercel, this ability to, like, dynamically load in data and then unload data and control, like, how you inject templates into another place. Like, it it you have a lot of power there even if the learning curve is really high in Angular.

Yeah. I I'm maintainer lead maintainer of the form, and then I also maintain config and store as well. Awesome. So

Yeah.

So the the there's a secret sauce there, and it's it's Tansac's store. Right? It it kinda depends. Some of the other frameworks aren't using store yet, but we're refactoring them solely to use it. But if you see a framework agnostic library, they're using something like this where in order to control your own reactivity, you have to own a reactivity primitive, whether that's a signal, whether that's, you know, an observable, some kind of data mechanism that that is able to inform the framework when to rerender, which is really backwards from application building. Right? In an application, you have state in your app that tells the framework when to rerender.

Instead, we have state outside of the the framework and even outside of the application sometimes that then tells the framework when to reenter, which is really peculiar to think about when you're building something like this.

So we have Tansac Store, which is our own framework agnostic, signals implementation.

And then we have Usstore in, like, a ton of different frameworks, just a bunch of them. And then for each framework, library that we build, you know, Angular forms or or Preact forms or whatever, we then use the the core API, which we've built in plain vanilla JavaScript, works with reactivity outside of a framework, and then we glue it back into the the reactivity of each specific framework.

And I'll ask that question first, and I have another follow-up. I I'd say it's closer to 95% vanilla, 5% adapter. Like, I think especially with the TypeScript types, like, we have a couple 100 lines of TypeScript types for form, and then we just have the same utility types that we then export and reuse in each adapter. When we wrote the Angular adapter, the biggest question was, like, what API do we want it to have for each framework? Right? And I think that that's the more cognitively challenging piece is that each of these frameworks have different capabilities. So what do we want it to look like and keep the the feel the look and feel of the the base API very similar to one another? But, yeah, I'd I'd say it's like, you know, a couple 100 lines of code in in vanilla, maybe maybe a 100 ish even lines in framework. So it's definitely 9095 to to 10 to 50%.

So we could have built our APIs. It like like, there there's nothing unique about going from framework agnostic to DOM APIs.

Like, we could have built a a fully headed solution or, like, what was the joke that Tanner and I were making recently? The leaded solution, right, of having, the the the framework built into, the Dom APIs and then have it, like, gluing code there.

Yeah. The reason why we don't wanna get into that territory often is that it kinda constrains what you can build.

Right? Like, Tansacq Form works perfectly in NativeScript or in React Native or even in Next. Js because there's no DOM APIs.

And moreover, what happens when someone wants to use a custom UI framework or they wanna use a logger to to to keep track of their forms that they have, like, pnpm SDK for? Right? So there's a lot there that's kinda like, ah, you know, it it's, we we don't wanna limit the the usage of our app or of our libraries in applications.

Yeah. So my first piece of advice is really weird and probably unpopular. It's don't do it.

Like like, kind of unironically, the more code you have, the more likely you are to introduce bugs, the more you have to maintain. And and especially when you make, like like, divergent tech stack decision making, the complexity in building this stuff just ramps up to a 100. Right? So my first advice would be, please don't do it for your own sake.

Yeah.

But let's let's put that aside, and it's like, okay. We're mega corp. We're gonna have to use 3 frameworks because, you know, we we have different reasons, and we we have different needs and whatever else. Right? I would say the first thing is try to find I think a lot of this actually starts with design and project management. Right? I was talking with the progress folks at Npm Conf about this, and and a bit of it is like, how do we get designers to get in a room together and agree that we don't need 18 shades of of a purple on a button. Right? Yeah. Or or how do we get PMs to agree that our date pickers should work consistently with one another and that their application like, how do we get the consolidation from that aspect and grow from there from a technical standpoint? So I think to start at at the decision making process is kinda crucial.

From there, you have a lot of decisions. You can use something like, web components to be able to build a framework agnostic, you know, UI component layer. You can do and and there's even integrations like LitLabs that allow you to kinda glue that back into your framework a little bit more easily.

You have what is it called? It's from Builder. Io, Mitosis that allows you to build out 1 template that then compiles to multiple different frameworks.

So there's a lot of different technical solutions once you have that that base, business decision making to go off of.

Yeah. Well, since you probably have to test in all kinds of frameworks, and I I know you're, you know, the framework field guide guy the framework field guy.

There has to be something in one of the frameworks that irks you more than anything else in any of the other frameworks. Is there a pinpoint that you've hit where you're you're just like, why, comparatively?

Yeah. So so the the one fine. The one that I have.

View, please work on your directives. They are so limited in what they can do. Like, I wanna be able to build, like, conditional UI using your your, directives, and the the the API for directives isn't very easy to make type safe, and it's I don't know. It it's like a a bit of a sore spot because I love directives as as, you know, a past Angular developer and and even, like like, for an Angular lover. Right? Like like, components are directives, and that's just not the case in Vue. It or at least it doesn't feel that way in terms of their APIs.

Work. I have to rephrase that question to get you to answer it.

I mean, not really.

Like, I found that that, like, you know, the each framework has different lengths and shortenings and whatnot.

Yeah. But I I don't find that any of them have, like, so much more boilerplate that it's overwhelming.

The only exception that I can think of that is maybe Angular's, CLI.

Their CLI is really powerful in ways that I think Vee has kind of, like, hidden away. Mhmm. And even then, Angular is starting to move towards Vite, so this problem gets solved eventually. But I think that, like, if then the minute you open the Angular Scott JSON file, you're like, woah.

There's a lot here.

But in terms of actual code that you write, I don't find that there's, like, a particular, like, boilerplate headache there. Yeah. Not even, like like, forms in React, like like, binding a variable to an input

Mhmm.

You know, I I guess so so so to answer your question, there there are headaches, right, now that I'm thinking about them, but the reason why they don't come to mind initially is that they tend to be, like, signs of malpractice.

Right? Like, when you have a a a state that has hundreds of components for your form, probably doing something wrong. Right? Maybe we should be reaching for a better abstraction or a better tool whether it's in house or out house. Right? So there's a lot to consider there in terms of, like, if you are running into a ton of boilerplate, I'm usually not super dry. Like, I I tend to prefer copying and pasting once or twice before we find a good abstraction to sit on. Yeah. But if you're if you are copying and pasting too much, it's usually a good sign that we should find an abstraction or or maybe a different pattern Node leverage.

across multiple renderers, something like that. The next Tansac project, Tansac outhouse. Outhouse. Yes.

Absolutely.

About web components here? We we briefly mentioned them as being like an agnostic UI layer. Do you have any thoughts on how web components fit into all of this? Sure.

I think web components are really good for, like like, base primitives, you know, buttons or text inputs or something like that. I think they tend to struggle in terms of larger applications or even a lot more complex parts of the UI. You know, there's no primitive for portals. I mean, there's no base primitive for portals. There's no base primitive for x, y, z. So especially with web components, it really is very heavily a bring your own tooling solution. You know, there's lit. There's there used to be polymer, which that, you know, kind of absolved or absorbed.

But there's you're running into the other headache of developer experience. Right? Like, a lot of people just tend to prefer or know the other tooling and they tend to have a lot nicer, you know, DX stories around them. So it's it's interesting to see how web components can fit in an organization, but also acknowledging that they tend to lack some of the power developer experience that other, tools use.

Yeah. I joke with my friends often that I'm allergic to money, and I'm I'm an open source maintainer.

Beth and I, wrote a free book.

The the the actual answer is that I grew up in a household where, you know, we we struggled in a lot of different ways. You Node, maybe not as many JS much as others, but, you know, we had to get food stamps occasionally. We had to pick between the cereal and the milk. And even now, the finances that I have have been transformative to my family's life and to my life in ways that are sometimes very private, sometimes very public. And I love working in the industry. Right? I I I joke with my friends that I would have been fired as a line cook years ago just because I lacked the the the hand eye coordination and the the time management. You know, like, I just don't have the skills to do anything outside of programming. Right? Yeah. So to be in this industry is huge for me. You Node, I I I dropped out of high school, so I I don't have the education on my side. There's there's just a lot of fighting against you going into the industry as as someone with my background. Right? And I wanna be able to to help reduce that friction as much as possible for others. You know? Now that I've made it in, how can I swing that door as open wide and and as frequently for others as I can? So that was the rationale behind the books being free. I want to help others get into the industry. I wanna help them transform their lives and help, you know, in any way that I can.

Nice. That like Wes mentioned, that that the pricing thing is very funny, but I don't think he I think he even understated how funny it is. I mean, you have that that for enterprise toggle, and it it fades in Texas JS absolutely nothing changes, still free. Tax included on the 0 tax not included on the $0. I mean, this is hilarious.

If you're out there, this is great site inspiration too if you're looking for some site inspiration. Did you design this yourself?

No. No. I I do lack the pen and paper design skills as well.

Shout out to Ed Pratty for doing the website design, and shout out to Kevin Aguilar for doing the, the illustration design for real. They they both did incredible work.

Yeah. It's sick. The whole site is is great. Real smooth. Looks great. Yeah. Super pro. Yeah. Yeah. The the color transitions took a while. If you if you scroll down from one part of the page to the other, it just changes the whole page to one color or another. That was a a really,

Yeah. In in fact, I think our tech stack is interesting, but I'll I'll answer the first question first. Yeah. So so when I structured the book in my mind, I was like, look. I Node what I wanna teach. Right? I wanna be able to teach people enough to get an application up and running and then be able to, like, sprinkle in enough that they can start contributing to open source. They can start understanding the internals, improving their performance.

So what I did is is I had a couple paragraphs written, and what I would do is I'd write a paragraph and I'd go, that reminds me I've gotta write about this. And I'd add a heading, and then I'd write a couple to do comments. And, eventually, I did this, and and as I mentioned, I ran into to 60 different headings. And I realized, oh, dear. This is gonna be quite the problem.

So from there, what I did is I thought, okay. Well, how can I group these headings together? Right? Maybe not necessarily as a single chapter, but if I do have to make these individual chapters, what is the the linear and cognitive flow that a user will go through as they're reading through the book and learning. Right? So my books make some weird decisions. It teaches use effect before it teaches use state.

Who does that? Right? That's a really weird decision.

Or it teaches useRef really early on. It teaches useEffect, like, frequently as opposed to, you know, avoiding it like like other like, people have been suggesting recently.

Yeah. So

the the idea there is that I wanted to start with I never wanted to introduce an API I couldn't explain with another API, and I never wanted to introduce an API that I hadn't shown at all before. Like, there are 2 instances in the book, and they both, like like, are daggers in my heart that I had to do it, just because I couldn't think of an of an alternative.

So I try to keep my book as as as close to a linear thought process and flow as you can.

Yeah. And I hadn't considered doing the use effect before useDate because it does feel like useDate is such a you know, you get some stuff on the screen. You whatever. But it all makes sense when you think about, hey. All of these things render in very different ways. The rendering cycle is important, especially in React. So understanding how useEffect plays into that seems like a big deal to to hit early. So, yeah, that's cool. That's it. Interesting. Yeah. About that a lot as well is

Yeah. Absolutely.

So so, yes, today, but there will be a physical edition sometime in the near future. I just Node to pony up the money to make it happen. Yeah. Yeah. Oh, yeah. I've I've actually seen some ex Amazon's print on demand. Have you have you looked into that at all? It's like There's been a few options.

Yeah. Yeah. Big time. Yeah. You should reach out to Joel Hooks if you haven't because I know he's been getting quite a bit into that area with with Sarah Drasner's book and yeah.

Yeah. Absolutely. So the tech stack we we went with was Markdown, Just plain simple markdown. No MDX. No nothing else. But then there's a question of, wait, there's tabs and there's interactivity in the book. How did you do that with markdown? Yeah. And this is where my answer goes from, like, really simple to why did you do this? So in order to to get both a a publishing pipeline that can export to an EPUB or a PDF or physical book or interactive website, what we did is we wrote custom compiler markdown a markdown compiler plug ins for Rehype and Remark Yeah. That then take custom syntax, which are made in HTML comments and transforms them in pretty major ways depending on what output you're looking to do. So our tool chain is all custom right Node, that allows you to export to multiple different formats.

But in the near future, I'm hoping to open source that as a write your own book in markdown, have it interactive, have everything else run just right out of the box.

So we're we're planning on documenting this in a much more in-depth solution. Man, those for for those you out there who haven't done this custom markdown renderer stuff, there's a lot you can do there. I I for the Vercel of tutorial site, I did kinda something similar to, like, what MDN has Wes they're trying to show the CSS different CSS tabs. And you click apply to different CSS, and you have the renderer in there.

And you can do all that with just you have, like, a little key or or something that the the renderer can pick up on, and then you can do all sorts of stuff with that. It it's really super powerful.

Yeah. Yeah. And then, you know, for the interactive website, we used Astro.

And, all the interactivity that you see on the site, with the exception of the search page, all the interactivity has no framework, no nothing like that. It's just vanilla JavaScript that we add in to to sprinkle in our activity throughout the site. Love it.

So I use WebStorm and a material I think it's pale night theme. Mhmm. So it's this, like, night Node dark shade of purple that I have. And then for font, I've always been a Furacode user, with ligatures enabled. Yeah. I like ligatures myself. Yeah. I can't believe you're a WebStorm user, and you went 52 minutes without telling us that you're a WebStorm user. That's probably

Although, Wes, the Neovim folks are getting a little rowdy. We we had a lot of comments on CJ's getting started video with the Versus Node setup, And there's like, not using Vim. Opinion disregarded.

Just like, oh, cool. Awesome.

Wow. You're very cool.

Okay. What what terminal on Shell do you use?

So I'm one of those weirdos that uses multiple different, operating systems.

So on Windows, it's a Windows terminal, and then on Mac, it's Iterm 2 even though I think it's version 3, which I found a lot of confusing.

Iterm to version 3. Yeah. Yeah. Yeah. And then, I believe on Linux, last time I used it, which is that long ago, I was using the elementary terminal.

Yeah.

Mostly Twitter, if I'm being honest.

I I, I use the mute and block buttons aggressively even when I don't actually dislike the person.

Like like, I have a lot of people who I think are authentically wonderful people that just post too much stuff that's not really related to to tech. So I'm like, okay.

Well, I wish you the best. Be muted.

You know? Yeah. But but, you know, it's funny because I have a personal account where I just go follow all those same people, just not on my main account. Mhmm. And and it's because I use you know, I I used to have, like, real troubles focusing with, like, social media and stuff, and nowadays, I I have it very, very narrowly focused on just, like, tech news and tech updates.

So that's how I'm able to, stay up to date mostly is that I found that and watching and starting a bunch of GitHub issues. GitHub's homepage is one of my favorite features that everyone hates. It's, the ability to see all the new stuff that's coming up on GitHub.

I adore, but most people are like, why is it there? I don't understand. But, like, it's such an under, yeah, it's such an underutilized resource.

I find all kinds of stuff from there. Or or, like, what's really great is if you follow a bunch of really smart people, library authors, people like Jared Palmer. Like Mhmm. Those types of people are starring a lot of repos that are maybe, like, very interesting, but nobody knows. Or like Sanity Foo, great follow.

Yeah. The you follow those types of people, and then whenever they start a repo, it just pops into your little feed, and you're like, oh, what are those people looking at? Yeah. The the starting issues also, like, following issues is is really good. Like, I got tagged in

And and the big one is the RFCs. Like, I swear I have have the major frameworks RFCs just pinned to a 2nd monitor at all time and just auto refreshing every 5 Sanity. Because as soon as they show up I mean, you you just have the galaxy brains of the universe popping up into those threads and just, like, like, spewing the smartest things that I would never think of. And I'm just like, I'm here for it. I'm ready to read. Yeah. And it gets you a good handle on what could be coming down the pipeline, especially, like, for people like, you know, the 3 of us who would probably wanna know about these things earlier rather than later. Yeah. You can know what what they're thinking Wes thought process and adding Node. RFCs because Oh, I agree. But So many people are so whiny once an API has gone through 4 years of Yeah. Back and forth. I think, where were you for 4 years if you care this much about it? Chance. Yeah. You didn't get a chance.

Yeah. My 2 biggest piece of advice, just get started and be bold.

You know, there's, there's something to be said about, you know, being respectful, of course. Right? Like, don't don't go outside and just, like, start bullying people or or thinking you're the smartest thing on Earth, but there is a bit of, you know, you don't have to have a big name to walk in the room. You don't have to have the the most stars on GitHub to come talk to people or even shoot a DM. Right? You know? Come ask us questions. Come converse with us, especially, you know, like, as content creators, I think we can all agree that having positive feedback is just awesome. Right? Like, we get so many hate comments of, like, well, you're an idiot. You've never been in the industry and blah blah like like which is just not true. Right? There's just an objective Node in there. They're just they're just insecure. Yeah. But but coming by and saying, hey. I don't understand x, y, or z, great video, whatever, is a great way to have have a a content creator even directly address what you're trying to say. It's like, hey. You know, it it is this way because the React team blah blah blah blah.

Right? That's super insightful comments that you might not be able to understand if you're getting new into the industry and looking kind of in random places.

Community is another big part of that. Right? If you can find a strong community that's supportive of you, stay in it and ask as many questions as you can. But then, yeah, just getting started. You know? I think we we have our own inhibitions, and it prevents us from moving forward. And the minute you take that 1st step forward and keep walking, eventually, you'll end up writing a book. That's how I found it anyways.

Nice.

Love that. Okay. Well, let's get into, sick picks and shameless plugs. Do you have a sick pick for us today?

I sure do. Yeah. So, my sick pick would probably be Shiki, the Sanity highlighter.

It's been working on for a long time, kinda stewing in the oven. And finally, they just released a version Node, and it's really good. It supports all the the languages and plug ins and any other features you could ever want.

into my code examples, and, like, it's super Vercel, and it works really well. Yeah. And that little demo is pretty convincing right there at the the Node page, so,

Please come read the framework field guide.

I I spent 2 years writing it and updating the website that that is published on, all that good stuff. We have a community called Unicorn Utterances. So if you go to unicorn utterances.com, we have a Discord community where we'd love to help newcomers out. We're always looking for either new contributors or just people to come join us and hang out and ask questions.

So we're happy to to help, however, again, whether you're reading the book or not.

Sick. Cool. Well, it's been it's been a blast to have you on here. It's definitely got a lot out of this. All frameworks included and just in general, man. You've been working on a lot of cool stuff. So Yeah. Thank you so much for coming on, Corbin. Yeah. Thank you both. Really appreciate it. Cool. Alright. We will check you later.

Peace. Peace.