Panel Episode
===

Emily: [00:00:00] Welcome back to PodRocket, a web development podcast brought to you by LogRocket. ~LogRocket helps teams, ~LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics.

Try it for free at LogRocket. com. I'm Emily, producer for PodRocket, and we're back with our first panel episode since ~January. ~June. So we gave a little break over the summer, but we're back again. ~Um, ~we're going to be covering a wide range of topics in the world of web development,~ um,~ as well as going through some of our guests, hot takes and what they're fired up about in the web dev world right now.

But before we get into it, let's welcome our panel back. First, we have Paige Nijinghaus. ~She's set. ~She's a staff. Engineer at Blues. Welcome back, Paige. Also, PodRocket host.

Paige: Thank you. I'm glad to be back.

Emily: Awesome. Next, we have Chris Batista, ~Senior Software Engineer, uh, sorry, ~Senior Engineer at Netflix,~ um,~ and also PodRocket host. Welcome back, Chris.

Chris: Hello, it's been a while.

Emily: It has been. ~Uh, ~next we [00:01:00] have Noel,~ uh,~ engineer here at LogRocket and also one of our PodRocket hosts. Hi, Noel. Nice to see you again.

Noel: Yeah. Same.

Emily: ~Uh, ~and finally, we have Paul, Fullstack engineer and again, one of our PodRocket hosts.

Welcome back, Paul.

Paul: Thanks for having me, Emily.

Emily: Always. All right, I'm excited to get into it and have us all back together again. ~Um, ~since it is September, we're moving into the school year. Things are getting back to normal after summer. ~Um, ~so I just wanted to kind of get into moving into like the back end of the year. Pun not intended.

~Um, ~we want to look at the last months of 2024. So I wanted to get all of your opinion. First,~ uh,~ over the summer, did you find any new tools, platforms, frameworks, et cetera, that,~ um,~ you were really excited about? You started using, you're really enjoying,~ um,~ or did you find any new tools that you were excited about and you absolutely hated?

~Good~

Chris: I can go first. ~Um, ~I started using v0 just because I was curious. I just kept hearing a lot [00:02:00] of buzz about it. And I'm already, like on my side projects, I use a lot of the same tools that,~ um,~ They're leveraging. ~Um, ~so yeah, I was actually thoroughly impressed. ~Um, ~as you can expect with AI, ~it's, ~there was some code issues, but I'm not a designer.

So in terms of getting something that just looks good,~ um,~ it was definitely very helpful. So it at least speed me up on just getting something nice to go on the page and then I can always just clean it up after. ~Um, ~so I've been using it pretty heavily. It's limited cause I'm using like the free plan or whatever that is.

~Um, ~yeah, it's been pretty cool though.

Emily: to hear. ~Like, ~it's like solidifying and like people are starting to use it. ~Um, ~who else?

Paul: I've been enjoying Cursor, which is pretty common. A lot of people are using that these days, but it's definitely been great as serving for a better autocomplete. Been enjoying using an actually commercial model versus like the GitHub copilot one. Not ~that ~that one's not commercial, but the ones that kind of plugs into FreeUR seem a little bit better.

[00:03:00] by

Paige: probably within the last six months or a year, and I'm not sure if it's just that the models have gotten better and the answers are more accurate, or if I've just gotten better at prompt engineering and I'm better at asking it and providing it with, ~you know, ~very detailed instructions of what I need.

But it's been super helpful for me writing like GitHub actions, which I don't write very often. So I always forget the syntax for it or bash scripts, which I also don't write very frequently. ~Um, ~or even just giving it complex things that I'm trying to ~like ~combine or group together and asking it to do that for me, it's been actually really good at that.

So it's been saving me a lot of time in terms of those kinds of things. Fiddly bits of coding that you need to do, but don't necessarily want to think about all the steps involved.

Noel: ~My, ~my stuff's been in the same vein. I haven't ~like ~made the jump to cursor, but I~ have leveled up like a lot of my, I've, ~I finally made all of my co pilot like keyboard shortcuts first class citizens, so I can just ~like ~pop into prompt mode really [00:04:00] quickly, anywhere. Like when I've got something highlighted, injected into a prompt.

and I feel like it's. Has streamlined stuff. ~Like, ~I don't know if it's making me way more productive, but it's like quicker than having to hop out into the browser or ~like ~switch to the tabs manually. Just like button type three words, enter. It's like, okay, here's the syntax for, ~you know, whatever. ~Pushing onto an array in some language.

I only write in once every four weeks. And I forget every time it's ~like, ~perfect.

Emily: It's really interesting. ~The four of you are like the, ~the tools you're using are AI. Cause I know like we do talk about it every time because ~it is like, ~It is the new thing and it's not going anywhere. But,~ um, ~after all these, honestly, a year and a half, it's very cool to see you all using it in your own work instead of just experimenting with it anymore.

~Um, I mean, ~Paige, you made a good point. It's like, is it getting better? Am I getting better at prompting? ~Like, ~who knows? But ~like, ~I think collectively it is becoming a more solidified part of the web dev ecosystem. So very cool. ~Um, so too, uh, ~now that we're out of summer. Is there anything you're looking forward to in the coming months?

Any releases, anything you're working on?

Paige: Well, as far as things that I'm [00:05:00] excited about,~ um, the. ~There is a new tool that is starting to get some traction called RSPack, which is ~kind of ~like the next version of,~ uh, ~Rollup. And the idea is that it is much faster than the original webpack because it's written in Rust, because every JavaScript tool now is written in Rust or must be ported over to it.

~Um, ~so I was just reading about it a couple weeks ago. It's still early stages, but it seems to be a lot faster and almost ~a, ~a drop in for webpack if you're using like a Next.js application or something that already relies on it. And if it. integrates and ~kind of ~provides the same level of compatibility with Webpack APIs as it purports to.

~Um, ~but it also speeds up your development time. That would be awesome. So ~I'm, ~I'm actually really excited to try this in like a new project or one of my existing projects and see if it really does work as well as it says it does. ~Okay.~ [00:06:00] Okay.

Chris: such as like React Query or TanStack Query. ~Um, ~so I've been seeing a lot of buzz about TanStack Start, so I'm curious to see a new contender, because right now it's like, what, like Next.

js, Remix, ~um. ~So Tanner has a very good track record. So I'm hoping this is,~ uh,~ going to be a ~very, ~very good,~ um,~ implementation. It's an alpha, so I'm not expecting like it to be perfect, but it's something I'm going to be watching very closely.

Emily: And if you're listening to this, we just released an episode with Tanner Leslie and I believe Noel, we hit a little bit at the end about that. ~Right.~

Noel: Yeah, we did. ~We like, ~that was earlier today. We recorded that and yeah,~ we, ~we touched on it briefly. There's a lot going on. He's working on a lot. Yeah.

Emily: per usual. Anyone else,

Noel: I'm excited to try the new,~ uh,~ Oh, one, whatever it's called. Open AI is new, like model. That's supposed to be better for like research and coding and stuff. I could probably even get access to it if I like went in and found ~the, ~the key we use like for company stuff, but I haven't, I'm just waiting for general release, but,~ uh,~ more just cause I like,~ I'm,~ I'm curious on code stuff.

Like ~how, ~how good it does.

Emily: Paul, [00:07:00] anything?

Paul: Not new, I've been enjoying the new releases of Drizzle over this year, they've been coming out and iterating quite quickly, and it's the first large kind of library, I don't know if an ORM is classified as a library, I say it is, right? It's the first like library that I've been a part of since ~like ~the early days, and it's fun to see, I feel like. You're getting a new update, a new DLC is getting downloaded, and you have all these new fun toys to play with, so that's been ~kind of ~like a fun journey this past year, and I hope they keep up the speed, because it's been great.

Emily: Hell yeah. Love that. All right. ~Um, ~Thanks for sharing your likes and loves for this year. So far,~ um,~ we're going to,~ uh,~ go into, uh,~ uh,~

Paige: Okay.

Emily: [00:08:00] I know before we even jumped on this call, Paige was like, this is becoming more of an issue that we're talking about. So why is SSR often the culprit of slow performance?

And what issues does it often introduce into applications?

Paul: Speaking from my own experience using SSR, I feel like ~it's, ~there's so many things we're gonna go into that I don't even know necessarily about the mechanics of SSR, they're pretty deep, but at just a very fundamental level, people view it as a paradigm and not as a tool. And I say that because that's that used to be me where I was like, oh, this is a new way to request data.

~And like, ~this is ~kind of ~the way and then I'm going to scaffold around that versus scaffolding the best way to ~like ~query your data and then using SSR client side, depending what it is. And that's just like a source of so many problems. Like should your data be SSR? Maybe ask that question first and a lot of things that Matteo talked about in that blog post might be avoided such as ~like if you're ~if you're rendering thousands of divs, it's like a whole separate ~sort of sort of like ~problem that could require a special [00:09:00] solution.

But I'm curious to hear what you guys have to say about the SSR conversation going on because I know it goes, you can go down deep into ~like ~the actual tech and how it's rendering and throwing data across there but. that high level POV, man, that was a big mental shift to view it as a tool.

Paige: ~Well, ~I think some of ~the, ~the server side rendering ~the, ~the slow performance that he was referring to, it's things like increased CPU and memory usage, which comes from rendering really big or complex data sets on the server side, and then having to send it over the wire to the client and then render it in the DOM or the browser. ~So there, ~there can be a slower response time if your HTML rendering is complex. There are concurrency limits that you can run into because JavaScript is a single threaded language. ~Um, ~there's cache complexity based on what kinds of information you are trying to cache to reduce the amount of re rendering or re computations that you're having to do.

So those are some of the challenges that you face, but. [00:10:00] If you are starting to run into those sorts of issues, traditionally, there are a lot of things that you can do to mitigate it. ~You can, ~you can look into caching at a lot of different levels. You can have CDN caching, you can have reverse proxies, you can have caching of particular pieces of data that you know are going to stay the same across.

A full session that a user is logged in. ~There's, ~there's hybrid rendering. There's a lot of ways that you can. mitigate,~ um,~ and that you probably would do if you were running into those sorts of bottlenecks that he really didn't touch on. ~He just, he used some very, I think, um,~ he used some tactics ~that you would, ~that a lot of people had issue with, a lot of the other frameworks had issue with, and called out because he used things like an LLM to generate the code in the different frameworks that he then performance tested.

And as we've all seen, LLMs are not usually the most performant when they're writing something for the first time, or they can completely hallucinate and just make stuff up that doesn't actually work when you run it.~ Um, ~so there were definitely ~some, ~some things that he said that I think [00:11:00] it would be hard to back up or hard to find in the real world where people haven't already thought of potential solutions when they start to hit these sorts of roadblocks.

Noel: ~Yeah, I think, so this is,~ I feel like this kind of SSR step in this flavor is ~kind of ~a new problem, right? Like it's not something we really had to deal with before in ~like ~the data rendering pipeline that is like the data that a server is sending. ~Uh, ~to a browser,~ like, ~and then in the old world, it was like, we'll send a static file and we'll do the asynchronous data fetch.

And ~like, ~that was all clean and straightforward. And you could see where the performance impact was. Now there's this ~like ~kind of magic SSR thing. ~Well, ~magic's not the right term, but like thing that we're not thinking about much in the performance impact of the SSR itself, ~right. ~Like in the rendering pipeline.

So it's like a new problem, but I also question how much of a problem this actually is because yeah, this benchmark is like, you know, Say you're just like somehow ~in a, in a, in this, ~in a theoretical example where ~like ~that piece alone is the only thing that's technically complicated in a given request.

~Like,~ and we push that to the limit, like ~which one of the frameworks does that the best. Right. And let's like, well, or~ [00:12:00] which one of the tools, ~I guess, ~does that the best. And it's like, sure, we can do that. But like ~how ~in the real world, how often is it the case ~that the, ~that, that piece of the pipeline, like fetching data from external sources and then Loading it all in and actually doing the server side render before we send data down to the client.

~Like~ how much of the request life cycle is that actually most of the time? And I bet it's not a lot. I don't have any numbers, ~but like, I think it's easy to like panic, ~but ~like, ~this is only a case when you're really punching the hell out of like a server that's doing a ton of. Server side rendering like this.

Chris: Yeah, I agree. ~Um, ~one thing I want to know, like in terms of just like real world examples off of what you just mentioned is, yeah, in my experience, ~it's usually not that step ~it's usually people waterfalling promises or not realizing requests and that's usually. The bottleneck there. ~Um, ~but yeah, ~I mean, ~it's still helpful to keep in mind.

Like we'll get into the results in a little bit, but you know, if a request does take longer or you can't handle as many requests, you are going to block other people if traffic is high enough. ~Right. Um, ~that's something to keep in mind, but I do agree. Like in terms of ~like ~what I've seen in the real world, I don't think I ever look at like the engine.

Oh man, it's like rendering [00:13:00] so slow. It's usually like, oh,~ this,~ this database call is just very imperformant. Let me go fix that instead. ~And kind of thing.~

Noel: yeah, it is a piece for sure. Like I'm not saying it's not something,

Chris: ~Yeah, yeah, yeah,~

Noel: if you're compounding, like if you have one server and it's like, okay, we're going to just do ~like ~a thousand requests a second. ~You know, for like, sure. I mean, ~that happens in the real world, but like, how often are those paths?

~Like ~is the SSR the blocking step? Maybe.

Chris: ~I agree. ~I agree. A hundred percent.

Emily: ~So, uh, ~I did want to get to the rankings like Chris was mentioning. ~So, um, ~the first one was, I believe, Fastify HTML, which,~ uh,~ I'm assuming is part of,~ uh,~ Mateo's fastify ecosystem. ~Um, ~and then the last place was react. ~So, uh, ~just listening from what you guys just told me. ~Um, ~I'm very curious to hear what you guys think about the rankings in a real world context,

Paige: ~Well,~ Mateo had a dog in the fight, so that's the first thing, is that he is the lead maintainer for Fastify, so obviously it's a very good chance that Fastify is going to be the winner no matter what. ~Um, but, ~but in addition to that, React has been around for several years, and as other people who looked more closely [00:14:00] into the results of this found, there were a lot of bits ~where he wasn't, or ~where the LLM had generated code that was unperformant.

~Uh, ~it was running things in dev mode for some of them. It was, just writing code that wasn't using the latest versions of different frameworks, like I think the Svelte code was written in Svelte 3 while Svelte 5 is in alpha right now. So there were just a lot of things that if you looked a little bit more closely, ~you'd be, you'd be, the, ~the results were suspect in a lot of ways.

~Um, ~and ~I did,~ I talked about this with some of my friends who are web devs at my company as well. And the thing is, We don't necessarily select the framework that we're going to use based on Performance benchmarks like this. We're going to look at what does the team actually know how to code in? Because that means that they'll be able to deliver features faster.

What are the requirements for the project? Like it may not be that node or any JavaScript based thing is the best. You may end up writing it and go, you may need to write it in [00:15:00] something that's just closer to the metal and is just a faster language to work in. So there's a lot of other things that I think that you would probably look to before you'd look to benchmarks for choosing what you're going to use to build your web application.

Emily: any other thoughts on that one?

Chris: I think it wasn't very surprising to me, but just how much faster all the other frameworks ~are than ~are than React. But I think ~like ~the common knowledge here is, ~you know, ~React has VDOM and VDOM is just overhead. ~Um, ~so it just has ~that, ~that cross to bear, right? ~Um, ~so ~no, ~no surprises. ~I've, ~I've always been spelt curious. So ~this is just a, ~this is just like another thing for me to ~like ~go down that road. I was very close to going down that path at some point, but I had to favor productivity ~over, ~over my own learning. So maybe one day ~I'll, I'll, ~I'll jump in that road. But yeah,~ these, ~these results, I would say to me,~ um,~ I did expect React to be last.

~Well, ~I stopped using it now, but,~ um,~ It's crazy how like Vue and Svelte are up there in solid, especially

Noel: Yeah, ~I was, ~I was most surprised by how quick view was. Like that [00:16:00] just was, I expected view to be like maybe next after react, not like second fastest or whatever. ~Like ~that was the thing that I ~kind of ~gave me pause.

~I don't know. ~I don't know. I didn't go deep enough in and like, where's view getting all this performance.

~Uh, ~bonus here.

Paul: I definitely share that too, Null, because view and react have ~kind of ~been synonymous for me and for all of you haters out there. ~I mean, ~lovers, you might hate me for saying that, but ~like, ~they definitely feel like one in the same in terms of their attitude towards A good portion of the stack. So it was very surprising to see it so fast because in the back of my mind, I'm thinking, Oh,~ well,~ it doesn't take much to switch over then.

Huh? In my mental model.

Paige: Um,

Paul: you're like, yeah, that's cool. Thanks

Emily: thinking now about like how this article doesn't really showcase the full picture of server side rendering. Still, what would you like to see either from frameworks or how [00:17:00] people write code? How would you like to see server side rendering,~ uh,~ evolve? And,~ um,~ do you ever think it might be replaced by something else?

Paul: There's so much you can do if something's being server side rendered I forget who called it up But somewhere someone here just called it at the beginning that you can get better visibility into what's actually happening on your server and in your data request lifecycle and React is doing some of the stuff like with next they're surfacing better ever messages and stuff, but man having more out of the box tools for performance benchmarking looking at individual life cycles of where data is coming in and Or if there's a memory leak, that'd be really great because there's like plugins you can get to help you find that stuff But if it's on the server, it'd be cool to have that in framework.

I don't know if that's a good thing That's just a selfish ask

Paige: That's not a selfish ask. ~I mean, that is, if I'm, if I'm not mistaken, ~I think that's part of what's coming in react 19 ~is better ways ~along with react compiler, which will take away your ~entire ~need to use react memo or use callback or any of those hooks yourself. That benchmarking is [00:18:00] something ~that is something ~that they're trying to do more of, so it's easier to see what's taking a long time or what could be deferred.

What doesn't need to be loaded on first page render.~ So, you know, ~that's something that I think is coming. And one thing that I would love to see more of, but make it easier for developers to kind of opt in is the streaming. Cause there's lots of talk about using streams to send data to the client as it arrives and not have to wait and ~like ~chunk it up in pagination and things like that, or polling and.

It's great that we now have those options, but they're still not the easiest to wrap your head around if you haven't used it before. ~So if frameworks and ~if they could make it easier for us to use those and opt into those newer features that would make things faster for our users, I think that would be an awesome addition to ~the, ~the options out there.

Paul: That sounds super cool being able to stream. And you know what? How fast it does it is like the least of my concerns. It's all going to be fast enough. I just want to be like easy and traceable and reproducible.

Paige: ~So, I don't know if~

Emily: Chris or Noel, any thoughts?

Paige: ~never seen anyone do it.~

Chris: Yeah, [00:19:00] I'll tap on to the streaming aspect. So yeah, that's ~like, ~I think that's where we're naturally going. We can see that with ~like ~Next.js with the streaming capabilities with RSEs where I'm hoping it evolves is. I think it's already happening. It's slowly leaving the Next.js ecosystem and starting to get adopted in other places so we can actually see like other ways of implementing these things.

Not just, this is how Next.js does it. It's only available here. Go try it there. ~Um, ~so I'm hoping like in the next year, ~you know, ~I brought up 10 stack start,~ um,~ remix, maybe. Those methodologies will be even better or something like that. So I'm just hoping the whole ecosystem kind of evolves. Cause to me, it's very confusing still, like the primitives are all there, or I think mostly there.

Now it's just a matter of, we need someone to put them all together and make it easy for someone like me to use. ~Um, ~and yeah,~ build,~ build that scale.

Noel: Yeah. I mean, I think like my perfect scenario, I don't know if this is ever even going to be viable or possible longterm, but I think ideally most of this decision is not something like one has to think about most of the time when ~like ~designing components and pages and routes, like what can I [00:20:00] render where, what ~it ~needs to be ~like, um, ~authenticated, what doesn't ~like, like.~

I think ideally ~just like, Oh, ~the framework or whatever you're writing against is just like, okay, this thing is completely static. We can just ~like ~do this at build time. This is just a file. ~Like ~these are never going to change. These pieces ~would like ~need to be reactive on the client. These ones need to be server side rendered because ~like ~there's some expensive call we've detected in here.

We want, ~you know, ~this is how your authentication layer is abstracted. I don't know if that's ever going to totally happen, but I think ~the, the, like ~the happy path for me ~and, ~and we're probably the closest in this with react right now, just because ~like ~so much work is being done on this front, but I think it's very possible it'll proliferate.

~Like, ~I just don't want people ~to have to be, ~especially like new devs or ~does it ~don't ~like ~do a lot of front end work to have to wade through all of this every time that they're doing something. So I feel like, ~yeah, ~simplicity. Is the thing that I want.

Emily: I think that's a good note to close that out on. ~Um, ~all right. Next everyone's favorite topic that we have to keep talking about AI. Okay. ~So, um, ~last week it is September 16th as we're,~ um,~ recording this, but last week,~ uh,~ Ryan Florence,~ uh, creator, creator of remix came out. Creative ~[00:21:00] creator of Remix,~ um,~ tweeted that ChatGPT,~ uh,~ moved from using Next.

js to Remix instead. ~Um, ~and interestingly enough, within the same time span, Vercel hired ShadCN to incorporate ShadCN UI into their v0 generative UI tool. ~Um, ~so weird crossing things happening at the same time. ~Um, ~so first,~ uh,~ Chris actually tweeted at Ryan when this happened and asked why they decided to move to Remix.

~Uh, ~Ryan doesn't know, but I just wanted to get your speculations of why you think chat GPD suddenly started using Remix as opposed to Next.js.

Chris: I have some thoughts. ~Um, ~the first thought is, so I use Next.js pretty heavily. ~I'm ~outside of work. The dev server is one thing that kind of pains me at the moment. ~Um, ~No offense Next.js, but this is something I've been voicing for a while. ~It's kind of, ~it's pretty slow at the moment. So that's probably one reason.

The next is probably, if I had to guess, this is one of my frustrations ~is ~there's just a lot of [00:22:00] Vercell isms baked into their framework, which makes sense, it's their framework. They have their opinions. ~Um, ~but it's very hard to understand and grasp, especially like the caching layer itself. Like, why is this cached?

How do I not cache it? ~Um, ~So I'm ~like ~exporting like random variables at the page level. ~Um, ~so I think ~like ~some of those ~could, ~could probably feed into it. ~So ~for me, it felt like even though the docs were ~like ~pretty good, I ~kind of ~just had to have a PhD on like how the whole ecosystem worked. ~Um, ~and I know with Remix, they're really big on ~just ~standards in general.

~Um, ~so I imagine that's probably a big reason with that. I haven't used Remix personally. Maybe their dev server is amazing too. I don't know. ~Um, ~but I do use React Router. ~Um, ~with the loader pattern and that seemed pretty straightforward. ~Uh, ~but just speaking strictly from my experience with Next.js, those are probably like the two pain points I had.

~Um, ~and I can imagine the dev server being a big part of it, especially if you have a large engineering team and everyone's just taking ~like ~15 seconds to compile a change, and then sometimes you don't even know if it actually updated, so you just refresh the page anyways. ~Uh, ~those are like ~my current, ~my current,~ uh,~ grievances, 

Noel: ~Do we know, does anyone have insight? ~Do we know if they switched [00:23:00] hosts? For the front end at least?~ Like, ~were they on Vercel and moved? Cause that's my suspicion. Like I have a hunch that they were on Vercel and they were like, ~this, ~it got way too pricey ~being, you know, being for selling it. ~They made their switch to cloud flare or something.

And they were like, eh, well, we're in here. We'll just rip the bandaid off and switch to whatever we want to be using is my hunch, but ~like, ~I have ~no, ~no data to back that up. ~That's what, ~that's the thing that I could see driving an organization ~kind of ~at this stage to make that switch.

Emily: ~It's~

Paige: ~I mean I~

Chris: ~like, yeah, oh, sorry, go ahead, Paige.~

Paige: ~well, ~I could definitely see that being part of it. Sure. Money is always a big factor. ~Um, ~I watched a video that Wes Boss made about ~kind of ~digging into why he imagines that they made the change. And some of it makes a lot of sense. ~Um, ~one of the things that he mentioned that we ~kind of ~touched on already or Chris did is the fact that. Next.js is extremely opinionated about how they want you to use their framework. They want everything to be server side rendered, pretty much, and ~if you don't want to, ~if you want to client side render a lot of stuff, which makes pretty good sense, actually, for when you think about what chat gpt is,~ um,~ that's not the easiest thing to do, whereas Remix is a lot less [00:24:00] opinionated about that and lets you ~kind of ~structure it the way that it works better for you, so that's probably part of it.

~Um, ~And from what Wes ~kind of ~uncovered as he was looking at their code base and looking at how the API calls were being made and things like that. There is a lot of, it seems like most of chat GPT's heavy lifting is actually done by their API, which is a separate service from their front end because they have a desktop app, they have the browser app, they have a mobile app.

So a lot of what needs to happen is being handed off to another server anyway. So if they just need a nice interface and wrapper, then there's a lot less need for all of the extra stuff that Next.js provides and wants to pack into your application. And I think Remix is that much lighter weight way to still have the React code that you're familiar with and the JSX syntax and all of the things like that, but still be able to say, I really only need a lot less [00:25:00] than what Next can offer me.

And,~ uh, ~actually that, that makes a lot of sense when I think about it. Plus it's using Vite. Which is just faster and better than Webpack in every way. And Next.js is trying to make it better with TurboPack, but it's still not as good as Vite. And it's not as easy to use as Vite. And,~ uh,~ yeah, I think ~that ~that's probably a big part of it.

Is that there was just so much that Next.js wants to do for you. But if you don't really need it to do all that stuff, maybe you don't need Next.js, period. Okay.

Emily: integrated now? Is it going to become like the next react? Not that it is going to be react, but ~like ~react more of a legacy thing that is integrated [00:26:00] heavily and we'll never get rid of it. What are your thoughts?

Chris: ~I can go if no one wants to go. Uh, ~I don't think so. So these are like ~my, ~my current just thoughts in my own mind. And don't quote me on this. So I think Next.js is great. I use it. I've been using it for a long time. ~Um, ~especially if we're just trying to get things out the door pretty fast. It helps you,~ um,~ handle all that. my opinion, I've, this is just like a general observation. I feel like their focus is now shifted towards AI and V0, and that's going to be their main thing. I don't really, and maybe it's just the bubble I'm in. I don't really see anything happening with Next.js at the moment. It's really ~like, ~he's V0, it's doing very good.

Look at our new, a new implementation. ~Um, ~so I actually think. Next.js is going to end up taking a backseat to the v0,~ um,~ effort in my mind. I think that's a smart move for them from just using it. I think it's very good. ~Um, ~obviously at the end of the day, it's still implementing, ~you know, ~stuff in their way or whatever.

And I think the play of getting ShadCN,~ um,~ with that UI, I actually think there's going to be some kind of component [00:27:00] play at some point. ~Uh, ~I don't know what that is. That's just my hunch. I just Thought of it right now as we're talking about it. ~Um, ~but yeah, I don't know.

Emily: Yeah, that's actually a great segue. ~So, um, ~CN UI was integrated into V zero. ~Um, ~and I saw. ~Um, ~I think making a component. ~Um, ~and it was so simple. Like I could do, ~I'm not, ~I'm not an engineer, but like I could figure that out. And I thought that was incredible. So I, and again, we ~kind of ~touched on this at the beginning of the episode, but like, How do you guys feel about AI now being integrated into these existing infrastructures and finally feeling like it's not just freewheeling everywhere that do you feel ~like, like ~Chris, you're saying,~ uh,~ Versal might be focusing more on this AI.

Do you feel like we're now going to get very useful tools like this? And ~what do you, ~what did you think of the integration of Shed CN 

Paul: Their blocks stuff is really cool. Is that what they're calling it? The blocks?~ Um ~where it assembles a bunch of components together for you. ~I like that because I can't even ~As a more back end leaning [00:28:00] person, it's nice to just see the ideas organized as long as you're specific And something that Paige touched on is as long as you're specific it does those things that are just they just hurt to do, it's ~kind of ~like lifting that one pound dumbbell and when you're on like so many reps you're like this is doing nothing for me and it hurts a lot.

~That's, ~that's what doing like the random like double nested for loop sometimes feels like or ~like, ~Oh, I need to do a search function. So now that it's at a point where it can integrate into my tool and use that reliably as long as I'm specific enough because it's indexing the code with vector stores or whatever like. Really enjoying it. And the blocks thing from ShadCM, being able to have those component blocks is, I don't know, it's sniffing in a really interesting direction, especially for the front end assembly of ideas.

Paige: ~I mean, ~to go back to your initial question of if Next.js is going to go the way of React where there's, ~you know, kind of ~a lot of negative sentiment and baggage around it,~ I,~ I think it's got a little bit of that to deal with, because it did have the pages router to start with, and then it changed to the app router, and [00:29:00] basically, if you didn't want to change off of that, or it was a pain to, A lot of people just stayed with what they knew.

So there is some legacy code that Next.js is going to end up having to keep supporting for who knows how long, because there are entire businesses built on the pages router, and they're just not going to go away from it because it does what they need it to do. They don't need the RSCs. They don't need the newest version of React. But at the same time, I think that there is just ~kind of. ~It's just that the shininess of Next.js has worn off, and there are new frameworks that are shinier, that are faster, that have introduced new ideas or newer ways of doing things, ~and everybody, ~and devs love to talk about it, they love to try it, they love to do it.

But at the end of the day, it comes back to having something that you know is stable, and it's going to keep running in production, and Next.js is a really good bet for that. ~I mean, ~even the react documentation itself says, please use next JS if you're going to build a react app.~ Um, ~so I don't think that it's necessarily going anywhere, but I could also absolutely see ~what, ~[00:30:00] what Chris and Paul are talking about, where it's going to get less press than,~ uh,~ some of the new shiny AI tools that we all want to talk about and try out and see what they do and then complain about them because they didn't do exactly what we envisioned the first time.~ So, ~yeah, ~I mean, it's, ~it's definitely, Vercel is a company, they're there to make money and AI seems to be where the money is going, so they've ~got to, ~got to offer that up or else somebody else will, and they'll start to fall behind. So yeah, invest in AI cause seems to be where everybody's going these days.

Emily: ~Alright, any other thoughts, Chris?~

Chris: ~Oh yeah.~ I was going to say ~like, ~I think there was an initial spike of ~like ~Next.js,~ uh,~ especially with 14 when RSEs came out, cause they were the first framework to get their hands on it. And now at this point, everyone's slowly starting to catch up. You ~kind of ~lose that edge, right? ~Um, ~but ~I mean, ~for some of like we mentioned, ~they have, ~they have other tools, they have TurboRepo, they have V0, those are two other great tools.

I love TurboRepo, it's probably one of my favorite Monorepo tools, but it's ~like, ~at the end of the day, like Paige said, they're a business, if we can't acquire them into our framework, how else can we [00:31:00] make money out of them? That's potentially through AI, that's potentially through Monorepo tooling or so, or what have you.

~Um, ~and I'm not going to fault them for that. ~I mean, ~at the day, they got to make money. ~Um, ~but I do think they are going to continue creating very cool tools for front end ecosystem. So I don't expect anything short of awesome coming in the upcoming years from them. So

Paul: also feel like Remix and Next.js, they're just so distinctly different in the, in ~like ~the persona. That they're catering to in terms, not only for ~like ~the individual coding it, but like, how are you loading data and are you a old fashioned like web standards, we're going to do everything like by the book sort of way which like has a lot of awesomeness to it for some applications or out of the box magic.

Also great for another set of applications, and it's hard to see a world where ~like ~one exists but not the other. They both have to exist in harmony.

Paige: They've pushed each other to be better and ~adopted. ~Adopted things from each other as well.

Emily: ~Any final thoughts before we hop into our hot takes? Awesome. All right. Okay. ~Now is our favorite part. Our hot takes when our panelists give us [00:32:00] their hot takes of the month. And I'm going to go around. You guys can just go off. We have about 10 minutes before we have to start wrapping up. ~So. ~Two minutes to give me your spiel.

We can talk about it and we'll keep moving. ~Uh, ~Paul, what is your hot take for this month?

Paul: ~Uh, ~that Nvidia is just way too overhyped. And I know everybody knows that just from the stock price alone, but in general, ~like ~you still talk to people even devs who love AI and they're like, Oh, yeah, ~just ~you need ~like ~so much VRAM and Those cards are so expensive and it really boggles my mind how little hardware, as long as it's good hardware, you need to actually run these models, and I have a MacBook Pro Max M2 with a broken screen, the screen cost too much to repair, it just died, right?

Sorry Apple, the laptop screen kind of sucks, but the screen just died, didn't have money to repair it, it was one month out of warranty, so I'm just running a llama model on it and it can run 70b slow but it can [00:33:00] run it and at first I thought I had to buy ~like ~seven grand and gpu cards and now you can have like unlimited copilot at home on a laptop so I'm still struggling to wrap my head around why nvidia is ~the ~the only seller of the gold shovels and ~um ~there's such a hype train around it when I'm running it on a 90 watt piece of hardware in my closet so y'all should go try that before buying a bunch of nvidia stuff

Emily: ~Interesting. Any, any comments on that?~

Paul: And you don't have to pay for OpenAI, ~you know, ~or Clod, ~you can, ~you can legitimately run a pretty good model~ in your, ~in your own house.

Emily: I would expect nothing less from you, Paul.~ Uh, ~Paige, what is your hot take for this month?

Paige: My hot take is that,~ uh,~ coding in the browser is not going to be the standard that people keep trying to push ~it. ~I think everybody who has a decent machine, who has a VS Code setup, is going to stay in it. I personally am. ~I, ~I've tried CodePen, I've tried StackBlitz, I've tried GitHub Copilot Workspaces.

And nothing feels [00:34:00] nearly as comfortable to me in the browser as it does working on my local machine. And ~I think that, ~I think that you're going to be hard pressed to get developers ~who have done that, uh, ~who have grown up with local IDEs to be okay with browser based, even if their settings import and their, ~you know, ~favorite extensions are there.

It just doesn't feel the same. And ~I, yeah, ~I don't think that it's going to take off in the way that they're hoping that it will.

Emily: Any comments on that one?

Paul: I'm here to support that page.

Paige: Thanks, Paul.

Emily: ~Uh, ~no. What is your hot take for this month?

Noel: ~Um, I feel like I was, ~I saw a lot of hype around,~ uh, ~instant DB the last few weeks. How do you guys know about this? It's ~kind of ~like a firebase database as a service open source thing. ~Uh, ~but ~it got, ~it got me reflecting a little bit and I feel like a lot of people are still sleeping on the database layer that super base built and is also open source and works very well.

And ~like, ~there is ~some, there's ~new tools and stuff in the market that are emerging, but ~like, ~I feel like super base built some really cool tech and like people. Sleep on it all the time. It's ~like, ~go check out this suite, ~like ~hosting service platform that you can ~like ~run locally. And ~like, ~there's all this [00:35:00] cool stuff here that I feel people just aren't talking about.

I don't know if this is a super hot take, but I was just hacking out one of my projects and had ~like ~generated types based on a SQL definition file that ~like, ~we're getting injected in my project in real time, like as I built, ~I ~this is wild,~ like,~ this is such a cool project.

Emily: No,~ we, ~we love hearing about the tools you're using. And also if you want to learn more about super base, we've got a lot of super base episodes. So go into our archive. We have them.~ Um, ~Chris, what's your hot take? Do you have a hot take this time?

Chris: I've been actively thinking while ~everyone was, ~everyone was going, but I will say,~ um,~ I know we talk about AI every time I'm ~on this, ~on this panel. ~So I'm going to say, ~I used to be very anti like co pilot, like, Oh, you don't need that. You're fine. But now that I've ~kind of ~been using it for the past month, ~you know, ~I'll eat my words and say, it's actually been pretty good, pretty tasty.

~Um, ~I'm not saying use it for very complex stuff, but it has been making,~ uh, ~my life a ton easier. ~Um, ~but also be careful. Don't ask it everything and get worse at engineering. ~Keep your, ~keep your mind sharp. all I got.

Emily: finally drank the Kool Aid. Everyone's getting in on [00:36:00] this. Awesome. ~Uh, any, any closing thoughts before we wrap up? Love that. Okay. Um, ~thank you everyone for joining today. Thanks for discussing as always. ~Um, ~if you liked this episode, please message me on Twitter. If you have any topics you want us to cover,~ um,~ I'm hoping to do another mailbag episode in the coming month, hopefully. So if you have any questions about web development that you want our panelists to answer, please let me know.

~Um, Everyone, uh, everyone, uh, ~where can people find you online? Paul.

Paul: So I've actually started posting on my YouTube channel again, finally. So if you just search up Paul Mikulskas, M I K, not like Mickey, not like McDonald's,~ um,~ you can find some videos that I'm posting. ~Uh, ~I've been loving posting about Nadin, which is like a no code automation workflow, which is funny because we're all coders, but it's ~kind of ~funny bridging that gap between us and everyday people.

So yeah, check me out on YouTube.

Emily: ~Sick. ~Yeah. We'll definitely have the link in the show notes,~ uh,~ page. Where can people find you?

Paige: I'm still hanging around on Twitter, so you can find me at P Nidri, E N I E D R [00:37:00] I, because I did not choose the same username that I use for every other social platform, unfortunately.

Emily: That's so annoying.

Paige: I know. ~Just let me have it. You've never tweeted.~

Emily: ~Oh God. That's even worse. Um, ~awesome. Thanks Paige. ~Uh, ~Noel, where can people find you?

Noel: You can find me here. ~I'm, ~I'm ~kind of ~a hermit. I'm technically on blue sky at Noel and OEL. com. M I N C dot H O W on blue sky, ~but~

Emily: ~We can,~

Noel: ~just as good as any.~

Emily: we can always find you here. ~Uh, ~Chris, where can people find you?

Chris: Can find me in the Twitter verse at, ~uh, Trash for 200, but~ trash with two H's underscore dev.

Emily: Still trashed. I love it. All right. ~Um, ~thank you everyone. If you are listening and have any questions, DM me on Twitter. ~Um, ~I don't remember my handle, so it will be in the show notes, but,~ uh,~ thank you everyone. ~Uh, ~hopefully we will see you guys next month. ~Uh, ~thanks for chatting.

Chris: ~Thank~

Paige: ~Thanks for having us.~

Noel: ~Yeah.~

Emily: ~All right.~