The new era of React frameworks with Ben Holmes
===

[00:00:00] Hello, and welcome to pod rocket, a web development podcast brought to you by log rocket helps software teams improve user experience with session replay, error tracking and product analytics. You can try it free at log rocket. com. I'm Noel. And today we were having Ben Holmes back is here to talk about the new era of react frameworks.

Ben's the core maintainer at Astro. Welcome Ben. How's it going?

Hey, it's going pretty well. I don't know if this is maybe the third time we've talked, but it's good to always be back.

yeah, I know it's been more than, one. . Let's jump right in the new era of react frameworks. What is the era? And why is it distinct from the previous era of react from?

Yeah, what's new? It feels like new stuff is happening every six months, but yeah, we're trying to block it out by eras. Well, if I'm trying to walk through it all the way back, if we go to when I started web development, which was AngularJS 1, playing with things before NPM existed, it We were on this [00:01:00] cusp going from these server driven apps that refresh the page whenever you submit a form to purely, most impurely client side apps that are getting thicker and thicker with JavaScript owning the component lifecycle, re renders, etc.

And now we're realizing, okay, we were all the way one way. We pushed all our tooling to the client. And now we're slowly pushing things back to the server so we can opt in to specific areas of the client that actually need logic. So I feel like that's the new era of scaling things back to the server and figuring out where you need to piecemeal that JavaScript in.

And there's a lot of different approaches to doing that, including Astro, Owens Architecture, Server Components, all things that we can get into. But it feels like everyone's aligning around that.

Yeah. I think that, reflects what I have found myself talking to guests like over covering pretty frequently, it's like everyone feels this rubber band effect that's happened pretty quick and drastically. I feel like it's been, like thrust upon [00:02:00] devs is the right.

Kind of phrasing, but it does feel like it's like very suddenly in the last couple of years, it's all this is what everyone is thinking about right now for better or worse, probably just by driven by kind of market trends and demand for even more snappy feeling web experiences, which is probably good in the end, but it is maybe a little bit stressful on the creators of these things, right?

Like us as well as web developers. Yeah. When you're, thinking about this and covering it, what are the big, like problems that you're thinking about are the things that define this new, paradigm of pushing stuff back to the server.

right. And we're referencing this talk that I've given a couple of times now about the new era of React, new era of frameworks and opt in design. So to break down, first off, what opt in design is, I can start from what opt out was, or we didn't call it, yeah, we didn't call it that. But it was how we sort of thought of things where when you created a new app, if you're coming from the react ecosystem, you leaned [00:03:00] on create react app, you client side rendered everything into a div and you reached for common libraries in the community, like style components for your styles and react router in order to have multi page routing in a single page application.

And that usually meant. There was a base cost of 80 kilobytes for the hello world in order to have all those libraries set up and ready to go. And then as you went on and as you added more features, you would maybe do a performance audit. Maybe you would find problems with that stack and you would realize, Oh, I need to opt out of loading.

My whole application, I need to lazily code split certain routes and certain portions of it. Those aren't the defaults. Those are things that you need to know about in whatever libraries or ecosystems you have, so that you can load those resources later. And you might also realize if I'm, handling all of my form submits with like prevent default and sending things off to the server, I'm dealing with a lot of client side logic [00:04:00] to first prevent the default behavior, then re fetch new data.

So maybe I need to, do things like Remix does where you offload to a form action and you put all of your validation now on the server and you keep it a little bit leaner. These are things you need to know about, though. So you need to, opt out of whatever you're using. Maybe you need to opt out of JavaScript based styles with style components as well.

There are so many areas where we pushed it all to be very dynamic and interactive. And we slowly realized the cost of that and tried to scale it backwards. And now, I'm at least trying to lean on frameworks like server components and also like Astro. Now let you opt into that behavior. So instead of starting from, let's go ahead and have a client side router and a client side component tree.

Let's start from render everything with the server side template. Whether it's on request or statically generated, you choose that on your backend. And that's where you start. And then, as you need to add [00:05:00] more features, like this form actually needs client side validation. You can import Zod into the client, which is a popular validator for objects, and wire up that submit handler yourself.

But the default is send it to the server and let the server do it. The opt in is choosing these libraries. The same goes for interactive components and other things on the page.

If I can wind us back a little bit and put on my devil's advocate hat here, I would say, or I've maybe question like, was this a lack of foresight that we realized that there were all these problems that we would require devs to opt out of or to configure the framework, to do something more.

I don't, I don't even want to use the word advanced, but to do something other than the default because we wanted to handle it differently, right? Like lazy code loading is a fine example. Versus , was that an intentional thing or was it more so that like for a lot of devs, we want to make this as easy as it can be out of the box.

And then if they need more advanced configuration stuff, we'll make it. So they have to go flip those switches to get whatever [00:06:00] configuration they want. Cause I feel like they're like, these were intentional decisions that these. Framework authors were making like, why doesn't that always work?

Is maybe the question I'd pose.

Yeah, and there is, I've hunted for that blanket advice, but it is more case by case.

Sure. Yeah.

like you're totally right saying, Oh, library maintainers just didn't know that this would be a problem and had to add it later. That's, not assuming much of these libraries that we use every day.

I feel like some of it is born out of How interactive is it going to be and how often are you going to opt out of whatever it chooses, like React is born out of Facebook highly dynamic dashboard, therefore, loading components straight away, or using JS to manage your styles with something like style components, you're going to want that flipped on maybe like 80 or 90 percent of the time, so why not make the default flip it on, and then the 10 percent where you do your performance monitoring, you flip it back off.

But, when we're building [00:07:00] Things like blogs, documentation, e commerce, anything that is further down the sliding scale from something that is a heavy dashboard. We're not having those flipped on 80 to 90 percent of the time. Usually, I've noticed like using styled components, I keep harping on them, I'm sorry, styled components is lovely.

But it does rely on JavaScript in order to mount all of your styles and change classes. That was an era before CSS variables. Before really that was it, that was the part that was missing in the browser to let you dynamically update styles from a variable. So now that we have that, now that the browser caught up and gave it this really nice primitive.

called CSS variables to update styles. It becomes a lot less necessary to have this client side JavaScript to do it. And we're making it dynamic a lot less often. So usually you're paying a cost of shipping JavaScript for your styles when most of the time you're not taking advantage of the cost. These are all static styles for what you're building.

Maybe it's dynamic some [00:08:00] of the time. It depends on the app that you're building. It also depends on how much the browser caught up from where those libraries originally started. And I think, for stuff like styles, that is like a very clear example. Create React app is a bit more nuanced, of course.

Yes.

there's all kinds of like biases and things like, if you're Facebook. You're assuming people have loaded the page already, like the initial page load for Facebook is of my very minuscule percentage of that user's experience, right? Like you got Facebook open on a tab.

It's been open for a year, right? Like you're not reloading that versus like you said, e commerce blog, something that's You know, a high percentage of that traffic is opening it for the first time or the first time in a long time on every landing like that's a very different story. So do you think that there was like a distinct failure with like create react app to adapt over time to these like technologies as the web?

Caught up to use your phrase there.

Yeah. There are specific failings to, you know, some of the choices React made early on. It leans on [00:09:00] Webpack, which is a very complex bundler that's hard to configure. We now have bundlers like Vite and Rollup, which Vite is based on. They give you much simpler config and much better loading in the dev server.

So that is one legacy cost that's really hard to move away from. Because you have a community that's really based on this bundler. Now it's just, they're kind of stuck. And also, they early on... This could be a library failing where they really wanted everything to work. As you mentioned, developer experience, the default is it works how you expect, they went pretty aggressive with that and even poly filled node libraries like crypto, just to make sure that it would work how you expected it to.

And it's hard to take things back. Once you enable a feature and it's on by default, it's hard to flip that switch back off. You have to be way more cautious. So there's a lot of churn from people that are like, migrating to VEET and this random package doesn't work because the maintainer hasn't updated it in a year and they assumed crypto would be there because Create React app, [00:10:00] whole, bit of legacy decisions.

So part of the reason it couldn't keep up is just making all of these choices for features, and relying on a bundle that's really hard. And now both of those are very difficult to reverse and bring people into a new world. So some of it's just, there's gonna be lock in.

Yeah. So maybe this is a good segue and I think maybe just an interesting question, how much of this shift to opt in this kind of what we're talking about here is just driven by switching to a bundler that is more conducive to this way of building apps. 

Yeah, I do think that Vite specifically is a bundler that was a catalyst for all these new frameworks to try things out. So up until now, if you wanted to compete with The way Create React app or Next. js work, you would need to set up your own bundler from scratch and understand all of the choices that go into it, which is a very high entry cost.

But now Vite comes along, which is a bundler that gives you a dev server, [00:11:00] gives you SSR, gives you cache and validation so people can have really fast reloads while they're editing their code. And library maintainers just sprinkle on top their component framework or the value that they bring. So that's why Astro came into view.

That's why, not view, but the reason Astro came in. Reason Nuxt was able to really speed things up. Svelte kit. SolidJS, they're building a metaframework. Yeah,

Solid start. Yeah. We just had Ryan on a couple weeks ago.

exactly. So I feel like these ideas existed, but now that there's this tool that we're all relying on and making better, we're able to play out those ideas super fast. So people felt whiplash of, Oh God, why are we going back? It's almost because framework authors also got this whiplash. Oh my God, all these tools exist now.

We can just go build something. We were trying to get a bundler to work for five months. I've been there. So now it's much easier to try out these ideas. And already conducive to SSR more. [00:12:00] That is also a thing, we can talk about server components as well, where React is inventing pretty much a whole new bundling strategy, just to let you start from the server and opt into client side JS.

And that is a whole new world that is, you know, unlocking these blurring of boundaries and other things that we could get into about server components, but that was definitely a bundler and tooling specific effort that wouldn't have been possible

if we just had Webpack Pro.

Yeah. I think as an observer, I feel like it's hard not to See that pattern or at least believe that pattern is existing there to some extent. And yeah, \ , I do want to talk server components. I guess I'm curious, maybe this is an interesting question here.

So like this shift to server components, how does this play into your opt in design thesis? Like \ how do these feel? Does it feel like we're able to do like server components or maybe even just SSR at large? Does that feel new? at odds with this kind of opt in design paradigm because [00:13:00] one could argue there's more magic going on now behind the scenes than there even was before.

So are we falling into the same trap here? Are we going to be in the same place in five years where it's oh we thought we just did all these things correctly out of the box in terms to us in regards to SSR, but actually we've been doing too much defaulting. 

Yeah. And I could go on for a while because I've been thinking about it like there is a lot to server components. And I actually just gave a talk where we build server components from scratch using the React core libraries to see what are they doing. And there are a lot of specifics to it, but in general, to explain what server components do, they are a way to use React templating to write something that only runs inside of a server.

And then, if you ever need to, make a database call, you can make the database call straight inside of the component. So that you don't have to write a separate endpoint call that the client goes out and gets back some JSON. So it makes it [00:14:00] pretty simple from the developer's point of view. But from the tooling point of view, we have this funny blurring of boundaries where you have your server components.

That can import client components and you can put this magical use client flag on top of any component that also needs to ship something to the browser. That's something bundler specific and it is, there is a lot that you have to put into that bundler to make sure it does it right. Because you don't want browser code to leak on the server.

You certainly don't want server secrets to leak onto the client. so in that way, I think the opt in part is definitely the use client directive. Where it assumes server is probably where this stuff should live, so that you get a fast response. And then we opt into client side JavaScript because...

That could, impact first paint, it could impact the amount of, just network calls it has to make. So that should be the opt in feature, is using React as you would for an interactivity framework. The parts where it's like, is this going to be too [00:15:00] much? Is, we have some fundamental issues still with React, like When you need to use Client, it's still really big.

It's a big runtime.

Yeah.

And hydration is a really funny concept. Because when you use Client, believe it or not, it is still going to server render a component and then use Client on top of it. So if you've ever dealt with those weird problems of you have a component that needs to access Window and then your server explodes because Window doesn't exist.

That's gonna keep happening because we've written our code to run in two places whenever we want something that runs on the client So I think just this idea of hydration at some point could reach its head I would hate if we still wrote hydration the same way like 20 years from now I don't want my grandchildren to see hydration mismatch doesn't make a lot of sense So I have been playing with other things that can offload that quick is one interesting idea That is still being proven out.

[00:16:00] I'm not really sure where that will land. But, I've also just been playing with going back to something like AlpineJS, which is a very lightweight way to add interactivity to stuff. So you could have a server template, and then have client only logic that mounts. When you resume it in the browser and it does simplify the mental model a lot I'm still playing with that idea But I feel like there are other ways to opt into client side JavaScript that don't mean crazy bundlers Potential hydration errors and other things and that's what we still might need to work out in other tools

yeah, Yeah, it's almost like it feels like a three pointed, it's like a triangle here and we're trying to find the correct balance of like dev experience performance optimization and like being too opinionated as a framework and like all everyone's like landing in different places in this triangle as to like where we hope to be or what is the right abstraction to make so we don't have to do this again in 10 years because [00:17:00] I'm sure this, people talking about this , five years ago we're having these same thoughts.

It's surely we're not going to be shifting this piece of the stack. And alas. Here we are. But yeah, I think this kind of, meta consideration that you're doing is interesting. How does this problem compare? yeAh, these kind of like super simple, explicit JavaScript libraries aside.

If we're talking more, the realm of frameworks like Svelte, React even like we could, Talk in terms of the kind of meta frameworks, like the remixes and stuff on top of that. Astro, we can also include like, where do they fall on your kind of opt in spectrum and how do they compare to what, just react is doing right now?

Yeah, I mean, there are a lot of different frameworks that fall on different areas. Astro is the easiest one to explain, I think, because Astro is furthest towards making zero truly zero. When you create an Astro app, for example, or an Astro website, if you care about the It's like, when you [00:18:00] create each file.

It's going to return HTML and you could wire it up as either a server or a static build whichever you prefer But static is the default and whenever you visit a route and it is file based routing whenever you visit a route It's just going to be HTML and scope CSS And no JavaScript until you add it.

And then the opt in is maybe I want a framework like React or Solid. You can choose whichever one you want. You add the integration, and now you can mount these individual components in. And you can choose how they load. So maybe you want to have hydration and server rendering. So you say, I'm going to add in this search widget, server render it.

And then mount Algolia on the client. You can import that component. You can say client load in order to do SSR and all of that. And then it will appear. Or if you realize, I don't want to do the server rendered pass because it relies on this stuff. Maybe it's like a Google Maps widget and there's no server result.

There you can say client [00:19:00] only, and that will only load the client JavaScript and not try to pass it on the server. So you have all these switches to decide what's gonna load where, server or client, when am I gonna load it, and what framework am I gonna use to do it, if I even need one. You can also, in Astro, just write a script tag, and you can write TypeScript inside that script tag.

You can bundle MPM modules inside that script tag. So if you wanted to go full on web components or mount a GSAP app, I've been playing with that just to just add an animation without a component framework. You can do that too. You can just reach for Vite in order to bundle everything and you're free to use the tools that you want.

With exactly the JavaScript you expect. So that one's pretty easy to explain. It's like, yeah, start with HTML and you opt into JavaScript. There's no baseline that you would expect there. These other frameworks have a baseline that's more assumed. So it's Remix and Next, they're staking their claim in e commerce and beyond in terms of [00:20:00] complexity.

E commerce, usually if you're talking complexity, it's like how much mutation are you gonna be doing? Like how much are you gonna send stuff back to the server and re render? With Astro, if you're doing like blogs or documentation, you're not talking to the server again that much, you're mostly just serving up content.

But if you need to go back and forth a lot, and you want to efficiently reload chunks on the page, Or send requests. That's when maybe you want the baseline cost of React in order to manage re rendering components. And maybe you just prefer the DX of React. That's, more opinionated, but it's in there.

And then the baseline cost of the router plus React. Which is somewhere between 50 and 80 kilobytes, depending on who you ask. That baseline cost might be okay. Because you're going to lean on it most of the time. And then from there you opt in to do any client side JavaScript for this, and this.

We can add the use client directive in Next. js. And that will also add it in. So it's just, everything has [00:21:00] opt ins, but depending on the framework, more things are going to be flipped on because of the use case that they're assuming. Like Astro might be really annoying for e commerce because you have to flip on a bunch of things.

I'm working on how you could get away from that with view transition, it's another thing. But you might be annoyed. But in Next. js, if you're building a blog, you might get annoyed all this stuff is shipping when you don't need it. So Next. js becomes a much worse option for blogs, but really good for e commerce because I actually wanted those switches flipped on.

So it's a really tough balancing act of define the use case, Don't try to be the framework for everything. Otherwise you'll probably make you know, diminishing returns. And choose which things to flip on to get to that baseline use case and then leave people to flip things on themselves for anything that goes beyond.

Yeah, no, I find that perspective interesting, and it's probably something that we don't talk about enough when we're discussing these kind of trade offs that different frameworks are making, because yeah, if you're using an app that's like super, has a bunch of client state [00:22:00] that you keep track of, the framework is just gonna make that easier to do things with.

Is just going to change. I mean, Like there's tools and stuff in place in almost all of these, like to make that easier. But, if there's just like a ton of data and it's, it's affecting, immediately how data that's returned from the server is rendered based on filters that are set on the client that, there's like some kind of filtering happening, that's client side only there's just.

All kinds of stuff that can be trickier as we push things back up. But I think that we tend not to think about all of those cases, like when we're discussing what framework to build a given project in. You also mentioned DX there, which we were talking about earlier in our discussion.

But I think that when we're talking about like opt in and opt out, that we really are talking about the developer. Experience. Cause these are decision points that are happening during the development process, right?

If everything is opt in, I agree. If you're a seasoned developer, and you know what you're opting into and what to look for and what to turn on that it can be like a liberating experience, right? It's like, I only get the things I asked for and that feels good. But if you're new, [00:23:00] you're getting into web dev for the first time.

It feels like it's another, daunting thing. That is being asked of you to figure out like what are all the flags I'm supposed to turn on for this thing I'm building. Do you think that is a true problem or do you think that that is a You know, like the opposite having everything turned on by default is causing just as much pain for those newer Into the space

Yeah. It depends on if the thing being flipped on is going to bite you later. And if you, if it's going to bite you. It's best to know that, that exists. We're talking pretty abstract here, but let's take lazy imports for

Yeah a good example. Yeah for

something like that. If you start from nothing and then have to learn later, here's how performance auditing works and here's what to do if you hit these specific problems, like that's a tougher journey than if everything was a lazy chunk that you flipped on and then you realize, Oh, I actually want to eager load this.

Because this needs to be mounted at this time, like it, you know, it's tough to be [00:24:00] prescriptive. It depends on like, how often are you reaching for whatever feature it is? And if you're reaching for it almost all the time, like if you're building a dashboard, you're reaching for client JavaScript and routing almost all the time.

Then newbies should just have it because it'll almost never be a problem for them because they know what they're building. 

But the problem is we started from, you know, you were told you have to use react. React was built for these dynamic dashboardy apps and people pulled it into all these other use cases that were way further down the chain Where you need to rip out a lot of stuff in order to make it efficient So now that we've realized that we realize okay, people aren't using Ruby on Rails.

They're using react to do this stuff now Let's try to make react a little bit more like that where things are server to start and you're slowly opting in when you're building things That really benefits. It's tough to say. I think that adding friction to flipping things on is good for a learning journey to show people here are the features, here are the browser platform standards, or [00:25:00] whatever. But, it really depends on who you ask. I know that request response is also a fun one where Next. js papers over a lot of things and makes it really easy to just send requests and response. They even patch the fetch function, which they're apparently going back on. So

But they patch fetch to make caching easier, but it differs from how the platform works, and you have to know what they're doing. Remix is the other way of yeah, it's more friction. You gotta opt in to figure out how to parse your response into form data and form data into the object with the type.

But now you know the platform and all of these functions, and isn't that great? Now you can go use these utilities from the community if you would like to. I prefer that latter approach of pieces are a little bit more pulled out. There's less figured out for you, but you learn it, and then you can go reach for a community library to make it easier.

So there are cases where it is nicer to do that because you discover why you need an abstraction.

Yeah. Yeah. Oh, for sure. when, When thinking about these, just, as someone who's [00:26:00] working on Astro a lot of the time, do you like in deciding which of these switches to have flipped on what features to have enabled for devs? driven by developer experience or when you guys are , thinking about these things, making those decisions?

Is it user experience at the end of the day that's influencing what the default should be, or is it in the middle somewhere?

Yeah. I mean, it all comes back to focusing the framework on what it's meant to do. There are a lot of frameworks out there that try to be a silver bullet for every website you would ever build. And Astro decidedly said, nah, our focus is going to be content driven websites, marketing, blogs, eCommerce, et cetera.

So what's the lowest common denominator in that? Probably a marketing site where it's a one pager that has some text communicating your company. So that's going to be the lowest one. Everything else would be an opt in switch from there. So that way you can intentionally grow Astro. Grow your site both Astro into larger and larger [00:27:00] things.

And we do think about user experience when we design those switches. Like If you had to do a weird function wrapper in order to turn it into something that works on the client. Or if you had to figure out how to bundle solid yourself and there was no plugin to do it now we're just making your life hard in order to opt into this stuff.

There's no reason to make your life hard. You're obviously choosing that decision for a reason. So we just have one directive called client that's able to opt into that. But yeah, we do try to balance it. And some of it comes down to good documentation and good language tools as well, so you can discover those switches.

before Astro is its own templating language. So people had to go read the docs to figure out all these things. But now you can just type the letter C and all of a sudden all the client directors pop up with inline docs describing what each switch does. There is a bit of that as well. I think language tooling is a huge part of discovery.

So that you don't even have to open the DevTools to figure this stuff out.

Yeah. I think we're circling this idea that like opt in is [00:28:00] cool and great for everyone when it's easy for devs to opt into and then it's like it's increasingly tricky when the opt in process is more difficult because then it's like, Oh, maybe we should have just made this the default if what most people, that's what most people are going to end up doing anyway.

But yeah like you're saying, I think that Can be problematic in certain cases as well. So that is it's an interesting dance to walk. Do you think this kind of shift as tooling gets better? In general, have you noticed this trend? I guess I'm resuming out a little bit.

Have you noticed this trend kind of across the industry happening? Or do you think it's still pretty specific to like a subset of the frameworks that are trying to push towards this opt in mentality?

Yeah, I definitely think it's a JavaScript ecosystem specific thing. Because, members from other frameworks across the aisle are like, You're just noticing that? We've had this in Laravel for a decade. And it is funny to look at, because I have been exploring Laravel recently. And I see all these patterns and I'm like, oh my god, that thing Astro just did?

Yeah, they had it. And they have it better. I actually want to take some ideas from that. [00:29:00] I think anything that was not JavaScript, anything that couldn't run natively in the browser had to work in these constraints. Had to keep things server default and then opt into specific client pieces.

JavaScript's a funny one of, we were born out of building client side logic, and then we started figuring out how to build servers with

JavaScript. So it's the one ecosystem where we moved backwards instead of forwards. So that's why we're seeing this trend of okay, JavaScript on the server is better than ever.

Now we have Deno and Bun to make it faster. The V8 runtime is fast. We have edge networks and all these other ways to deploy it quickly. So now JavaScript, confidently server first, is something that we can use. And now we can opt in from there to also ship JavaScript on the client. And I feel like most meta frameworks within JavaScript Are aligned in that the outliers are going to be ones that are very spa specific you know, tan stack, who has built your favorite query library react query, they're [00:30:00] also working on a router.

And it's like, no, we're still serving the people that need dashboards because they exist, they know their use case. So it is best to have everything as a client side spa. I think that story still is definitely strong and something Astro supports as well. We're trying to help people migrate from create react app.

Into Astro so they can have this nice sort of dual experience So I think those will always stick around But meta frameworks that try to address like a huge swath of things you want to do are all moving towards this more server first Idea.

Yeah, it feels like we're in a place just like pragmatically still where it's there may be some performance implications here, but like the overhead of trying to split this up feasibly, it's just make this a spot. , it's not worth what you're trying to do.

Maybe that won't be the case forever. I haven't seen a clear path. It's Oh yes, there's the winner. Like you said before, I haven't seen one. That's this is the clear jack of all trades tool set that we should be using, or even just like philosophy, like to make [00:31:00] this easy.

But it feels yeah, we're still in that realm. Like we said before, where there's like certain use cases where it's easier. It's eh, just make it a spot. Like it'll be

Yeah, I don't think we'll ever hit it. I don't know that might be a funny bet to make 

but 

I can't, speculate. No

I know.

Yeah. Is there, I guess. at large, just if we can stay zoomed out here, do you think have there been any other specific cases outside of Astro, maybe just to keep it interesting, where you've been impressed by shifts towards this? Philosophy opt in design.

Yeah, there are a few. One that I don't have my ear out enough for is security of the scripts that you run. And Deno has been pointing that one out. Where the default in Deno is you can't do much of anything inside of a script. It can run JavaScript logic, but it can't reach out to the file system, to your environment, to other parts of your machine. And you can add flags whenever you execute a script to say, this has access to my environment. This has access to my file system, but reads [00:32:00] only. You 

can't write files. You can be very granular about it. I noticed they also have a flag to opt into all. I think that was dangerous because too many people are going to do that.

I do that because I get lazy.

it's the easy way, right? This isn't working. What? Uh, Try this first. And it worked. Yeah,

Yeah, but they are really nice in their prompts if you try to access a library without a flag and it says you need to Enable this flag and then you can just insert it in and you're done And I know that node. js is picking up these security ideas as well I think at the end of the day, I'm gonna keep using node.

js And let these other tools create these new ideas that can hopefully get gobbled up by Node. js. Deno's definitely pushing Node forward in that way. And then Bun on the performance story is pushing it that way. Not really an opt in mindset, but it is another example of communities pushing things in a different way.

That's definitely one area. It's not all about performance when you're doing opt in design. There can also be like opt in to, sending secrets from a server into the client. That's something server actions is trying to [00:33:00] deal with right now. That's gonna be a tougher one, I think. Not sure where it'll land, but there are areas all over where you're blurring the server client boundary.

You gotta keep things tight.

Yeah, it does feel like this. This shift into the complexity of necessitating logic back on the server is like the tricky friction point here that like we're trying to solve. So I think, yeah, we could go down these rabbit holes and talk about , the nuance here like at length.

But I guess is there any, anything else in particular you'd implore listeners to think about or just consider maybe even look at when they're, Setting out, working on their projects right now in terms to design decisions like how they see what the libraries are doing for them or not doing for them or what's out there.

Yeah, it is tough to give advice that doesn't just make you feel more JavaScript fatigue Because a lot of these ideas are more fundamental mind shifts like oh, yeah Just delete all your style components and use tailwind because it's server rendered some people just can't do that. There's no way so I do think [00:34:00] Understanding the trade offs of those tools, now, is definitely important to know.

So if you're using React and React Router, understand the trade off of, Oh, there's no server rendering. You know the classic, there's no SEO. But you might also know just progressive enhancement. Maybe you want a form to work without JavaScript, or on a really slow internet connection. You're sacrificing that.

And, depend on your customers and who they are. Is it an internal tool? Is it someone on a subway with one bar of 3G? And if it's a bunch of people that might be on the subway, like people that are just visiting your e commerce site for the first time, you might need, you might be able to justify, let's get off of create react app and do something that is server rendered.

Ideally something that is server only so that we can pull the cost back to request times as much as we can. It's something my last company had to reckon with going from create react app to next took three years. But because first paint is so important, they were able to justify the cost. So they went ahead and did [00:35:00] it.

So it really is about cost benefit to know what you're working with, who you're serving and deciding if you need these more fundamental shifts. Your tool chain. Otherwise, just know what your trade offs are and do your appropriate performance monitoring to keep it in check and find all the areas that you can opt out appropriately if you're locked into that.

Nice. Yeah. Cool. Yeah. Thank you so much for. Sharing the insight, Ben. Is there anything else you want to point listeners towards or have people check out?

Yeah, Astro is cool, astro. bill. chat is our Discord, you can also find our docs and everything else. I also do a lot of explainers about web dev concepts, I keep it to one minute shorts. So that you're not overwhelmed and you can get a taster for everything that's out there. So if you go to WTW.

dev, I have an archive of all of my one minute shorts. It's on YouTube, TikTok, Twitter, whatever you prefer. So if you're trying to learn these new technologies quickly, you can head over there.

Good short little domain. We'll get a link in the show notes regardless. I'm impressed by the six [00:36:00] letters. That's cool.

surprised it was cheap. I didn't think it was fake, because those are rare.

Yeah. Very cool. Again. Thank you so much. Thank you so much, Ben. It's been a pleasure chatting as always.