Welcome to another episode of Compressed FM, a podcast all about web design and development with a little bit of zest.In today's episode, we have the JavaScript cage match.
I would like to add a JavaScript death cage match, but hopefully we'll both come out alive after this.So without further ado.
Hello, my name is Amy Dutton, and I am a lead maintainer on the Redwood JS core team.Hey, y'all.My name is Brad Garropy, and I'm a senior front end developer at Stripe.
I did want to highlight our sponsor.So our sponsor today is Wix Studio.And one thing that I really appreciate about Wix is I've just traditionally thought of that as a no-code or a low-code tool for building websites.
But Wix has put a huge emphasis on developers and empowering developers.
And the cool part is we all know we're not just building websites for ourselves and having to be concerned about our own tech stack, but also the people that we're building it, the marketers, the salespeople.
And one of the things that Wix does is it allows you to use code with low code.
And so when you talk about, yeah, we have all these JavaScript frameworks, Wix Studio has a lot of these features that we're talking about, like, oh, we have to start from the beginning, it already gives you a lot of those tools to enable your teams to build things more efficiently.
So Check out Wix Studio.We are going to have, I believe, one of their founders on in a few weeks.
So we can ask them more questions, get more details about Wix Studio and just a lot of the mental models that go around their development processes and workflows.
Yeah, with Wix Studio, you can avoid this entire JavaScript framework conversation.
Right.Which, you know, more literally more power to you.
Focusing on different different problems, more business problems.Don't don't waste your innovation points.Awesome.So I was at Momentum Conference in Cincinnati last week and gave a talk called the JavaScript Cage Match.
And I think my favorite part of the talk was we all got in a room and I jokingly said, OK, everybody pick your corner and lock the doors.
Little did they know.But basically I walked through six different frameworks.I walked through Svelte, Astro, Next Pages, Next App, Redwood, Remix, and that's it.So mostly React frameworks.
Astro is kind of on the fringes because it could be a React framework, it could not, depending on what frontend you bring to the table, and then Svelte's kind of an outlier.But comparing and contrasting all of those things.So it was a good time.
We'll talk about each of those frameworks and kind of what they bring to the table and kind of go from there.
Yeah.Before we jump into all the different frameworks, talk about the Momentum Conference in general.I think the organizer's name is... Why do I want to say Michael?
I think I met him at... Yes, it is Michael.Michael Richardson.He is amazing.It was a great conference.I think what surprised me is that Cincinnati is a tech hub, but like a different kind of tech hub.
in the sense of Kroger is based out of Cincinnati.Yes, I think 5th 3rd the bank is based out of Cincinnati.
They were also a major sponsor, so you have these companies that might not necessarily think of as tech companies, but technology does play a huge role in the company and they are based out of Cincinnati.
So the sponsors were not like the typical indie Twitter, right? Vercel Cloudinary, you know, all these other ones that you typically see.It was like big corporations.
Yeah, it's funny.There's like bubbles that are tech for tech, like hosting companies and DevTools companies.And then there's like tech in industry, which is just like literally everything else.
That's right.And they were all there.And I'm assuming they were there more for like recruiting purposes to be like, Hey, come work here.
And this conference was a little bit different in two ways.One, I went not with somebody, but I've done enough conferences that I went and there were friends there. which is like such a great feeling.
So our good friend Taylor Dessin was there, which we talked about multiple times, actually lives here in Nashville.I'm from Nashville, but we've never hung out together in Nashville.We just see each other in different cities or at the airport.
And then Alex, Oh, what is his last name?He lives in Atlanta.He's been to that conference.Have you met him?He has blue hair. He is a view developer.So I didn't talk about view in a particular talk that I gave, but he is really big on CSS.
So I think all the talks that I've heard him give he talks about CSS.
Okay.Yep.I remember the talk now.Yep.
Yeah. One thing that Momentum did that I've never experienced when I've gone to a conference, which I really appreciate, was they had a speaker feedback system.And so you could opt into it.You didn't have to receive feedback.
But they only asked if you are going to opt in to get feedback, we ask that you attend at least two sessions and provide feedback to those two sessions.
So I attended Alex and gave feedback to him just because I wanted to be there to support him.So that was easy.And then I attended a tech leadership talk, which I really appreciated the guy that gave the talk.
He focused not only on the tech track leadership, but also people leadership, because there are basically two tracks as you become more senior.And it's important to recognize both.
Yeah, I think the people leadership aspect of that is definitely the tougher of the two.
Well, my dad, when I got into management at Zeal, he was like, The dirty secret of management is that it's really an HR job, which you're doing a lot of managing people's emotions, not just work.
But anyways, I enjoy helping a group rally around a particular thing or a particular project.So It was good.But so what I want to say about Alex's talk was he's talking about the latest and greatest features in CSS.
And a lot of them I'd already heard about, but there were still things that I learned in his talk.So I appreciated that he kind of had something for everyone.
And some of the stuff, this is the only thing about being in tech for so long is I can get away with a lot of my previous knowledge with CSS, but there's so much stuff that's been added lately.
In fact, I think he said there's like 500 properties that have been added within the last two or three years.
you don't know until you run across a use case.Like the first time I used has, I was just like, you know, whatever, I'm writing some CSS, I'm like, this seems difficult.And then I took a step back.
And I was like, Oh, my gosh, this is what has is for.And all of a sudden, this really complex selector that probably wouldn't work in some use cases, just melts away to this nice, easy little has statement.
Yeah, so my favorite takeaway, the thing that I did not know that I learned is that he made the point CSS is a typed language, which I don't really think about, but you can't put, say, like if you have color, you can't give it a pixel value and say it's 50 pixels.
Or if you have width, you can't give it a hexadecimal value.That's not gonna work.So if you create a custom property, so what that looks like is basically a variable within CSS, you can actually define those types
So that when you're working within like the browser and looking at those things, it will prompt you and tell you like, no, that's an invalid input, which I had no idea you could do.That's pretty awesome.
Yeah, Adam Argo loves to like flex on that, like the number of units that are in CSS, and that it's actually typed.
Now what we need is like a really cool, like, and I don't think this exists, but like a, like a type linter for CSS, where it's like, yo, you're not putting the right thing in here.
And I should have asked, what are things that you still feel like CSS is missing?
Because I'm like, you can almost do everything masonry, we got masonry, and we got the the parent selector, which, like, that's, that's pretty much it.
queries are pretty awesome.
Like, I'm not sure that there's anything I really, like I need this.
And I don't feel like I also don't design like the most craziest websites.It's like I just don't feel like I'm reaching for a lot of these advanced features, you know, and I'm just like, this is great.One day I might need them.
But today is just not really tailwind.And all the utility classes pretty much suffice for me at this point.
Yeah, I don't think I've designed some crazy stuff and built it.But there's not too much.I feel like more of the innovation stuff happens on the design side.Yeah, that you're plugging in.I've never, at least recently, I haven't designed stuff.
But also I know enough code that I know what I can and can't design.So I don't know, maybe it's not an issue.But yeah, I'm happy with the state of things.
So let's let's transition into your talk.Before we get into every single framework.How do you think it went?How was the reception?
So it's a lot of ground to cover.
I had 50 minutes and I'm giving the same talk at Connect Tech next month in Atlanta.So I'm really looking forward to like being able to tighten things up a little bit.It's a lot of content when you're talking about six different frameworks.
And so the good thing about having a friend in the room because Alex did come to the talk is was like, be honest with me.You're not going to hurt my feelings.Just tell me like what can be better.
because there were moments where I felt like next can do this next app can do this or Redwood does this Astro looks like this and it just felt like so much material to get through.
where I felt the better parts were parts where I had stories where I'm like, this is the use case that I have for this.And let's talk about how this applies to your code or when you might reach for this particular tool.
Towards the end of the talk, I did have a few charts where I just like kind of laid out, here's what you get with each one.And I can talk about that a little bit too, but this felt a little bit more
I don't know, easier to talk about, easier to follow.I just wasn't sure how many people in the room followed all the examples.It was just, it was a lot of content.So just trying to make it more cohesive.
You almost need to set the baseline of like, yeah, yeah, yeah, this is what they all do the same.Let's talk about what makes them interesting, you know?
Yeah, yeah.And when you might reach for one over the other. And, you know, I work on Redwood full time.
So and I made that very clear at the beginning and I kind of pitched Redwood and I was like, OK, I don't I don't want this to be a commercial for Redwood.I mean, that's not why you guys came to the talk.
Let's talk about all these other things and why you might reach for them.And there are instances where I prefer to reach for Astro or I prefer to reach for Remix.Like the compressed website, for example, is built on Remix.Like why?Why do that?
What are the things that it offers in those contexts that make more sense?And I think, you know, that's really been, my exploration has really been twofold.It's been one, I think rising tide lifts all boats.
So what can Redwood specifically learn from these other frameworks, but also have more tools in your tool chest.So you're not always reaching for a hammer when you need a screwdriver, like let's figure out what's the best tool for the job.
Yeah.All right.Well, let's let's get into it.I mean, I can't wait to hear I, you know, baseline for me, I've got react experience, remix experience, some spelt experience, some astro experience as well.
What else we go next, but not the app router, just the pages router.What am I missing?
You haven't read redwood.
I think I did like a starter and like that's about it.
Okay, and this is interesting too.So maybe let's just start here when you talk about baselines and what all the frameworks do.
There's been a talk, I guess that was maybe around April and May, online, where everybody was like, we want the Laravel framework for JavaScript.And like we did, we recorded episodes on those things.And the conversation was just fascinating to me.
It was kind of coming out of React Conf. And I feel like in some ways Redwood has tried to be that.Like if you go to Laravel's homepage and look at their feature set, Redwood actually offers most of that out of the box.
We have background jobs built in.I don't know of any other JavaScript framework that offers background jobs.
No, save Redwood like everybody else is just, hey, we'll give you like a server action maybe but like and routing, but like that's about it.Nothing else on the back end.
Yep.But the other side of it is we also have we haven't really announced this, but we have storage and file system built in.Wow. Yeah, which is pretty cool.We just kind of wrapped all that stuff in.
So we snuck in the feature and then the developer that was working on it took a sabbatical.So then we had another developer come in and like refine and tighten all of it.
I believe last week he released some example code for 15 different use cases of how you might want to use uploads. and file systems.So I'll find a link to that.But I'm like, I love that kind of development to where you're like, this is my use case.
Now we're going to make sure that the framework supports that use case and what that looks like.
Does it work?Like when you get into stuff like that, you have to think about runtimes.Does it work everywhere, right?Because Cloudflare, it's not going to work.Like, you know, things that don't have things that are serverless, essentially.
Right, right.Well, and this is kind of interesting, too.A lot of the decisions that we've made lately, we're been like, OK, let's do this more like from a server full environment like background jobs.You need a server.You can hack it.
You can have another server ping like Vercel to run the jobs.But it really is better if you have complete control over the environment.You have a little bit more flexibility there.
So I'd say the same is true for the stuff that we're doing with file system and storage.
The first developer kind of went deep into this path, and this is also why we had another developer on the team kind of revamp and re-explore with these use cases.
You can store an image as base64, which gives you this huge chunk string that nobody could possibly read.And since we're GraphQL, you could just store that string inside GraphQL, like inside your database.
Then you get to situations where you're like bloating the database with these huge base 64 things.You can't really manipulate the image if you want to deliver different sizes and things like that.So that's why we came up with all those use cases.
But I'm just saying like when you have GraphQL as your backend, there's some pretty interesting things that you can do with that.So we have Auth out of the box, which I don't think
Unless you want to reach for like one of Kent's epic web, you don't have off out of the box with anything else.We have testing out of the box like you don't have to do anything to configure that we have form validation out of the box.
So we have Mailer, too, which is pretty awesome, and Redwood Studio.
So Redwood Studio will let you preview your emails when you're in dev mode, or you can also run telemetry and performance stuff so you can see, like, when you're working with GraphQL, do you have M plus one, or why are these queries taking so long?
You can see graphs for all of that stuff.Anyways, that's my pitch for Redwood, and why you might go with Redwood.I think it's really great if you're trying to build an application. But here's the caveat, it is a SPA right now.
We're still working on that RSC SSR piece of it.And so if it's a app hidden by a login, you don't have to have SEO.You're not gonna have things unfurl.It makes sense, like SPA is great.
But if you're trying to do an application that you're sharing links with people, you want things to unfurl, you're trying to be mindful of load times and performance, things like that on each query, might not be the best thing.
Yeah, I'm going to answer that question that you kind of post the beginning of like, what is a framework?Because I think I think that's going to reveal a lot, like at a minimum, in my opinion, a framework is some kind of a view library, right?
React, or Svelte, let's say it's like no pun intended, not view v u e. Yeah, some kind of a like a like a UI library for rendering HTML, some kind of a router,
And then some way to perform actions on the server to load data to update data and like do a mutation.That's that's as small, I think, as a framework can be.
And it didn't used to be that way, like create react at people were like, this is almost like a react framework. hardly, right?But now that we're taking the server into consideration, frameworks now kind of have to address both sides.
And what's interesting is that a lot of these meta frameworks, a lot of the frameworks that you're comparing, start from a different place.A lot of them are kind of starting from server side now.
Next.js does, Remix does, and one that kind of is breaking the mold that
Your talk didn't actually capture which now maybe we should consider it is tan stack start that that is actually coming from the client side So the way he built it starts it starts at the client, which is interesting but yeah, that's what I think a framework should be like the smallest bit of a framework should be and
Yeah, what I really want, though, is like, typically, you want to expand a little bit more in both directions.So on the front end, you kind of want to see like, hey, give me a mocking solution.
For the front end, you want probably like some kind of a form library or form validation.
And on the back end side, you just want like a ton of utilities for a server full environment, how to send emails, how to do background jobs, how to handle image uploads and storing them, things like that.
But like you start at the middle with your base set of features and then slowly work out.And I think that's what we're saying is like nobody has covered the full gamut of both actually to save Redwood who's gotten the closest, right?
Right, right.So there's two points I would add.When you talk about what is a framework, you hit everything that I covered in the talk because I did answer that question.You talked about rendering data.
So that's where I kind of went into client or server or build or
Request time but that goes into what you're talking about the approaches i also would throw dx into that because why would you reach for a framework it has to do with the experience of that weather allows you to move faster.
Well, two things, right?It's like they made all the decisions for you.
So you didn't have to go find the libraries and stitch them all together.And two, they give you a lot of helpers.I'm like, this is how you spin up a project easy.
This is how you add a route or a component or whatever, you know, which probably means a CLI that does some things for you.
Yes, yes, yes.And then in terms of this doesn't make up the framework, but it plays in a big role when you're deciding a framework is the longevity of it.And I broke the longevity into two parts.Some of it is like, how long has it been around?
And the other side of it is where's the funding coming from?Because you want to know not only does it have the history, but also does it have the future?
Well, it's like, what were their opinions that they picked?Are they picking like bleeding edge tech that's only been out for a little bit?Are they just grabbing the new shiny stuff?
Are they really like relying on the tried and true stuff, the boring stuff almost?And I'd throw one more pillar in there.
Okay, like education, or community, essentially, like when you're using a framework, it needs to be super well documented, and it needs to have all the questions answered.That's how a framework gets popular and stays popular.
Because like, people are asking questions, the framework authors and maintainers are answering them.And you know that it'll handle anything you can throw at it, when you encounter a problem, you can get over it.
That's right.That's a really good point.So I think before we kind of go on to the next point, I think what's interesting is because we started off talking about the layerable piece of it.
And then when you look at the JavaScript ecosystem and where other frameworks have gone, a lot of them are leaning on that composability piece. Like, I just want to be able to pick what I want.Like, just let me pick all these other pieces.
And so sometimes that makes things easier, and sometimes that makes things harder.And so I'm not sure exactly what the balance is there.
Yeah, I think Wes said this on Syntax recently, and I couldn't agree more.He's like, I want a framework to be opinionated, but I want it to be my opinions.And that's why for me, I'm just currently like building my own starters.
I always build and improve my starters.And now I'm adding testing and Sentry and all this stuff to them where like now when I spin up an app, It's gonna have all of my opinions just baked in because I chose it and I put it together.
Is it wasting time?Maybe, but like I'd rather really know my stack than necessarily like jump in and completely rely on somebody else's opinions and how they did things.
Yeah, so actually, we did an episode I think was this the first time you were ever on the compressed podcast?
We did an episode with Brad.I'm going to find the number all about his productivity setup.
And it talks.So if you're like listening to Brad talk about his starter kits and like, oh, that's interesting.How does all that work?Check out this episode.It's episode 68.It is actually one of our most popular episodes.
So 68 feels like it was a long time ago.
It was April of 2022.Wow.It does feel like a long time ago.But in my mind, this episode is evergreen.All the things that you talk about still apply.They're still helpful.
Well, OK, let's start breaking them down individually.We'll talk about like, well, I guess the commonality.So we talked about what makes a framework.So which ones of these have what we just talked about?
The data fetching, the routing, the back end support, things like that.
They all have some degree of that in some capacity.I think the biggest thing is like what you bring in for the backend.
So in my project, kind of what I based this content on was I built the same app on every single framework and was trying to compare code for what it looks like in each scenario.
And did you have to build like a separate back-end application to serve data like some other Express or Hono app to do the data piece?Or were you relying explicitly on these frameworks to handle all of that?
Yeah, so I use Prisma in every single application and connected it to a Postgres database.And with the exception of Redwood, I used super bases off.
Okay.And then so your API layer was whatever the framework provided, not another node server that you brought up.
That's right, except for Redwood, which right now has GraphQL support.So it's still using Prisma to set everything up.But then I'm using GraphQL to serve up the endpoints as serve as the API layer.It's a little bit different there.
The similarities with the exception of Redwood, all the other ones for their router is a file or a folder based system.And so there might be differences in how you name things.
So for example, you might use square brackets for like a dynamic route where you have an ID or you might use a dollar sign for the ID.
But for the most part, it just depends on if you just drop a folder and a file in here, then all of a sudden you have your URL.
Did any of the frameworks have a config file based router?
Yeah, right, right.So Redwood does.And that's probably one of my favorite features about it.I just feel like it's easier to maintain that way and easier to update.Remix does, but I've never used it.Have you used it?
I have, and they're coming out with a new version.
So I think the new version is going to be a whole lot better from what I've seen, which includes, instead of all the funky characters to do the layout and not do the layout and do the URL and not do the URL, they're all nested functions.
And so it becomes, I think this is how they're getting some of the type safe stuff too.
Interesting.Yeah.So I've looked at the documentation for remixes.I should just build an app on it.Because I mean, that's really how I learned best.That's how I develop an opinion is I just build something on it.That's why I did this project.
But the remix based on the documentation, it felt like I was more limited than what I got with the files and folder names.
Maybe that's true.Maybe that's not.But again, that's just from reading the documentation.
Yeah.Okay, let's let's talk about like, which ones skew more server and which ones skew more client.
Hmm, good question.So Svelte is going to render everything on the server and on the client, it'll make the decision for you, unless you explicitly say within the file name about that server.ts.
Okay, and it'll make the decision based on which one of its like data fetching methods, you're going to call in the script tag or something, or if it's like trying to update like that, because like, it might give you the first render out from the server, but the second render from the client.
Right.And it knows because it had compiled this already.
Because it's a compiled framework.And so it knows, OK, this has to run here.This has to run here.So the output bundle is like, this is what you host.And this is your JavaScript bundle.
That's right.And then Astro, you have fences.So if you've ever worked with Markdown, you have like these three dashes at the top where you put all your front matter in it.
Astro has something like when you look at it, you're like, oh, this looks like front matter.But within those three dashes and three dashes at the bottom, you can have all the code that you want to run on a server.
So I found at least when you're working with it, it's really nice separation to be like, I know this is running on the server.
Yeah, it's not like all just JavaScript, or like which one is which again?
And you don't have like these weird configurations with Next where you're like, use server, use client.You just know this is running on the server.
Okay, that's a good stopping point to talk about the next paradigm, right?Because everybody else has, like Remix has these functions run on the server.You know that it's a convention, they always run on the server.
And then Astro is like, this stuff is your script tag, it runs on the server, all that kind of stuff.
Next, did you find that, you know, after trying all these frameworks, next felt confusing because of the directives, the use server, the use client, do you not know where things are running?
I felt for the most part, it's pretty straightforward ish.There is a little bit of a, of a mental shift though, where I ran into issues.
And I think you, you pointed this out is like, you have to, this threw me off in the very first next app project that I worked on.It wants a, Oh, maybe you can help me with the, I might use the word wrong.It's a object primitive.
Is that, is that the right word?
I think so.So what I was doing was I was just like passing props, I grabbed all the data and pass it down and I just pass in my props.
But because I was going from like the server to a client component, it's like whoa, whoa, whoa, whoa, we need an object primitive and it's because it's not serialized.Is this ringing bells?I'm passing an object, what's wrong?
But it needs like a one layer object so that everything can be serialized.You can't have like these nested things.
Yeah, yeah.And supposedly, like remix is coming out with this single fetch thing, which can serialize anything, which I still don't understand that.Yeah, that's the the black magic.
Let me explain that because I am kind of talking very vaguely right now.But say like you have a person and on your person object, you have address.
And so then as an address, you have another object and that object has the street, the city, the state, the zip.Sorry, this is the United States.That's how we structure our addresses.
So what I'm talking about is because it can't really serialize it because that address object is nested.It wants everything in that initial layer.And so one thing that you can do is you can serialize it.
Just say like, here's a JSON string, pass it over and I'm going to convert it back.
Yeah, so you're saying like it won't automatically serialize it for you.
Well, here's the thing.I don't know if it will now or not, because I was an early version of next.So take all that with a grain of salt.But anyways, it was just that was kind of like, Oh, that's that's different.
Okay, this is not a decision, but the limitation.
Yeah, any any other big like, as you were switching between frameworks, any other big gotchas?You're like, man, why did they do it this way?Or this doesn't jive with me like things that made that made you stumble?
Okay, so this isn't stumbling, but I think it's important to talk about is Remix has the data loader pattern, which is really interesting.So within every page, you can have three functions.
You can have your loader function, your actions function, and then your actual page component that is a function. And that does all the rendering.But you know, when the page loads, it's going to run the loader function.
When I'm processing a form, it's going to run the action function.And then you have your rendering piece.I like that separation.It's nice to be like, I know I'm loading my data.I know that I'm handling my form.
And you just know when you open up a page, you have those functions and that capability available.
the downside there is that like, the action is a little overloaded.On some pages, you have multiple ways to like mutate data.
And so you kind of have to like either pass in a hidden input to tell your action function what you're doing, or just make separate action routes and route to a different page, which that's right.
Now there's more complexity and how you handle errors and things like that.Because know, standard browser behaviors that it would return right back to the original page.And you don't get some of that stuff for free anymore.
Right?Right.Well, what's interesting, so if you look at Redwood on the other side, because it's using GraphQL, you can do all that stuff on the page, like I can just, you know, throw it, hey, update the page, you know, we're wherever Willie wherever.
Yeah, amazing.But The problem is, so I know people have mixed feelings about GraphQL.That's fine.I particularly like it just because I'm like, Hey, this is the data I need.Thank you very much.You gave me the exactly what I was looking for.
But the best way to interact with GraphQL I think is with Apollo. and with Apollo comes a lot of boilerplate code.
So if I'm going to create a mutation, this is almost embarrassing to describe, you have a GraphQL call that handles the mutation, then you have to define, you have to use the use mutation function that Apollo gives you that calls that GraphQL mutation, it gives you a function back, and then you actually have to call that function within your handle submit.
So there's like three chunks of code you have to remember for every single form submission.
I mean, for if you want to include the revalidation, right.So after you do the mutation, you typically need to revalidate some data Well, you can and they give you a validate a revalidate function, right?
So with that stuff, a lot of times you can handle that within the use mutation hook because there's an options object that you can pass it like on completed on error and you can have it refetch every country.
So you just say like, hey, once this if this was done, refetch or refresh this cached query to get the latest data back from the database.So if it updated, give me this, give me that.
But it's just like, man, you have the GraphQL use mutation, the function.And then yeah, it's just a lot of code.So if something goes wrong, trying to figure out where that went wrong is sometimes fun.
Talk about like, did you notice any performance differences between the three apps?Did you actually deploy them?Or did you just all just run them local?
Everything's basically running on Vercell.I mean, you just can't get over how easy it is with Vercell.
I'm like, think what you want about Vercell.But I just don't think that experience has been matched anywhere.I mean, Netlify has come close.
Yeah, and I gotta say, like, I've tried deploying remix apps on CloudFlare.And CloudFlare can run them just fine.
But the problem is when you want to use like environment variables, the way CloudFlare delivers the variables into your JavaScript is, is weird.They're not globally available.
They're like coming in as context to the request, which makes it difficult to share around your app.Very problematic for cells like yo, we'll inject the environment variables for you.It's fine.Yeah, you know,
Well, and the other thing is just even this is so simple and so small, but even their user experience around adding environmental variables to your app.
Oh, it's so good.You can, you can use the CLI to upload local environment variables.You can use the CLI to pull them down.You can copy and paste an entire ENV file and it just blobs in like, it's so good.
I just copy my ENV file and then I go to the web environment and I just hit paste and it just, it knows, it just enters everything in.
I also find that the way they can separate them in a production environment, in preview environments, or you can define an environment, it's great.
Yeah, so it's all done on Vercel.
So now that they're deployed, right?Did you notice any of them running any faster, any slower?
Yeah, so I'm still working on this part.So this, hopefully I'll have this information for the Atlanta conversation, but I am working with Century.So huge shout out to Century.They have performance tools built in.
And a huge part of this project was like, I don't want this to be just a Redwood commercial.
that, oh yeah, of course she said Redwood, she works there, but to be the objective person in the room to say, actually, X, Y framework is the best, or, you know, this is running smoother here, or, you know, whatever.Sentry has so many great tools.
it's it's hard.I guess I want to talk about performance and about century.It's hard because when you're measuring performance of these different apps, if one is server rendered, it's time to first bite is going to be slower.Right?
But if one is more like leaning on the client side, it's gonna have a way faster time to first bite, but it's going to be done painting.Probably if all else was equal, after the server rendered apps, right?
Because it's got to make more than one round trip to the network, you know, one for the shell, then hydrate the react, and then, you know, call, call and go get your data.So like performance is different.It all kind of depends.
And it goes into like, what kind of app are you building?And what kind of experience do you need?
And then second, with these more complex apps, the ones that do the hydrate, like there's the server piece and the client piece, and you're now you're calling server actions and stuff.
the Sentry setup is actually more complicated now than it ever was.Back in the day, you'd like wrap an entire React client side app in Sentry.That was the only concern you ever had.
But now you have to like, make sure you're wrapping your the server render portion, and the client portion and any client side transitions, you know, because your loaders and actions are called again.
So like the Sentry setup, I noticed, has gotten more difficult as these frameworks get more complex.
Yeah.And, you know, some of that will be interesting, too, as we move kind of, pendulum swings the other way, and we go to more of a server-full environment, what things are easier and what things are harder.
Because SPAS solved a very specific problem, but they also created other problems that we're now trying to solve for.
But I don't think we'll ever go back.Like I don't think the pendulum will ever swing all the way the other way.Like we know the benefits of client side transitions.They're just super fast.
And if you can do some nice pre loading, then, you know, it's gonna feel really snappy.And you can get the best of both worlds.
You know, all your secrets and a lot of your data stuff stays on the server, you hand that over to the client, it hydrates, and now like your app just goes quickly.I don't think we'll ever go all the way back.
Yeah, one thing I will say that I appreciate about remix is how they have stuff built in for handling optimistic UI.So it's like, I'm just gonna assume that it works.And then we'll deal with it if it doesn't.
Yeah.And that's coming to react anyways here soon.Like, I feel like the remix surface area is actually going to get way smaller with like react adopting like the use action status or whatever the heck it is.
It's like what's happening with your mutation and the optimistic UI stuff. So Remix is just going to get smaller and smaller, which is kind of cool.And a lot of the frameworks that bank on React are just going to get better because of it.
Yeah, I was trying to think what other pieces.Oh, let's talk about one other thing.Middleware.
So when you're talking about, you mentioned routing with Remix and how sometimes those loader and action functions can get quite large because you're having to run a lot of the same code in each.
Now you can put those in an extra or an external function to call it, but other frameworks like Astro and Next and eventually Redwood have a middleware layer where you can just run those functions inside middleware.
And then you don't even have to run them on the page.It just knows, oh, you're going to that route.Let's authenticate.
Yeah.How do you do like, what's the process for defining middleware on each route?Because what you don't want to do is say, Hey, um, don't forget to add the auth middleware every time you create a new route.
Like how do you guarantee that like, this isn't a problem of forgetting to add the middleware that you need everywhere?
Yeah, so like I said, it's coming to the server version of Redwood.
But when you're talking about authentication and Redwood right now, because there's a configuration file, you can just wrap it and it looks like, okay, the route file looks like a react component, but you can wrap it in a set component, gotcha a private set.
So there's like, if you have an authenticated route, just stick it inside, like when you define it, stick in that block of code.Okay, easy.
With Astro, it's kind of interesting because you have a file, it's the easiest way to handle it, which can be maybe a little clunky, is to say, like, I'm just gonna have a folder called admin, and any file inside my admin folder is going to be protected.
And so then in middleware, it's just looking for that admin inside your route.
Is it like glob based?Like, hey, these paths are fall under this middle?
Well, you can kind of meet and basically make it that way.
So I can say I'm gonna if it's an admin route, then apply authentication, you could define it on the page on a per page basis, you could like not use the middleware, but then you're having to put that function every
You could also look for it on a per route basis, but then to your point, you are having to remember, okay, if this is a protected route, I need to add a block of code every single time.So anyways, this is kind of interesting.
But I mean, thinking about Laravel, what they do is within their routes file, you say with authentication, which is kind of like how Express handles it.
If you think about their syntaxes with their middlewares, you just say with whatever you want that middleware layer to be.
Which one do you think you got up and running the fastest and which one do you think you got up and running the slowest?
Well, that's not a fair question.And the reason why I just I live in Redwood, so I can like move around it super fast.I know things just the documentation.
I think Redwood covers so much ground that I think if I didn't live and breathe it every day, I wouldn't be able to move around as fast.So I don't think that that's a fair, a fair thing.I also, depending on what I'm building, I love Astro.I really
I really do.I love that it has Markdown support built in.So a lot of if I'm doing like a marketing site, that's what I'm going to reach for is Astro.So like this is alluding to my pick and plug later, but I have freakingfullstack.com.
That's an Astro site.So I just love that I can say, oh, here's a bunch of Markdown files and then it'll handle that content as collections or its own page.That's really nice. And then I really do like remix.
There's a few areas that are harder for me to work with, but some of it's just, I wonder, that's a question that I ask myself.Is this harder because I don't work with it every day or it's a pattern that I'm not used to?
And if I just got more comfortable with it, I would like it more.I think that's valid.
Maybe now's a good time to talk about like, which frameworks stood out for different use cases.You already made the case for Astro and kind of documentation or marketing sites, anything that consumes markdown for sure.
Right.Remix, I love for a small app.To me, it's it's it is great.You get a lot of stuff out of the box.The one thing that I really appreciate about Remix is they have said the browser is super powerful.Browser API is great.Why not lean into it?Yeah.
So for a small site, it's great.I've had problems when it's gotten to be a large application and then it just becomes harder for me to manage all the pieces.And some of that I think really does come down to how it handles routes.
And I'm really interested to see how it handles this next iteration with the configuration piece.It's also gonna be interesting to see how that really overlays with the React Router 7.How will that work together?I'm interested.
Yep, they're getting closer to like converging them or, you know, like getting remix and just be like telling them just use the reactor out or seven V plug in essentially.
Yeah.Svelte is a question mark right now.So they had their Svelte summit last Saturday or the Saturday before, and they've officially released version five.And so I need to spend more time with that setup.
I really like the old version of Svelte because it felt more JavaScripty.
So for example, if you had state, there's no need to have this useState hook that then gives you a array and the first value is the name of state and the second is a function to update it.Try explaining that to a new person.
That's very strange and very awkward.With Svelte, you just say let count and you're just defining your variable and because you put let in front of it, you can update it.
I've heard runes, like change that a little bit.And it's like not as easy anymore.
That's right.So the well and before so if it needed to be a prop, you just say export.Now it's available leaking pass in value.With ruins, it looks more like react boilerplate code.
so you have dollar signs in there and you're wrapping things in functions.I've seen people like Scott Talinsky talk about how like, oh, I wasn't crazy about this, but now that I'm using it, it's great and it makes sense.
I'm just not sure what that level is.So right now all the old stuff is still supported in Svelte 5, but moving forward, I think they're going to deprecate it.So yeah, there is a video and I will share it.It is on my watch list where
It's on the Syntax YouTube channel, where Scott Talensky just released about an hour and a half Svelte basic course explaining all this stuff.It's in my watch list.
I'm going to go through it and just try and get a better grasp on all the new features of Svelte.But I think it goes back to what you're talking about with the documentation.
So Svelte's documentation is completely different than any of the other frameworks.If you go to their site, It's like, I'll give you some information, but mostly I'm just going to give you a playground to see how this works and to experiment.
Sometimes I like that.And then sometimes I'm like, Oh, just tell me what I need to know.
You know, and I gotta say for as much as I love remix, I don't love their documentation.They're a little too focused on like API level documentation.And I'm just like, Can you tell me how to use this?Like, instead of just what it is?
Yeah, the other thing that gets me sometimes about remixes documentation is because for a while they were adding support like they were doing something in react router and then they'd added to remix.
They do something in remix and then added to react router.So you go to pages within the remix documentation where it's like this is the same thing as react router.Just go check over there.
I was like, No, just I'm right here.Tell me now.
Yeah, yeah.And it's they I'm ready for them to kind of like really get that story straight where it's like, Ah, we finally made the clean break use react router.And here's what remix actually does for you.
You know, at the end of the day, doing all this, do you think it changed your mind on the tools you would use for anything?Do you have a new default?You know, like, what, what did this show you?What'd you learn now that it's all done?
That's a good question.So I'm such a framework nerd.I just like experimenting with all these things. that in some ways it's made it harder.So I build a new app and I go through my head and I'm like, Oh, I should do this in Astro.
Cause I want to put the documentation here and I can format like, but wait, remix also offers Markdown support.So I could format it like this, but it's a larger app.
I really don't want to, you know, I love to use storybook and that's already built into Redwood automatically.So I have like new, Circular conversations in my head.So I would say, you know, for somebody that's like, What do I do?What do I learn?
Where do I start?And I almost appreciate your approach, Brad, where you're like, I'm your Remix Guy.Remix is my thing.
I, I had way too many of those circular conversations in my head.And I just decided one day that I'm going to pick what is it like the tool of least power, essentially, that's tailwind for CSS.For me, that's a remix for a JavaScript framework.
And just go because if I keep like, don't get me wrong, I want to check out like just hono for building API's, I want to check out this new one framework, I really want to check out tan stack start.
And I'm like, I'll never build anything if I continue to do this.So I kind of drew a line in the sand and said, I'm going to shore up my starter templates, I'm going to make more advanced starter templates, which include auth DB, all this stuff.
And then I'm just going to like stamp out new applications when I have ideas.And don't even think about the tech stack, just get good at using a tool.Because if you look at all these indie hacker guys, if you look at kits, a if you look at
Mark Lou or any of these guys who are popular like we use the same tech every time and it allows us to move fast So that's that's where I want to get to personally or Peter levels is like PHP I do yes old school and I mean I can't tell you how many people that we've interviewed on the podcast that we've asked Oh, what's your tech stack?
We love those conversations.
Like pick boring tech.Pick boring tech.It's stable.People know it.You don't want your tech to be where you're making all your decisions.And it's actually really interesting.I heard a new concept the other day called innovation points.
Have you heard this before? So a person, I think all this is confidential, so I'll just leave it super vague.A person that I know is starting a new company and the question was, what is my tech stack?
And so apparently when you're starting a new company, you have, I haven't dug into it, so I don't know if it's just this person's theory or if it's like widespread. But this person believes in innovation points.
And so what that means is when you have a startup, you have so many innovation points to spend.
The way that I, at least I understand it is you have certain areas where you want to innovate in certain areas where you're like, I'm just like, that's where my focus is going to be in terms of pushing things forward.
And so anyways, he ended up going with a different tech stack than what you might expect, because it was old and boring.And it's like, we don't want this to be where we spend our innovation points.
We want just to pick something stable that everybody knows.And we'll spend our innovation points focusing on other things to push the company forward.
Yeah, yeah, that's right.Like focus on your your business value, like the thing that you're actually going to do that differentiates you business logic.
So that's the other problem.How many apps have I started where I started in one app, and then I hit the hard part.And I'm like, well, I'll just go rebuild this and remix.And then I hit the hard part.
And then like, well, let's see how this looks in Astro.And so I've built the same app multiple times, which is just dumb.It's like I hit the hard spot.And then I want to instead of pushing through it and solving it, right? go on to something else.
I would just advise people pick one.I don't think you can really go wrong.They all basically give you the same thing and build like that's more important is the building piece.
I think my take for something like this is like, I've tried them all and just go with the one that vibes the most with you.
If you feel like using one feels like a struggle and it's not fitting your mental model and you're like constantly just being like, wait, why I don't get this.
Go with the one that you get, that you understand what it's doing, that just clicks with the way you view what a framework should do.And then I think you're going to be set up for much more success in the long term.
Rather than worrying about the slight differences between these frameworks, which don't really have an impact on the app that you're building, just the experience you have while building it.
So just optimize for like the best experience while building it so that you keep going.
Yep, yep, for sure.So the next segment of the show is our picks and plugs section where we pick something that we like, could be anything, and then we plug something generally that we've worked on.So, Brad, what do you have for picks and plugs?
Another video game.It's what I've been doing to just relax lately.And there's a new Zelda that came out, 2D Zelda.
I'm gonna have to get that one.
It's it's good.You actually play as Zelda, not as link.And the whole shtick of the game is like, everything you come across in the world, you can clone it and use it.
So anytime you want to like summon a table, a chair, an enemy, you can just summon it and it can like fight for you or you use it to like, you know, traverse and jump on it.
Very puzzle heavy, like everything's a puzzle, you know, just like Zelda games.But even more so because you're like using your library of things to try to accomplish a goal.
Yeah.I get lost in 3D worlds.So even if it's like I don't know if I'm assuming it's like this where you have there's a specific game style where it's like you're looking at the overall board.
So even like you're kind of moving around maybe in 3D space, it's not like Mario where you're just moving left to right.Does that make sense?
Yeah, it's it's exactly like links awakening that the 2d isometric.
Yeah, the isometric.That's what I was trying to think of.I don't get lost in those worlds.It's the 3d stuff.There's just something disorienting to me.So I love that it's 2d.
And all the Zelda 3d worlds lately have been too big.Yeah, yeah.
And then what about a plug?
plug.My Twitter has been doing pretty well lately.I got a ton of followers after tweeting that I joined Stripe.Apparently, all I have to do is mention Stripe and boom, you get a bunch of followers.Thanks, Stripe.So go check me out.
X.com slash Brad Garropy.
Oh, man. I've been MIA on Twitter, so I have, I feel like I post more pictures there than anything else.
Like I treat it like a photo reel or I'm like, Oh, I did something cool.That's somewhat related to tech.Here's a photo of it.
Yeah.I have been thinking more about, I, this sounds so old.I miss the old Instagram where it's like, I'm just posting photos.I like it on Instagram now and it's just all videos.I'm like, I don't want to watch a video.I just want to see a photo.
You know, it kills me on Instagram where people are like, you know, you see like a post that you want to go check out and you click on it and they're like, all the information is down in the caption.And I'm like, I'm not here for that.
Just tell me what I need to know right in the post.
Yeah.Yeah.So anyways.OK, so I'm going to plug.I don't even know what this is.This is an AirPod cleaner.I was like, I don't even know what the official is, but I was having issues where they weren't necessarily charging.
So I bought this little cleaner.It was like maybe five, seven dollars on Amazon.Pretty cool. So on one end, this slides out.This is like a giant Q-tip, but you can stick this down and clean the little stem part inside your AirPods.
And then on the other side, so this little slider goes one way, it's the Q-tip.The other way is this little, it has a protector thing on the tip.So this is a little pointy thing.And so you can like, clean anything out.
You can pull the little rubbery stuff out, get those all nice and clean.There's a little brush here that you can use on like the sensors for noise canceling.And then I guess it's like the speakers and things like that.
So it was embarrassing how dirty they were and it solved my connectivity problems, charging problems.
Yeah, AirPods are amazing.Probably.I mean, I switched over to the whole Apple ecosystem not that long ago, or I returned to the Apple ecosystem, I should say.And AirPods are probably my favorite bit about the whole thing.
Yeah, yeah.Well, and I've thought about the Air Max.This is really vain.I just don't want it to mess up my hair.And they're big.
They're really big and really heavy.
I love how compact these are.And these are getting older.So the fact that I'm cleaning them will hopefully give a little bit more life.
Are those the gen twos, the pro gen twos?
I they've got noise canceling.
Okay.Well, they are pros.Here's my hesitation.So my first set, you know how they had this huge recall where you, you could send them back in.I qualified for that.Yeah.
So they like the noise canceling got bad and there was like this weird, I don't know.It would even, they would even make this weird whistling sound when I was using them.And so I took them to Apple.Apple was fantastic.
They ran a test on it and they're like, Yeah, both of your AirPods qualify.They're both bugging out where I kept the case and they're like, we're just going to give you new pots.So they gave me the new pods.
I'm not sure they were like new were even though they were older version.
So the last time I was on a plane, I took both these and the AirPods and I did side by side noise canceling tests on the plane.I think your pods are better. at you.
There's something about how they're right in your ear, the seal is a little bit better.And I'm just like, and they're just like 1000 times more convenient, you know.
And so these headphones, the only thing I really use them for now is direct line monitoring when I'm talking into a mic so I can hear myself.Save that.AirPods are like my go to for everything else.
Interesting.That's good to know.For my plug, I'm going to plug freakingfullstack.com.Yeah.Uh, so check this out.It's Halloween themed, which is really fun.
I mentioned earlier, it is an Astro site, but I am doing a free no strings attached free workshop on Halloween.It's gonna be like nine to 12 central. standard time.
So if you're trying to do time travel, that's the same as Chicago, but we will be building a full stack application.So I did a workshop at React Summit.It was in New York, but I was remote last year.
And so it's basically that same workshop, all the same content. So we'll be building this app that we talked about during the show that I built six different ways.
We probably won't, you won't have the exact app, but I'll give you all the pieces you need to be able to build it.So we'll talk through all the logic, we'll build an API layer, we'll do all the data fetching, all the things.So register.
There is a recording.It is Redwood.
And there is a recording.Oh, yeah, come on.There's a recording.So if you're like, I'm at work, you will get the email with the recording later.And you can listen to it at 2x.
Awesome.But for now, that's all we got.
