How to Pick a JavaScript Framework

Welcome to Syntax. Today, we're gonna be talking about how to pick a JavaScript framework. So there's a new JavaScript framework that just came out 1 stack or or Node. It's from Nate, the guy behind Tim Magui. And anytime I'm like, one of these new frameworks comes out, I Scott, like, take a look at the docs and do a quick scan. And I I found myself being like, I'm starting to do this, like, little checklist of does it have x, y, and z? How does it approach these things? What is its its thoughts on these things? And I thought that would be kind of an interesting interesting episode Wes, like, let's let's rattle through that list of things that you you have to think about before you you dive into a framework. Because, certainly, I've been there before where you you go all in on something, and you realize, oh, crap. Like, they don't have this yet or at all, or they don't they don't like it, and I need it. So now Wes Scott a switch. So that's what we got for you today. My name is Wes. With me, as always, mister Scott Tolinski, and we got CJ on today as well. Hello, CJ.

Hello.

Howdy. I wasn't supposed to be here.

So so Yeah. I I I was going to be we have Scott. Yeah. I was going to be in in Florida, which, by the time you're listening to this, hopefully, the hurricane fizzled out. But there is a large hurricane headed to Florida, so I had to cancel all my plans. And, yeah. And, we have a couple of really sad kids who Yarn aren't going to Disney right now. So That's a bummer. Huge bummer.

Alright. Well, before we get into it, you know what, Wes? When you're picking a framework, you gotta make sure they have a Sanity integration. But let me tell you, I feel like that's hardly even a conversation considering Sentry does such an incredible job about having integrations for everything.

I it's it's kind of wild. You could find literally anything and if century themselves hasn't made it, you know, there's Node within the community whether that is, you know, Rust, JavaScript. I mean, we're talking languages, but we're also talking frameworks. They have even like a SvelteKit wizard. You just run the dang wizard and it adds all the files for you and sets you up.

And you get all that cool stuff, all the amazing features from Sanity out of the box. So all you have to do is sign up, run the wizard, or, at worst, copy and paste a few things. And one of the cool things that Sentry does is they even include all of your correct IDs and stuff in the copy and paste bubble. So you don't even have to go hunt down IDs when you're going to do that. So check it out. It's You wanna you wanna take a guess at how many,

specific JavaScript integrations Sentry has? Just for JavaScript. Scott for not for Kotlin or Elixir or Java Bar Go.

Oh, that was pretty good. 28. Wow. Woah. Woah. Sorry. What were you gonna guess, CJ? I was gonna guess 50. I was off. Wow. Oh, yeah.

Yeah. That's a lot. 28.

Yeah. That's that's quite a few.

So let's let's get into it. Oh, wait. Before that, head on over to century.ioforward/ syntax, and I think it's 2 months free. By the way, when you do that, you do have to use the coupon code tasty treat, all lowercase, all one word. We had some folks saying that it was only giving you 14 days. It says on the page you gotta use tasty treat, but that's easy to miss. So, use Node coupon code tasty treat, and you'll get those 2 months for free. Alright. Let's get on into I thought, like, let's start off talking about what is what is a framework. Right? Like, we're we're only talking today about, like, JavaScript frameworks. But in that realm, what is a JavaScript framework, and and what is a library? CJ, what do you think?

I consider a framework something that's all inclusive. Right? Like, a lot of times, something might call itself a framework, but then you need to do one specific thing, and you gotta go install another library or another package. So, for me, if I can get a lot of stuff done without having to reach for other packages, I would consider the thing I'm working in a framework.

Yeah. Like, if you could sit down and build a application with the base things, like like, I'm thinking, like, routing, What what are what are some of, like, those other basic things that would make a, like, a router is is probably the biggest one. Like, maybe a Scott management is is another one.

Yeah. I mean, we're gonna hit a lot of these in this episode.

But if if if I wanna be I wanna be a little controversial here, I am going to take the stance that I don't believe a framework is a framework without auth in the database or at least some sort of solution for that. For me, everything else is just kind of like a pre framework. It is a a tool to build things, you know, like, I wouldn't consider Next. JS or SvelteKit even a framework granted you can build websites. But, like, with those tools, you're always having to tack on, you know, 10 additional choices of your own. And to me, a framework is something more like Rails that, or Django or any of these things that do more of it for you.

Interesting. Okay. So let's give a cup a couple quick examples of of what they are so people are listening.

In the React JS space, there is obviously, Next JS is is an example of 1. We have the 10 stack start is another example.

We have Remix.

What else do we have in the space? There's

There's next. Re I mean, even you could even say Vite react or

Not really. Adonis? The yeah. Adonis is is a good example of Node. That that one's even probably fits your criteria of it includes absolutely everything. You know? And then at a certain point, it yeah. At a certain point, it moves into, like, being, like, a almost a CMS. Right?

Yeah. And, Redwood is another good one because that that also has opinions about, like, using GraphQL. So, like, they choose your

whole system of working with data for you. Yeah. I fired up Redwood the other day because they now have their server component thing in action Because, like, there's not a lot of frameworks are, like, rolling out support for React server components just yet or at all. You Node? They're kinda like, I'm not sure about it. You know? That's kind of this weird spot right now. So Redwood JS is one of the, I guess, I think the 3rd one to implement it. It's still super early. Like, it's probably not even worth worth trying just yet, especially if you're gonna think about running in production, but I did get it up and running and and tested it out. Yeah. For me, Wes, the the distinction between a CMS

and a framework there is that a framework to me includes the database and the ORM.

Right? But a CMS includes the UI.

That to me is like admin interface.

That to me is where the line is drawn. Because if I look at even something like pocket Bos, which is just the back end, that to me is still not even a CMS in my mind because I I might be comfortable giving that to a client, but I'm not the same level of comfortable giving that to a client as I am with a Drupal, WordPress, Ghost, any of those things back ends that are, you know, definitive CMSs.

What would you consider pocket based then? What I know it doesn't matter. You know? Like, it doesn't matter at the end of the day, but I I kinda like talking about this stuff. It's kinda funny. Pocket based for me

is just a, like, a managed back end. It's a back end service. Engine? A data engine.

You know, the cool thing about Pocketbase is that it does include auth. It includes email.

You know, it's almost like a a data framework without the UI, like a headless data framework.

But yeah. I I that's a tough distinction. It's it's all, Yeah. It's all a pick and choose out of all of these different categories that we're gonna discuss.

Hey, San Francisco. We're gonna be in town for GitHub Universe on October 28th, and we're doing a syntax meetup. You don't have to be going to the GitHub Universe conference to meet up with us. But if you are in San Francisco, come hang out from 5 to 7 PM, October 28th. We're gonna be at the Bare Bottle beer garden in Salesforce Park. Admission is free. We're not gonna charge you, but come hang out, and you need to grab a ticket via Eventbrite. So we put the link in our socials, in the newsletter. We'll put it in the show notes as well. Come check it out. Come hang out. Scott's gonna be there. I'm gonna be there. The whole team's gonna be there. It's gonna be exciting. See you then.

Do Wes wanna go real quick into a couple examples of frameworks for Vue, Svelte, and Angular?

Yeah. Also, in the in the Vue ecosystem, there's Nuxt.

And, I guess what's nice about the the Vue ecosystem is that's kinda the the only one. We don't have a bunch of choices.

But it is nice. And they're working really hard to start to integrate things like databases and caching and some of the stuff that you would see in other,

ecosystems like in Rails or Laravel. It it seems like Nuxt is definitely trying to be that as well. Yeah. And then Svelte, same thing. I mean, there are other ways to write Svelte. You can just use it, but it's it's pretty much SvelteKit or Bos at this point, which, again, I think from the view in Svelte angles of that, it feels Node, you know, that there isn't a 1,000,000,000 options. And for Angular, there is analog JS, which I actually I don't know how ubiquitous that is in the Angular ecosystem, but it's definitely the one that I've heard of the most. Mhmm.

And then, like, outside of all of these, there's also other languages that run on JSX or run on multiple ones. Like, Astro will will use Svelte components or React components. You know? Like, it's kind of its own thing.

Seems like Astro's becoming really popular. Then there's Solid JS and Solid Scott JS another one in that space. There's Quick JS. So Solid uses JSX, so does Quick JS.

There's quite a few in the space that still use even HONO x, still use JSX, but do not use, like, React per se.

Yeah. Yeah. And I definitely I think Astro JS on a good path here. Like, it kind of seems like the great unifier, the fact that, like, you can take any framework, and, like, they have SSR. They're coming out with database solutions and routing solutions.

Yeah. Astro is is kind of, like, all inclusive or, like, the the one that bridges the gap between a lot of these frameworks. I do have to say, if I was to pick one that wasn't SvelteKit, I think it would be an easy choice for me to pick Astro.

How come?

Just because it's you can use everything in it, or just, like, the approach in general just seems to make a lot of sense? The approach in general, I like the islands. I I like that it is kind of like you're you're opting into client side where you want it, but that's not hard to do. Yeah. I I like that how co located everything is. You know, one thing that was kind of a bummer for me with Sveltekit is that before they were version 1, you used to have server code collocated in your component with a, like, a module script.

And I'm like, I don't I I think a lot of the Svelte folks didn't like that. Like, Rich specifically said he he hated that because it was, like, collocating too much. But me, personally, it saved me from having to write a whole another file for sometimes very simple Node, like, really simple stuff. And it was, like, really obvious to me that you have a 2nd script tag and this is your server stuff and this is your client stuff, But he didn't like the the commingling of of the 2. And I personally I liked it. So I I like having that kind of, like, colocation of it reminds me of PHP stuff. Right? Your UI next to your your server Yeah. Location. Also, I would like that too. I asked that. Like, when React Vercel components came out, I was like, why do we have to have a separate file for

the server bits? You know? And there's all these rules around how it works.

And the answer to that Wes, I think it's because it was too complicated for the bundler, and because it's it's also a little bit risky in terms of oh, yeah. You're just you're importing client side and Vercel side code into the same file, and you could accidentally do something you don't don't Node. So very clear distinction of that. But I'm I'm on your side, Scott. I kinda kinda would like that. Yeah. I know. Maybe it's just because I'm experienced enough to know where that that Yeah. Like, maybe if we could put, like, 8 emojis of, like, a server between the Node. You know? Like, that's how you Yarn it. Yeah. Then it's okay.

Yeah. But I think to that point, Scott, that I I feel like that's kind of why it's a good thing. Like, if you have newer developers or maybe people that aren't familiar with the JavaScript ecosystem, having the separation kind of helps draw those lines between front end and back end.

But it is more mundane to have to create a new file every time you need, like, a simple loader. Yeah.

Alright. Well, let's get into the actual questions of of what we need to answer here. The first one we have is, like, where do you wanna or or what do you need to ship, or where do you need to ship? Right? Like, probably shipping to the web is is by far the most popular, but that's not the only place where an app needs to be powered. Right? It might also be, a native app. It might be a web view. It might be a desktop application.

So specifically for people who are looking at, like, React Native, that's a big question of how much can I reuse in my React Native application, or can I simply just write it in such a way with something like or React Native Wes where I can I can reuse it? Like, a lot of the the Twitter code, a lot of Blue Sky is simply just a single code base that deploys to React Native and the web. Yeah. I mean, in in some of these things play nicer than others. Right?

I think, actually, you know, part of this discussion, you know, got kicked off because of the one, 1 stack Scott dev.

And to me, one of the most compelling things about OneStack besides the data story was that it is very focused on write once, deploy everywhere, but also, like, deploy everywhere with a native solution and not just like a Wes view. Now granted, web view apps can be fine, but, like, man, if something makes it easier for me to write React Native or write once and deploy everywhere and actually have it work well natively on those systems. That's that's pretty compelling.

Next one is how do you render it? Now there's a whole bunch of these different distinctions and the boundaries are kind of blurred here. But, you know, client side rendering, server side rendering, do you need it to be static? Do you need a combination of all 3? And largely, what these depend on is what you're shipping. Right? Does an application like, you know, like Sanity, that's a dashboard of UI things showing you your errors. Does that need to be server side rendered? Probably not. No. There there's not a whole lot of reasons why you would need that to be server side rendered. Sometimes you you'd go server side rendering for performance. But a lot of the times, it was really just, you know, so that you're not just shipping a blank HTML page. And I I do think, like, we went a little hard on the on the server side rendering story when a lot of these applications, especially ones that very well may run inside of a WebView app or something like that, they just don't need server side rendering and all of the challenges that come along with it. Now granted if you're building a site like Syntax, Syntax is an interactive site. There's a player. There's all this great navigation stuff going on, but there's also a lot of data, a lot of data that we would love to be indexed, a lot of data that we would love to exist in the HTML. That makes perfect sense to be server side rendering. And sometimes you have, what, like a product where the application is client side rendered, but the marketing pages, the about pages, the Wes, all those things are are even statically generated. So sometimes you need a combination of all these things. So something that might make it more flexible is is really nice. Like, for instance, in in SvelteKit, in a in a route by route basis, you can say this is a prerendered static route, and that gives you the flexibility to determine what is static and what's not within your app.

Yeah. That being able to, like, choose which one is server rendered, what's client rendered, which one is is prerendered. Static is is really nice because, like, back when, Gatsby started getting Jamstack was really popular, like, we realized, oh, yeah. Prerendering a lot of the stuff is is a great idea.

But, eventually, we hit this point where they go, oh, yeah. I don't want everything to be statically rendered. You know? And then the answer to that was, well, you just have to do it on the client. And and but then we're like, like, okay. Then I have to make an API, and then, this is starting to get annoying. You know? It's nice to be able to just opt in to one of these rendering or even just, like, rehydrating on the client. That's what SvelteKit does. Right? You can render it all on the client, but then you pick it up on the sorry. You can render it on the server, but then you pick it up all on the on the ESLint.

Word. Yeah. And a lot of these modern, meta frameworks, so like Next. Js, SvelteKit, they all have this Sanity even Astra have this idea of route by route route rendering. So any any route you can choose, this will be SSR. This will be CSR. I will say Wes I worked at a consultancy, like, this was kind of before the explosion of meta frameworks, and we essentially just had, like, 2 internal apps. So, like, if we needed a marketing page or SSR, that would be like WordPress, but then the internal would just be built with, like, create React app and an API.

So I will say, like, it doesn't have to include all this stuff, especially if you find a framework that maybe doesn't include the thing that you need for this one specific use case. I don't know. Build 2 apps posted on subdomains, something like that. Node often you see, like, the marketing website for a product and the actual

product itself being 2 totally separate code bases just because the overlap that they have there is is very small.

And often the marketing wants to do so many things. They wanna test stuff. They wanna try new things. They wanna do redesigns.

And that pace at which they move is or or how they move is is is too different than the actual product. Right? And it just doesn't doesn't make sense. You certainly can share stuff between between the 2, especially if you have, like, a design system, but almost always you're seeing 2 separate code bases for marketing and, and the actual product.

Yeah. A lot of times too, that's even like they need a CMS. They need different tools to publish, and they're not gonna wait for some developer to make a code for it or whatever. Yeah. Yeah.

The next 1 we have here JS, where are you deploying it to? I think, like, this story has gotten really good lately because it almost doesn't matter where you're deploying it to. Actually, I'm doing a talk in a couple days, and I'm talking about all of the different JavaScript runtimes. You Node, we've got BUN and Deno and Cloudflare Workers and, obviously, Node. And then we have Node serverless, and then we have Node that will spin up and spin down as you need it. And then we have traditional, node running on on an actual server. Right? And I Wes thinking about, like, there's so many of these runtimes, but it almost doesn't matter what you like, how you write your Node. Because if you're writing it in standard space JavaScript, obviously, there's a couple little things here and there, but even Cloudflare announced the other day they're using this thing called Unenv Mhmm. Which is part of the, like, Un JS ecosystem.

And it just, like, polyfilled, like, almost the rest of the Node APIs. And now Cloudflare JS sitting at, like, 98% node compat, which is amazing.

Yeah. I'm gonna be contradictory because you know what, Wes? I've noticed that good podcast, they always have 1 person who's like, I disagree. You know? What do you have? Disagree. No. It matters where you host. No. It doesn't. I don't I agree with you, man. It doesn't you know, every everything is, it's gotten really good in the hosting space. But one thing I will say about this hosting is is I do really enjoy the adapter pattern that a lot of frameworks are picking up where you can plug and play the adapter that you're going to use to deploy these things. Because I don't think, and, this might come off as targeted.

I don't think having your application work on 1 specific host is the right way, to do it personally.

And you're you're talking about Vercel and Next. Wes. Right? You know, like, we don't have to dance around this. Right? Everyone's talking about that.

And

Yeah. I just don't think it I don't think to me, personally, I believe in a little bit more of an open system where, like, the best experience for a framework shouldn't be tied to a specific host. Now I I get it. The the company that makes that framework, they are funding the development of that framework with their service, and I get that. That all makes sense to me. But at me, personally, I don't wanna be tied to 1 host to have the best experience to my framework.

Yeah. Yeah. And people are gonna be saying, like, well, you can run Next. Js anywhere. Right? And, like, yeah, you can run it as a node Vercel. But I think what where the lines start to get blurred is that so many of Next. Wes features are tied to infrastructure.

And if you want to be able to replicate those nice features, it can be really hard. Right? And, like, even Cloudflare came out the other day. They are moving their cloud like, Cloudflare had a Next. Js adapter called Next on Pages, and it worked pretty good. I run our website on it, but there's still some spots here and there that were were kind of frustrating.

And it looks like they're they're moving over to I think warp they funding OpenNext, something like that, where they're they're trying to get it to just work properly Yeah. Which is Dax's thing. We had Dax on the podcast. He runs this thing called OpenNext, and, we're trying to get Next. Js to run as Node different serverless platforms. Right? Hosting Next. Js on a on a node platform is is relatively easy. I do that as well. Yeah. Bored.

I think in general, like, just the adapter pattern itself is a really good software architecture pattern. Like, we've known this for the longest time. I mean, Vercel only came about, I guess, like, the last 10 years or so. But for the longest time, you wanna write your stuff in a more agnostic way. So when things change, when hardware changes, like, you're you don't have to do as as many updates. And so these frameworks that support adapters like SvelteKit, and Nuxt, and I've been working with HONA. Node JS a back end framework. It's not necessarily rendering, but they have adapters for all the runtimes. And so you write your code in a runtime agnostic way and then just plug in the adapter, and I think that's that's definitely the way to go.

And the way that those adapters work, we should say, is that when you run a, like, a CI to build your website, the adapter will determine what the output looks like. You know? Like, oh, is there a folder called net underscore Netlify, and there's a functions inside of that? You know? Or does the pattern look a little bit different? And, also, does the code need to be polyfilled or transpiled in any way so that it runs on that specifically? Cloudflare, usually has a little bit of weird things with their bindings, trying to be able to hook it up to the database.

So the the adapter pattern will often take care of a lot of that, and I agree. That's that's the way to go. Yeah. Well, one thing last thing I'll add to that is, yes, this adapter product works, but also you do have to be careful of, like, web standards. So I've been fighting this because I'm trying to get HONO deployed to a bunch of different places. But because I didn't use import extensions, which is a web standard, like, when you're, importing modules, you need to include that Scott JS. If you don't, then you need you need a build step to do it.

So that's the Node caveat there is, like, you gotta make sure you're doing all the web standard stuff. Yeah. I'm. That's the story of my life is I'm preaching web standards until

there's something that I wanna do, like import, CSS as raw text.

And, oh, Vite does that. That's not standard. Or use TypeScript. That's not standard.

Yeah. But I also want those things as well.

So I think Vite's doing a lot in this this ecosystem where it's like, yeah, right to 90% standards, and then Deno will take care of the the rest of the the funky stuff. Yeah.

The next question we have JS, how do you store data? So there's a lot of different ways to do this. And 1 question I'd also ask is, do you have an existing API? So this is how I've built a lot of the applications in my career is we have a separate back end. Right? The API already exists. There's potentially a separate team or a separate product that's working on that, and it's our job to kind of build the front end and and integrate with it. And so in those scenarios, I wouldn't necessarily need a a back end first framework to to build my app with.

And then also you have to think about the the kind of APIs. Right? So is it GraphQL? Is it REST? Is it something else like gRPC? In that case, does the framework have an adapter or or a library that's gonna support working with those kinds of existing APIs?

Yeah. You see a lot of people being like, well, I don't I don't want all of this full stack framework because, like, we have a team that runs our API, and it's a Python app, and it's it's been around for 10 years. We just wanna be able to build an interface for for that application. Right? And if that's the case, then, yeah, you can you can still do server rendered and and fetch that data on the server. But for a lot of those people, it's it's not necessary. They have all everything in place, all the auth, all the rate limiting. They wanna go straight from the client directly to,

the API. Exactly. Yeah. To me, this is a question of what the greenfield JS like here. If if your app is, like, you know, brand new, you you, you know, potentially just need an API or you need it tightly integrated, whatever. But if if it is a brand new greenfield app, I typically want the framework to do more for me. And if it's an existing API Mhmm. I will want it to do less for me because, yes, I already have auth. I already have an API. I already have all this data stuff. And all I wanna do is fetch this stuff either for server or for client and interact with it on my UI. But, yeah. I mean, there's a lot of different choices here. If it's an existing API, is it GraphQL? And if you are picking GraphQL, does it make sense to pick a framework that integrates tightly with Wes or vice versa? You know, integrated server, is your data loading via RPC? Like, maybe you're using even something like tRPC to make that that boundary a little bit blurrier.

Is it is it a Wes Bos, system? Do you need a GraphQL based system and have it run on your own server? Or do you need to have a separate one? There's all these choices, that you need to make. And even as far as that, we we get ESLint, like, database.

Does your framework include a database? How many how many actual frameworks these days included a database Bos at least database adapters? And typically, that's just like Node ORM. Right? I think that might be a better better thing to say here. Does it include an ORM? Do you need to fetch this data from your server or from the client? You you might you know, fetching data from the client often looks like what you're using something like Supabase.

You sign up. You create your database.

And then you're basically doing subscriptions or calls from the client side for all of your data transactions.

And then the last 1 we have, which is something I'd been checking on all of these new frameworks that come out, is does it have RPC or or server actions or server functions or form actions? They're called something in every single framework, but, essentially, what it is is can you call server code from the client either programmatically, like Wes you click on a button, or via a form submit? And, like, what does that look like? So Astro now has that. It just rolled out just under a month ago, which is pretty cool.

I was look that's one thing I looked up on. Node one is they don't have that at the moment.

The 10 stack start stuff is looking really cool. They have that pretty much, I would say, most of these frameworks are starting to implement some sort of so even if it's not a React server components, it's some way to call server code from the client and pass data back and forth. And the benefit to that is that you don't have to set up a whole endpoint and be able to alright. What parameters is it gonna gonna run and whatever? You simply just define your function in 1 file, and then you can call that function in another file. All the types flow all the way through. SvelteKit does a beautiful job at this type of stuff to to a point where it's like, if you need to code a quick feature into the website in ESLint syntax, it's, like, so easy because it's like, oh, yeah. I just make a folder. I got my I got my Svelte component here, and then I have a server JS thing here where I can implement my endpoints, and and they can just call each other. Yeah. And I even to go along with that, Wes, is can you write endpoints

in this framework? Because, you know, a lot of frameworks, you might not even have that server side component. Or for me even, like, I have an app that is my habit tracker. It's a client side rendered app. And you might think you do not need endpoints for a client side rendered app. But you know what? I also run sync endpoints from that app for my my data service. And even if my app is only running client side, itself on, like, let's say, a native app. Like, I have, like, a a Tori, WebView app. The server is not running on that device at all, but it is still making sync calls to a server that exists that's in the same code base and actually the same app that I'm deploying to the web version of the app. So, like, can you write your API within your application and not have it be directly tied to the application itself?

I I can't stop thinking about when we had Tanner on the other day, and he thinks he said, like, like, why do you even need API endpoints? Can your route just return JSON? Like, isn't that what an endpoint is? And I I it can either return a component or it can return JSON. I thought, oh, that's that's actually, that's a good point. I guess the the other thing you need to think about there is, like, it does have middleware, you know, and and what does the middleware story look like? That's my my biggest beef with Next. Js JS the middleware story is not good, in my opinion. I much prefer something like the express middleware or Node, like, who knows middleware is much better in my opinion.

Yeah. I had that same experience with Next. Js for like, literally, you can only have 1 middleware file. And so if you wanna do custom things based on route, like, the code gets really messy, and,

it was not great to work with. I asked some of the authors of the middleware of of why they did it that way, and they said they initially built it the way that we're talking. Like, I want every route to have its own middleware, but they said that it was hard to stack them together. It's it I think it is a little bit more tricky when you are using route based, sorry, file based routing Vercel, like, a, like, a defined route in your code.

Yeah. So sorry. Go go ahead. No. It's okay. But, I mean, on that point, like, that's another kind of, like, gripe I had with Next. Js. I think I'm getting used to it, but the idea that you can't even get access to the request inside of a server component. Like, they have helpers to get headers or to get cookies, but, like, every other framework I've ever used JS, like, okay. You get the context. Right? This is this is request based. There's an an a a HTTP request came into my app in order for me to for me to be able to render this thing, but I can't access it.

And so, like, they have the reasons around it, but it is definitely a little bit more cumbersome when you're trying to get access to those kinds of things. But one thing I wanted to add that Scott talked about in terms of, like, Greenfield, I think the JavaScript ecosystem and JavaScript developers potentially get a lot of flack from people outside the ecosystem. Like, why are you building your back end in JS? But I think that's one of the beautiful things is this idea of being able to call the code with just a just a function call. Because with the RPC, and later on, we're gonna talk about, like, type safety, like, literally, you're the the dev experience is super fast. Right? You can literally write a function and then just call it directly in your client side Node. And then when it all gets deployed and everything, it's in a nice and secure way. It's living as an API function. It's potentially living as client side code. And so that's one of the things you really can't get if you do build things completely separate. You're gonna have some sort of way that you have to share types or copy pasting of code. And Wes you decide to use one of these, like, full stack meta frameworks, that's one of the biggest benefits. It's like the dev experience of working with both the client and the server in such a a tight tightly coupled way. That's so good. And, like, if you have a dependency that's, like, huge or you're like, I don't want to do this on the ESLint, like, I want highlighting code is is a great example. Yeah. Code highlighters in on the client are super

heavy. They have to download the whole, code highlighting library. You have to download every like, if you have CSS, JavaScript, HTML on the page, oh, that's 3 different highlighters that has to that go ahead and then download. And then it has to do the parsing of it. You know? You could just put all of that on the server. Do it all on server. You can cache it really easily and then simply just just deliver HTML with some classes on it.

Yeah. I know JavaScript haters don't understand just how nice it is to have that kind of interop between your your server and your client and just have it be so well connected types, even Node, like, no context switching, naming conventions, all that stuff. You don't wanna worry about multiple languages or whatever, one code base, even Node process, whatever. It's it's it is such a good experience, and that's why I choose to to write JavaScript on the server personally.

The problem with that is we're just in this world where there is no complete solution tip to tail. Is tip to tail how they say that was? You would know. Right? Yeah. Tip tip to tail or

snout to tip yeah. I think it's tip to tail. We I usually goof these up, so let's let's look it up. Tip to tail method of adding vectors and crews drawing the 1st vector on a graph. No.

I usually say soup to nuts. Soup to nuts. Yeah. I don't I don't understand that one.

Soup to, soup to nuts is an American English idiom that conveys the meaning of from beginning to end to drive from the description of a full course dinner.

Soup to nuts may refer to soup to nuts film, but who's having Nuts. JS nuts the last thing you have in a meal?

Maybe that's what people used to do at, like, super fancy meals or something. I don't know. Yeah. Yeah. I'm soup to,

soup to cookie.

I don't know.

No. Soup to cake.

Soup to cake. There you go.

Auth, do you need authentication? This is an odd one that is I'm surprised it's not in a lot of the framework. So we have Redwood JS has auth built in.

Adonis JS has has auth built in. And we Wes were talking on Twitter the other day about Adonis JS just as as an aside. You know? Like, when we had the Taylor Atwell episode out, we asked, like, why is there no Laravel for JavaScript? And a lot of people came out and said, Adonis JS is the move. You know? And and, like, Redwood is also kind of in that space. And then I I have the Wes is like, why aren't they more popular, though? You know? Like, do you guys actually have any any thoughts on that?

I think people just like their tools, and you look at something like Adonis or any of these things that make all these choices for you. Like, if I look at these things, I say, can I use Svelte with this? Which, like, I think I know that's, like, a ridiculous thing because we will just suck it up, use JSX, use React, whatever.

But it matters to me. I don't want to. And I have that choice. So, therefore, I'm gonna make myself suffer by using, smaller bespoke tools instead of something that's more complete. But I just do think it's people like their tools and everything like that. Or here's the thing, just things have taken hold in the meta, whether that is, you know, the frameworks of choice here and there, and some things haven't. And because those things haven't, the jobs aren't there, or the tutorials aren't there, or the hype isn't there for some specific reason. And therefore Mhmm. It just hasn't caught on. Sanity could be a number of, like, really inconsequential Wes, like, not inconsequential, but really mundane and and dumb things like hype that,

cause something to to not work or not not take on that way. And I think it comes down to just the sheer number of options.

Like, one one thing about the JavaScript ecosystem is, like, because we're writing JavaScript, typically, you see the source. Like, it it it's source visible by design, like, even when you're publishing something to NPM.

And so with the, like, explosion of NPM and NPM packages, like, there's just so many choices, and everyone has another opinion, so they just fork a library and, like, write their own version.

And so, like, that's that's kind of what we're up against. I mean, I think, like, there are I think it kind of, like, takes someone who has experience or who has opinions that at least other people can get behind to make those decisions? Because I think that's kind of what happened with Laravel and Taylor Otwell. Like, he made those decisions up front. People trust him, and now it's the way to go.

But, like, if you look at Adonis JS, like I mean, I'm not super familiar with it, but, I mean,

what choices has it made? Like, are are there any popular choices? Back end framework. Yeah. It's been around for a long time. It doesn't make any decisions on the client side. So it it is Laravel in that regard that it's all client rendered, and then you can use whatever or sorry. It's all server rendered. You can use whatever you want on the client. But but even Redwood JS, I've been kinda rooting for them to to pick up a bit more steam.

But, I I think the I think it JS, at the end of the day, is I want an opinionated JavaScript framework as long as it's my opinions at the moment. That's right. Yes. That's exactly right, Wes. That's exactly how I feel. One thing I I re one reason I think that people don't, or that, like, auth doesn't get built deeply into a lot of frameworks Yeah. Is just the basis of a lot of these frameworks don't come with an ORM.

If they came with an ORM, then auth would be trivial to add because, an ORM, you know, connects to the database, and and that's really the big thing JS you need to adapt to whatever database the person wants to use. Or because if you if you lock on to something like meteor died because they built so tightly into MongoDB.

They built so tightly into MongoDB that people would who didn't accept that just totally, you know, left it or moved away or whatever. But if they would have at some point been able to write an adapter that worked for, you know, Postgres or MySQL or whatever, I think people would have stuck around a lot more to these things. So you need an ORM that's flexible enough, and that then would have the ability to have, like, a a smooth auth experience.

As far as auth packages and things go, there's a number of things if you're in the the NextEcosystem Auth JS.

Lucia was a good option, but recently, I saw the maintainer announced end of life, which to me, I don't necessarily

understand. I can't figure out why. I think yeah. He actually touched on it, Scott. One of his biggest points was maintaining the database adapters was the biggest amount of time spent, and he didn't wanna spend that time anymore.

To me, that's that's not that valid because the auth stuff really exists and that you have like, he has a number of his own, like, little tools. Right? Yeah. But that's where the the the stuff that people need in the off things. I I wrote my own off package I called drop off. And to me, the adapters portion is really super small, And the adapters portion is is just like, alright. You've done the comparison. Now all I need to do is save the data to the database. So the adapter portion is just saving that information to the database. The problem with tools like Lucia is that they wanted to be everything to everyone.

They wanted to to support how everyone did their auth instead of being opinionated.

These are the fields. These are the auth methods, whatever.

And when I tried to use Lucia, I was like, there's too many things that I have to do personally here. It feels like I'm writing my own auth Wes I would prefer something that makes more decisions for me and is a little bit more wrapped up in there without having to, like, support a 1000000000 adapters for a 1000000000 different things. Yeah.

Yeah. That was my experience with I say Lucia. I don't know if it's Lucia, but mine went to Lucia. Because it's it's based on the island, Saint Lucia, just where I went on my honeymoon. And my dog, Lucy, her name is spelled like Lucia, but it's Lucy, after the island. It's beautiful island. Oh,

awesome. Yeah. That was my experience too. Like, when I so I implemented Lucia into Sveltekit app, and then I've also tried implementing it into, like, a Node app, and I think and also Next. Js. But every time, I was just like, you've basically showed me what I kinda just wanna write this code myself. I have to Yeah. Yeah. Yeah. To do all I mean, that but that might be the point that the maintainer JS trying to make is, like, we provide we will still continue to provide these kind of utilities and examples, but it's up to you so you can adapt it to your own needs in your own database and and whatever Vercel. But that was my experience. I was like I I added it, and I was like, I could have just written this myself. But at the same time, I've done it before. Like, I know about, creating tokens or signing secrets and and stuff like that. So for people that don't, it's gonna be more of a jump to try and implement it themselves.

We I think we've said this probably a 100 times on the podcast, but, like, everyone listening, go write your own auth just once. It's not that hard. There's yeah. It's it's a really good learning experience. You'll understand how these things work, and you're also not gonna be spending a bazillion dollars on some SaaS that uses to log in.

Yeah. People feel like it's high stakes, but, like, session based auth is is really pretty simple. It's all the features that are that are like, once you start getting, oh, log in with Twitter or whatever, you you can do those. But, like, a a a simple username, password, confirm password reset link, that stuff, you could do that. Yeah. If you wanna see some examples,

on how I purchased, I did link to my hand rolled auth that I use, and it's just a really simple session based authentication, which I think is is more than enough for most people.

Here's one that we don't talk about enough is does it include email? Like Adonis JS includes an email package, which granted, you know, I just think that's nice sometimes. One of the things I love about Pocket Bos is that when I make an account on Pocket Base, it automatically sends the email. All I have to do is put in my email credentials into their UI if I wanna use a third party, you know, mailer service, which you probably do.

But, like, you just drop in those things and it automatically does all that stuff. You wanna update the templates, whatever. Meteor did that too. And in fact, if you didn't have your email creds set up within Meteor, it just output the email to the console. So when you were testing before you went live, you could just click and copy and paste from there, and it was a great experience. It it was just nice to have that baked in. Next one we have here is what does a TypeScript story look like?

I think almost all of them now allow you to simply just write TypeScript in it. It just runs, which is beautiful. Previously, you had to, like, run some sort of weird compile step on a lot of them. But, are the routes fully typed? Can you write is it possible to write a link to something that is not a route that exists? That's that's a big one. Right? Or can you get access to the parameters of a, a URL route that are those fully typed, or do you have to are are you just assuming they're there? You have to check if they're there. That's kind of annoying as well. So deep integration

with TypeScript is a major benefit to me. How does it handle images? Does it handle images? Do you just left to drop it in static, Or does there some kind of process? Or even better, like, can they handle automatically uploading images and throwing them into a folder or a bucket for you and having that all configured? So what does it do about static files, images, uploads, those types of things? Like, Yeah. Creating, like, a source set. That was the Gatsby was, like, one of the first in that space where you simply just uploaded a 18 megabyte

from your camera, and then it would just chop up and make a 1000000 different versions of your image for you. And then there's also, like Next. Js image component has some pretty good documentation on how to use stuff that's not the Vercel image. So if you wanna use, like, your own hand rolled thing or you wanna use Cloudinary, which is is what I use on a lot of my websites, there's a lot of good stories there. But just basically, like, do I have to now write this whole thing myself Mhmm. Is is a big question because images are are a hard one.

Word. And then also, what's how do we work with CSS? So we know there's a 1,000,001 ways to to work with CSS in the JavaScript ecosystem.

So for instance, like, in SvelteKit or even in, like, Nuxt or Vue, they have Scott styles by default. So you define styles in your component, and they're only scoped to that component.

But for other frameworks, especially React based, you need to use other things like CSS modules or CSS and JS and all of those various solutions, like Stylex and Panda and styled components.

And then also these days, a lot of people are are choosing to use something like Tailwind. So does it support Tailwind? And a lot of times, you need to make sure that, especially if you're doing server side rendering, there's there's some sort of mechanism there that's gonna allow Tailwind to to be included in those server rendered bundles. And then one of the things that I like to look out for because I write a lot less of my own CSS is is there good support for component libraries. If you're if you're not wanting to write all of your styles from scratch, you might wanna reach for something like, Daisy UI or or Flowbite, these things that basically give you prebuilt components.

And if you're trying to integrate those with some frameworks, they might not have the best support. So, like, if you're trying to use there's Daisy UI React. And if you try to bring that into Next. Js, every single component that tries to bring 1 in in one of those components has to be marked as a client component because the library hasn't taken that into account yet. Yeah. Yeah. That's that's a huge pain in the butt. You gotta wrap it. Every single component you have to wrap. What a Yep. I mean, I think they're trying to fix it, but, yeah, it's super annoying.

Yeah. One thing that I think I have a hard time with that other folks might in the JavaScript ecosystem JS, how long has this thing been around? Is it version pre one? If it's version pre one, I I'm like that that meme where I'm looking back at it like, oh, you Node? Like, a pre version 1, JavaScript framework? My kind of thing. But, yeah, I I I do think that it matters. Like, how many times have they had to do small rewrites, API thrash, things like that. Even with this new Svelte five stuff. I love the way Svelte five works, but I'm not stoked to have to rewrite so many apps to it. Even though the version 4 code will continue to work when you upgrade to version 5, you're not gonna wanna hang on. I I did this with React. I did this 800 times with React, and I'm I'm tired of it. So I would like some stability, please.

Yeah. Yeah. The API thrash and the breaking changes and things change JS is so frustrating at some points. Like, there's something to be said for picking older tech. You know? I have express code that I've written 10 years ago, and it still runs today. And I've I've upgraded it many, many times throughout the versions, and it's almost always like a 10, 15 minute, upgrade, where it's, like, not this huge, oh, this is how we approach it. Or, oh, yeah. We're doing it this new way, but the old way is now supported. So now you're thinking, oh, there's 2 different ways to do things. It's it's kinda frustrating.

Yeah. That's what we've done to ourselves here as as JavaScript developers. You know? We want new and exciting stuff, but we also want it to stop changing.

Yep.

But, like, on on the same point, like, what does the ecosystem look like? You Node, is there is there editor plug ins? Are there different libraries that work with it? I think the, like, whole library thing is getting a lot better with the move to people writing either writing them in vanilla and then just providing, like, a headless interface for it. Like, a lot of the tan sucks tan stack stuff is 98% vanilla JavaScript, and then there's a system that they just write, like, a React version for it to to actually integrate it. Right? And then a lot of the stuff is Node, like, web components. And okay. Well, you look at the the shoelace or the the font or web awesome stuff. Those are those new web component UI libraries that they're working on.

That's great. You Node, you don't have to, like we don't we shouldn't have to have a React specific charting library.

It should work with all the frameworks.

Yes. Yes. Yes. All of the above. Also Sanity support, which is often underlooked thing.

Do are there how many people are there in the Discord, or even better, like, how active are the discussions and forums like that? I I'm kind of over Discord as a a a tool for maintaining community, but I I get it as being like a nice thing. I I love an active community in general though, because it means that people are not just using it.

They're interested in it and excited about it and, like, wanting to talk about it, which is a Mhmm. A big thing. If people are willing to talk about their tools, it means that they're invested in their tools. Yeah. And I think also beyond that, like, I wanna make sure that I can get help when I need it. Right? So, like, are the GitHub discussions active? Are the GitHub issues active? Like, if you come across this new shiny framework and you go and you look at the GitHub issues, but none of them have been answered in a year, you're probably gonna have a hard time getting your answers, but also you might run into those same issues that those people are opening up. So we definitely wanna see active maintainers and active community members that are helping people out.

Yeah. Sometimes it's so frustrating when, like, I literally don't have anybody I can ask about this this this actual issue. And, like, the maintainer is super overwhelmed.

You Node, it shouldn't have to be the maintainer's job to also do the support. They're not gonna get anything Deno. But you also want your your questions answered. How do I do this? I'm I'm hitting this specific issue. Is it my issue? Like, so many times I've used smaller things, and I've ESLint an hour on something that's broken. And then it turns out to be a bug in the library, and it goes, oh, it wasn't it wasn't me. I thought it was.

I said sometimes it is you, though. But it's you know? Often, it is me.

Yes. It's almost always me. That's why I I default to that. Yes. Exactly.

Portability. How easily can you duck out of this thing? So we we talk a lot about web standards.

So a lot of these API requests, if you write them with standards, form data, request, response, fetch, the 98% of that JavaScript code is going to you can move it over to something else. If you oh, you know what? This isn't for me. I can still move the login route handler to something else. You know? Can you how easy is it to move your actual components? You know? With if it's going from a React framework to React framework, it's pretty easy. Most of that will move over. It's just React. If it's going from React to JSX, that's a little bit different. You gotta decide, oh, well, now all of a sudden my use Scott doesn't work. I gotta I gotta move those over to what the equivalent is.

But then if it's is it a React to something totally different? Then you gotta rewrite a lot of your components.

Word. And then finally, hiring. Does it matter to you? Quite honestly, that's why React is is still very popular. Right? There's lots of people out there that write React. There's lots of stuff built on React.

And if you need to be able to hire an expert in that type of thing, then you you will be able to do it. Granted, somebody who's good at JavaScript will be able to pick up any of these frameworks, but that's not something a lot of people look at when they're looking at what does the hiring landscape look like.

Yeah. Sick. I think that was really a a great discussion, y'all. I mean, there's so much that goes into here. If you have things specifically that you look for in a framework that we didn't mention, leave a comment below. Or heck, if any of these things that we mentioned aren't important, leave a comment below. Or what do you think a framework is? That's, like, the best question here. I think when we kick this off, I think everybody has a very different idea of a framework. Is React a library? Is a hot dog a sandwich? Any of that same old discussion.

So let us know what you think in the comments below. And how's the part of the show where we get into sick picks and shameless plugs?

CJ, did you come with a sick pick today? I completely forgot, but I'm just looking around my Wes, and I have one. It is the Classic. It's I mean, it's a cassette, but, it is, the latest album by Tyco. It's called Infinite Health.

And he JS, well, they are. It's it's 1 artist, but he he tours with a band. It's, instrumental music, great for programming too, great for getting stuff Deno, but the latest album is often awesome. I've I've had this on repeat. Infinite Health by Tyco.

Did you know that I used to work for Ghostly International?

We talked about that. Yeah. That's awesome.

Yeah. Tycho is on Ghostly. I don't know if he still JS. They were.

Yeah. I think he's on

something oh, mom and pop. He was. I think his latest stuff hasn't been released on there. Yeah. I'm ghostly for a while, but I've been a big taiko fan since, like, forever and ever and ever. And and you're so right. Sometimes that music feels like you're swimming underwater or something like that. It's it's the best. Yeah. Yeah.

I'm gonna sick pick citric acid, which do you guys know what citric acid is? Vitamin c. Yes. Vitamin c. Is it vitamin c? Oh, I didn't I didn't even know that. I I just thought it was the stuff they put on, like, Sour Patch Kids to make them sour.

But I bought a huge bag of it because we have so many things that need to be descaled in in our house. Right? You got we have a coffee maker. We have the kettle. We have this egg cooker. I just sick pick the egg cooker, actually. I've never sick picked that. We have our dishwasher.

There's a baby Brezza, which is this, like, Keurig for formula for babies. Like, there's so many things in our life that we need to descale. And I was buying this, like, really expensive descaler, and I was like, what's in this stuff that it's so expensive? And it turns out, like, you can use vinegar to descale your coffee machine and whatnot, but it's actually not great for it, especially when, like, we have a nice really nice coffee maker. I don't wanna goof it up. So I was like, I'm gonna start. I'm just gonna buy a big bag of, what's this stuff called? Citric acid. And Yeah. This stuff is amazing.

Like, I used to pour vinegar into something like our kettle that needed to be descaled, and I would just let it sit. Or, like, we have these humidifiers for the kids, and we have to pour vinegar and let it sit for, like, half a day or whatever, and then it would disintegrate.

I pour citric acid and hot water into the kettle, and, like, 3 minutes later, it was, like, gone. Just absolutely blasted. And I was like, man, why have I not been using this forever? It's relatively cheap. Get a huge bag for a couple bucks, and you you descale your life.

I wanna fact check myself. Citric acid is not vitamin c. It is similar. Ascorbic acid is vitamin CSS I'm sorry. Y'all messed that one up. But I also use citric acid for cleaning my Zojirushi Zojirushi, water cooker. And that's, like, the the way that it it comes with the cleaning pouches. So and that's super duper well.

Yeah. Anything that makes water hot will get mineral buildup over time. And and the sad thing like, I go to a lot of thrift stores, and I look at all these things people have donated.

And it's kinda sad to me because it's like, obviously, this didn't work as well anymore, so they they got a new one. And it kills me because it's like, just clean your stuff, and you're it will last longer. Yeah. I yeah, that

is quite literally a great life hack. Clean your stuff. I'm gonna say pick a, small little thing I just recently got, which makes too too much sense. If you're like me, you have a lot of little USB, like, the the old USB style thing sitting around, USB a, whatever.

And a lot of the new things, USB c. So I I just got, like, a a pack of these, USB 8, a little USB C adapters. I put them all, like, in my car USBs. Yeah. It's just itty bitty ones like that. And and they're so cheap. You can buy them a whole bunch. Oh, mine are even way smaller than that. Are they? Yeah. They're just like they're almost like they barely even stick out at all. I wish I had 1 sitting here. But they're just itty bitty. Oh, yeah. Yeah. And I like I said, I put them in my Yarn, all my car USB ports. I put them in my kitchen and, yeah, everywhere. So these things just give some extension to your, USB a ports.

I'm so excited.

I'm I'm getting a new iPhone soon, and my wife is too. And that means that aside from 1 iPad, our whole our whole life will be USB c. And, like, I've been I've been waiting for this moment, like, my entire life. And, like, I even these headphones I'm wearing are micro USB.

Mhmm. And there's a mod that you can convert them to USB c, but it's it's, like, $50. I don't know if it's worth it, but I just wanna get rid of all the u s things that are not USB c.

This is great. I'm gonna get some of these. Yeah. I know. I I I've nothing that's not USB c really anymore, so I'm way off that. So Man. Happy to be here. Shameless plugs. Check out the Syntax YouTube channel. We're on YouTube. CJ just released an awesome video at the time of recording this.

Build a documented type safe API with honed did you say hono? Hono. Hono? Node? Deno. We've been saying it wrong. I I like, I you know, it's one of those things where I've just, like I can't get it right in my brain.

Hono, Zod, Drizzle, OpenAPI, Scalar. What is Scalar, CJ?

Scalar is the interactive API documentation. So it's similar to Swagger UI, but it's a bit more modern. Like, if you've ever been to API docs and, like, you see all the endpoints, but then, like, it shows you code you can paste to, like, run it with cURL or run it with Python or whatever, Scalar gives you that. So you feed it the open API spec, and then you get interactive docs.

Sick. And the Scalar folks even commented on that video, so shout out to, Scalar.

Yeah. Cool. Well, that's all I got. You guys got anything? No? Silence from the silence from the crowd. I got nothing.

Just wrap her up.

Alright. Peace.