NextJS VS SvelteKit in 2024...

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
a question I get asked all the time and I've been really resistant to answer is nextjs versus spell kit in 2024 and I want to say at the outset of this video that I think both of these Frameworks are excellent I really like what both of them have done I'm a huge fan of the server component model I'll kind of talk about why in this video I think it makes a lot of sense and while it is new it is tricky there is going to be some learning that goes into it I think it will ultimately create a much better full stack experience for everyone but we do have to stick our head into this like okay we're doing things in full stack now like that's kind of the way all of these meta Frameworks are moving and while I personally really like that I know a lot of people in the comments a lot of people I've talked to don't so that is definitely a thing that's happening here but I do think both of these Frameworks are really good but they are very different and I think the way that they do things is very different the mental model is very different uh and today I want to give you guys the reasoning behind why I prefer spel kid's model over next js's model I think the best place to start is going to be going going over how each one handles data fetching and I want to visualize how this sort of works now unfortunately I do have to give a sort of caveat here and this is why meta Frameworks can be tricky and why I think a lot of people get so confused with all this stuff on the client versus the server because this line like this is this is a hard line these days because we have stuff which will only ever run on the server and I'll talk about that what that is in a second here but we also have stuff which runs which can run on the client but won't always run on the client like client components and page. spelt files they are technically like you can think of these like client components they'll run on the client which is the user's browser but the problem is with SSR they will generally be run and pre-rendered on the server so they will actually still be kind of run on the server at the same time but for the sake of simplifying this a little bit we're just going to say the client is any of the reactive stuff which gets shipped down to the user the state variables the effects all that stuff which they can interact with and we're just going to simplify and say that page. TS and client components are only run on the client even though yes they are SSR I know it's just it's kind of a tricky distinction these days um so to begin let's talk about data fetching and let's first talk about how nextjs does data fetching um and this is going to be entirely in the server component model if we look at the server component model the server component itself can talk directly to our database and drizzle is how we're communicating with our database so our server component can call drizzle directly we can fetch data in here but the trick is this can also render out UI we can also put a lot of our UI and we can take that data that we fetch in just a top level of weight in our server component and we can print that out on the screen I will talk about this in more depth later when I show some code but I highly highly recommend you guys because I'm not going to get as deep into it check out Jack Harrington's video on server components he does an amazing job of breaking down the sort of Steelman case for why these are so good he shows a bunch of examples of why it makes so much more sense in this new model to just be able to say okay fetch my to-dos here at the top and then print them all and then print them all out down here it's a great model and it makes a lot of sense and it really does kind of feel like magic but the thing is these are just regular react components that execute on the server and can and can connect to our database and then on the client side of where we need to get reactivity our effects our state all that stuff then down here have our client components and these client components can get data passed down into them from server components so we could go in here we could fetch all of our to-dos but if on one of the to-dos you need to go ahead and have some like State variable manipulation stuff we pass that data down into our client component and our data flows like this so it's flowing through a bunch of react components it's just that some of these react components execute on the server some of these react components execute well again it's not it's not a clear line but for the sake of argument I'm going to say some of these react components execute on the client so that's the sort of model for how nextjs data flows and you'll notice there's no like dedicated data fetching backend route we can obviously have like a server directory or whatever where we have functions which will call the data which just wrap the database calls and stuff which we then call within our server components but it's still basically just directly going in a in a react component querying our database and this is one of the things that's confused me the most about a lot of the server component drama and stuff is like this is a dream like when I back when I started doing nextjs and I started doing React 2 years ago I would have loved to have been able to go in my component and just grab stuff from my database it makes so much sense it's such a great model for building full stack apps or even just querying a separate backend I mean if you have a separate backend team you could still just replace this little drizzle logo with a little goang back end we fetch our stuff up there it works now let's talk about how spell kit does this and spell kit does do this differently spell kit instead of having like server components having pages that render on the server which again they do but just you know you know what I'm saying instead of having Pages which run on the server we have a load function so we're going to have our plus uh page. server. TS whoops we're going to have our page. server. TS and this page. server. TS is going to have a load function in it whenever we go to a page this load function is going to fire this load function is basically just a get request which is called on Mount it's very similar to get server side props from old nextjs and this will connect to database this will fetch our data and then it will send it down to our client side code which is our page. spelt so we send it down to our page. spelt we do this and now we have our data but the thing is we're not rendering UI and stuff up here this is not executing this is not UI code this is purely just a load function versus this can actually be UI code and this can also be reused because there is some Nuance here which I didn't get into where technically we could go down here and uh whoops let's make that blue uh we could go down here and we could have a another just server component chilling down in here we could just put another server component down here you can do some wild stuff with that if you imagine a UI where we have like a Navar and then we have a sidebar or whatever we can reuse that sidebar over and over again and we can just have all the data fetching logic built into it and we can just reuse it over and over and over again because that's really cool again check out Jack Harrington's video he does a great job of explaining this in depth um in Sp we can't quite do that as much it's very much just taking okay here's a page and here's a load function on that page and we can do stuff so we have these two different models which one do I personally prefer I personally prefer the spelit model to me it makes a ton of sense to on a website go from page to page when you hit a page you fetch some data that's just kind of makes a lot of sense to me it's kind of what PHP used to be back in the day but if you look over here at um this is the full stack e-commerce I've been working on if we look here at our products page so this is our products route I have my page. spelt and I have my page. server. ts so there's a really clear distinction here where it's like okay this page. spelt this is the client side code which renders out the page does all this stuff and then I have up here at the top I have this nice little export let data this export let data is how I'm actually grabbing the data out of my load function fully type safe and end type safety which both of these get one of the problems with old nextjs and get server side props is type safety was a on that it's not really a problem anymore because we're literally querying out of the database in the clients in the components so it makes a ton of sense but then if you go over here I have my nice little um page. server. TS and I know that all of the different serers side actions and load functions which are associated with this page are just right here so I know that whenever this page is loaded I'm also going to grab everything in this load function so I just can get everything we need in here and to me that makes a lot of sense and that works really well this is a little different from nextjs wherein if I was on my homepage so I was in my root directory page. TSX if I wanted to do const data equals a weight uh weight fetch data imagine that function exists I can now just use this data within this I can now just use this data within this component right away it's all wrapped in together and this creates a really nice system where we can go into our like this example here of this slow load add this asynchronous load function which I can go down in here I can call this and then we can return this data if we look at this site um live here it'll give it a second to load we go here it'll say loading feed it's going to take 5 seconds and then at the end of it we have just loaded that feed and the way I'm able to accomplish that is with these suspense boundaries with this nice little slow load and the fallback it all just works we're fetching the data directly in what is the UI component and a lot of people like that for me personally I do like this separation I like having my load function up here and then having my client side stuff down here it just makes sense another really cool thing which I wanted to show off which you can do with the spell kit model is we since we have these page. server. TS files and we have these load functions whenever we go to a route this load function will fire so that means that we can put a lot of the like checks and stuff for that route in that load function a great example of this is authentication so like in the e-commerce site if you go to the login page if you're already logged in we don't want you just go into the login page again we want to redirect you to the profile page and we can do that in the load function it's like you have this serers side method which will run every time you go to the page and it's just there we can do that same thing in next that does totally work you can make that happen with the server actions or with the server components sorry but for me I really like the way this sort of works I like having access to these another important thing to talk about here is going to be the way you can run server actions and you can run post requests to your server to mutate and handle data I'm not going to go too deep into this one because to be honest it's fairly similar between the two they both support Progressive enhancement it's basically just in next World we have these functions which we can call which are always run on the server we can pass in form data to these we can handle these with Progressive enhancement do all that different stuff um you can see I'm just using the docs right here because they have a really good example of basically just like right here we have this create function it will execute on the server we can pass this into our client components handle it there it's just functions injs which we can fire spell kit is a little bit different these in spell kit they work more like just kind of HTTP post requests and they're also very heavily tied to forms they're called form actions for a reason in spell kit the form actions are very heavily tied to forms if you look right here I'm grabbing my form data I'm validating it doing all this stuff and running all this stuff it's basically just the post request to update the basics of a product if we go back to our page. spelt here you can see all we're doing here is we're just saying okay we have this form it's method post and whenever we submit this form it's going to call the form action which is attached to this route so we have these actions which are heavily tied to these pages and that's kind of the theme of spell kit is everything is we have these like sections in these pages and they have load functions and actions which um which are all kind of just grouped together which we can use in this really nice link we have our server side stuff and our client side stuff they can communicate back and forth really well and I really really like how it feels and if we go back to our page. spelt here you can see it's not just a basic form post request we can also use the enh do we can also add the use enhance directive to have basically a call back here which will overwrite the redirect or whatever we want to do we won't reload the page when we submit this form we'll submit it we'll do all our stuff and then we'll grab our result down here we can check if the result is successful then we can do a bunch of UI logic here without having to completely refresh the page so we get the benefits of being able to update stuff in the client do optimistic updates all that kind of stuff we could run optimistic updates up here when it runs all that stuff just works while also getting the benefits of having these just kind of be normal form actions we can do all that stuff in here we can get our optimistic updates we can return our data we can uh we can mutate our data afterward or we can just use these as normal post requests to our server which would be form submit events it all just works super well and to me it's super intuitive I love the way this works and to close this video I want to talk about the two underlying Frameworks for these big meta Frameworks and that would be spelt and react this is one place where I really don't have a super strong opinion I am not at all super anti- react I think react Works super well strong Primitives are great the libraries and ecosystem is fantastic it has its quirks use effect kind of sucks I kind of hate it but like I've built production apps with react many times it works really well I don't to be honest I didn't make the decision that I prefer spelt kit over re or over next gen JS because of react versus spelt I think spelt is great um I know some people have a problem with the like um I know some people have a problem with the hijacking of JS and some weird stuff it does where we have like this each directive where which is not which is kind of weird and when I started I did have to look this up a lot but you know once you get used to it it's really not a big deal same thing with the if statements I get it it's kind of weird it's not like jsx where it is just JavaScript which returns a bunch of tags I you know I get why people don't like that and I also totally get the argument against it where just having these random State datas these random State variables floating around that are not explicitly bound can be a problem but that's all getting fixed in Sp 5 so it's really not that big of a deal and to be honest the biggest difference for between the two of them for me and this is a super Niche use case which probably doesn't even apply to you is that I don't like the virtual Dom and react because I have to use libraries which don't interact well with the virtual Doms so I don't want to deal with that and spelt doesn't have to deal with that so building stuff in spelt makes more sense but and I I guess another thing too would be the sort of like UI library and the the big argument that people make against spelt or any of these different Frameworks is that their ecosystem isn't good and I can tell you from experience I built production apps in both spel kit and in nextjs the ecosystem in both of them is fantastic obviously next ecosystem is beyond spelts but everything I needed was here Shad CN for spelt works great Lucia great authentication Library uh for the database we have drizzle that works in both of them we have all of the different things you would need to build an app there's no ecosystem problems in spelt right now I think maybe we need to create some better systems for bootstrapping apps and there could definitely be more templates and more guides and more stuff like that but you know as far as looking for like UI components and things to make it work better there's no shortage I think spel is just fine in that department and obviously nextjs is fine in that department so so to close this video I want to say this both of these Frameworks are excellent they work really well they do a really great job of solving the problem and you can build fantastic production grade apps in both of them I personally prefer spell kit it makes the most sense for me I sort of talked about why I hope that makes sense I built stuff with it I'm going to continue building stuff with it next but nextjs is still a really good option if you haven't given server components a try or any of these different things give it a shot try building something in both of these and see which one is more organ OMC to you because genuinely I think at this point these are all getting so good and I think Vue or knjs and Vue is in this bucket too I think these are all getting so good to the point where it's really just pick which one is your favorite and then run with that there's no objective best pick here and I think that's really awesome so if you guys enjoyed this make sure you like And subscribe and I will talk to you soon
Info
Channel: Ben Davis
Views: 7,922
Rating: undefined out of 5
Keywords:
Id: 7RQMxJNBqpo
Channel Id: undefined
Length: 15min 50sec (950 seconds)
Published: Thu Feb 22 2024
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.