It's really quite simple. If you are more MVC minded, you are not going to like RSC's. React was inspired by XHP which was a component-oriented architecture and the "concern" has always been the component. RSC's componentize the request/response model. React has moved further away from MVC and closer to their component-oriented vision. This has ruffled a lot of feathers just like JSX did back in the day when people were complaining about "separation of concerns".
Started using svelte+sveltekit and agree with all you said Now I’m learning next js, mostly to understand how it works and adding that tool to my set of tools, but… I’m staying with Sveltekit for the moment, it just works super great
Here's the issue with NextJS; say you have a database with 10m todos, if you are to fetch all that on the sever when rendering the page then it's going to take some time before the user is able to see the page; Remember if you overworking the server then it's going to be a bad experience for all the users. This becomes an issue when you have stuff like dropdowns, accordions or any kind of input/data driven components; You don't want to fetch the data upfront unless the user is interacting with the component. I think this "hype" is something created by the cloud software companies like Vercel to boost their revenue. The more server side resources you consume, the more you have to pay these companies, draining your pocket and filling theirs. Don't go with the hype, think before you code!
Well that‘s why you don‘t do that. Blocking the initial page load until some potentially long running operation is done screws you no matter which Framework you use. You need to learn about React Suspense. Understand how to use the tech before starting to complain about it.
The only thing I hate about nextjs is that it's hard to host it anywhere other than vercel or something like netlify, and we all know vercel's pricing isn't the cheapest
Yea I have heard horror stories about next on other platforms. Vercel is great at small scale but yea the pricing as you scale is absurd, a literal 5-10x markup on AWS sucks a lot
The same thing happened to me with sveltekit until I decided to just create a docker image and deploy it on railways. With docker, deployments are much easier.
I prefer sveltekit, but had to switch to nextJs because of the community and the amount of libraries and plugins. UI libraries, Datatables, Full proejct examples online, etc.
Svelte can use any vanilla js library, typically with no extra effort. Worst case scenario you simply use the library in a js/ts file and then export the functions and classes you need into your svelte file.
The only thing that keep me on Svelte/Kit is transitions. So easy that I can't live without it anymore. Until Leptos (Rust) or someone willing to commit to Zig and do something similar I do NOT think I will ever leave Svelte/Kit behind.
@@NathanielBabalola First, I don't know Vue but taking a look at their docs seems like you need to do some CSS and this is a matter of your opinion. I think Svelte is simpler but not as customizable as Vue (although you can create custom transition in Svelte, It's a pain). Why Svelte is simpler is that you don't need to do CSS and just `import { fade } from 'svelte/transition'` and just use it on element directly: `This will fade in and out on create and destroy` You can take a look at the examples. Just search for '{framework} transitions'.
@NathanielBabalola If it is about transitions, In svelte it is just include "transition:fade" , "in:fade" or "out:fade" in html tag just like that. And about Vue you have to declare CSS class, I don't know if there is any other method in Vue because I just use UI framework. If it is about front-end only framework then I don't think it is that much of a different. In Vuestate is ref() in svelte 4 is just "let" and in svelte 5 is $state(). Vue use Virtual DOM while svelte not. If you understand how state works I don't think you will have a problem switching between different front-end framework. It is just a state with different underlying method like react state use hook, Vue state use signal.
The problem is typing. And by that I mean both creating types and pushing buttons on your keyboard. When I use a typescript backend I can enforce my apis to conform to a specific model and the important part is I only have to write it once. I don't have to make sure that my models in whatever language match my models in the front end, because I can use the same models. It saves so many headaches. Go is great in a lot of ways, but writing everything in two languages just isn't worth it unless you have a specific backend use case that requires a high level of multithreading for some reason.
@@zBrain0 "writing everything in two languages just isn't worth" Oh my fucking god. We it rock bottom. You literally just said that writing a backend in a proper language that is not fake type safety is not worth it. Just just fake type safety, good look maintaining that project dependencies in the next 5 years. I'm doing that right now and its a pain in the ass. But yeah, If you wanna keep doing your startup bullshit and side gigs, use whatever you want.
" If you wanna keep doing your startup bullshit and side gigs, use whatever you want" If you're saying you wouldn't write your startup in Go, aren't you agreeing with the main point of the video?@@Kats0unam1
"real backend language" is silly but I get what you're saying. There's no silver bullet and it's all tradeoffs. For a production grade application there are more things to consider, but for solo dev side projects, it's a much better experience writing everything in one language.
@Kats0unam1 ok son. Apparently you have never tried supabase. Good luck when your backend team makes a change and your api breaks because by definition you can't guarantee they are going to match. Have fun with that.
Unfortunately I don’t have time to study and stay proficient in 2 frontend frameworks, and money is currently in Next, so that’s where I am at the moment.
@@Indonesia_Emas_ couple of days to learn frontend? have you worked on a large codebase before? Implemented features no library exist to help? If you can learn frontend + every popping frameworks + ui frameworks + libraries in just couple of days. Salute to you.
How can one say that Svelte ecosystem is not great? I guess that's your biased "react devs". Svelte ecosystem is JavaScript ecosystem. You can use any library that is out there. On the other hand, to use libs in React you need some weird bindings (aka "the react way"), which have nothing to do with JS lib, docs often aren't there or are clanky at best, etc - eg Apache eCharts is a great example - amazing to work with in Sveltekit (even when doing the most complicated stuff well beyond the docs) and abysmal experience in React/Next world (to even run the simplest charts). And that's only one example, there are countless out there. With Svelte 5 it will be even better. React is just bloated mess at this point.
Yea this is a good point honestly, what I more mean when I say react has better ecosystem is that when a company makes an SDK for their thing, 9/10 they will have a special optimized one for react, but not for the other frameworks and you have to work around it which can be kinda annoying
In sveltekit the load function stop the routing until tge data fetching complete and if you are thinking about stream with promises. Then it won't be server rendered. Where in nextjs suspense data can be found in pageview html data. Its a huge with for Nextjs
Await each data object seperately in your load return. Like return { await dataObjectA, await dataObjectB}. Then when they are brought into your page they will load individually, lazily
I can't deal with the lack of nice UI kits in Sveltekit anymore. I value my time in that matter... Writing react doesn't seem like a pain after seeing how many hours you need to spend to get a professional looking app with Svelte.
"I can't deal with the lack of nice UI kits" sounds like you build multiple sites a month which all of need a completly different UI the big names are literally usable in svelte. and saying "value my time" just means ur too lazy to write your own styling. this will be an issue no matter the framework you choose
Second vote here for shad cn svelte. With either some copy and pasting or a few command lines you have a set of components that have really good defaults and if you want to you can customize them. Problem solved. React had its day in my opinion, but with tiny bundle sizes, soon to be really crazy accurate levels of reactivity in version 5 and just a hell of a lot less boilerplate for me it's not even worth considering react in 2024
Qwik is not that appealing because of too many requests for user interaction, normally it is better to expend 3 seconds for the page to load and user interaction be instant than load the page instantly and user interaction takes 500ms Astrojs with island architecture is the way if you want really good SEO scores Nowadays people are focusing on HTMX to reduce web development complexity
Yeb, indeed, the way of splitting the client side of server side in Sveltekit is pretty good, plus, if we can call it merging them in the "Form Actions" in a magical way, I think that's what makes Sveltekit more predictable when dealing with "Form Actions" !!!
I used to develop using Laravel, but not going back. I really don't see what's better about it, it works even slower than node/bun based frameworks, worse type safety, the PHP itself is even worse than JS in terms of dx
Here is an idea from someone who used to follow you and doesn't anymore, because I think your takes are questionable: How about we dont use a fake type system like Typescript on the server and use a proper language (C#, Go, Java) on the backend and just use Typescript for what was intended to, aka, manipulate the DOM on the browser. I have a medium side project that will go to prod maybe next month with Go, HTMX, Templ, Tailwind, PGX. The only js dependencies I have are arc to display some curved lines on openlayers, htmx, and tippyjs to display some tooltips on the map. I installed tailwind though the CLI which means I have 0 need for node_modules and package.json management. 0 js library dependencies and maintenance in 5 years when I want to add / bug fix my projects ? Count me in.
I'm not an expert, but SvelteKit has this nice thing were you are in a sense more "declarative" in your construction. You load all the data you need to build your page. Then you use the data to build your page. In your page you have a bunch of forms that allow the user to submit information that will potentially change the data on the server. Now the fun part is that you don't have to worry about updating all the potential parts on the page that will have to be updated with the new data - you just call to "invalidate" those fetch requests whose data may have been affected by the form submit. You could write an API backend in Go and still use SvelteKit, but it seems the issue is that you end up writing stuff twice, types become more painful.
I've said before and I'll say again that I pretty much agree with this, its just that for MY use cases, fullstack TS is better. I am on a small team that has to move fast, I have a separate go in backend in prod rn, and it sucks to maintain. No one disagrees that Go is a faster/stronger language for the backend, its just that TS can get the job done. And it gets the job done way better then I think people give it credit for...
@@bmdavis419 "you end up writing stuff twice, types become more painful" yeah so.. what you mean is... you have to... type.. code ? Crazy concept. You write typescript and you dont enjoy writing type for the backend schema. There is a solution for that, its called Javascript.
I dont understand why people are so mean. You dont Show your face in Public as he does. You can have your own opinion but unless you dont speak in public you wont help anyone or change anything. @bmdavis419 Keep on sharing your thoughts, always nice too see how others are looking at the current situation.
@@dave-7117 appreciate it man, honestly I don't really care if people are mean on the internet, it gives more engagement which helps the channel and I earnestly believe in what I'm saying/making and thats enough for me
I use SvelteKit with Rust ActixWeb as a backend....fast as hell and simple enough....
It's really quite simple. If you are more MVC minded, you are not going to like RSC's. React was inspired by XHP which was a component-oriented architecture and the "concern" has always been the component. RSC's componentize the request/response model. React has moved further away from MVC and closer to their component-oriented vision. This has ruffled a lot of feathers just like JSX did back in the day when people were complaining about "separation of concerns".
Yep
And Which most jobs required MVC experience right?
Exactly why I prefer Sveltekit
@@mwlulud2995SvelteKIT isn‘t exactly MVC either.
Started using svelte+sveltekit and agree with all you said
Now I’m learning next js, mostly to understand how it works and adding that tool to my set of tools, but… I’m staying with Sveltekit for the moment, it just works super great
Me too... sveltekit it's all i need.
Here's the issue with NextJS; say you have a database with 10m todos, if you are to fetch all that on the sever when rendering the page then it's going to take some time before the user is able to see the page; Remember if you overworking the server then it's going to be a bad experience for all the users. This becomes an issue when you have stuff like dropdowns, accordions or any kind of input/data driven components; You don't want to fetch the data upfront unless the user is interacting with the component. I think this "hype" is something created by the cloud software companies like Vercel to boost their revenue. The more server side resources you consume, the more you have to pay these companies, draining your pocket and filling theirs. Don't go with the hype, think before you code!
😂😂 you need to learn more about web performance
Well that‘s why you don‘t do that. Blocking the initial page load until some potentially long running operation is done screws you no matter which Framework you use. You need to learn about React Suspense. Understand how to use the tech before starting to complain about it.
The only thing I hate about nextjs is that it's hard to host it anywhere other than vercel or something like netlify, and we all know vercel's pricing isn't the cheapest
Yea I have heard horror stories about next on other platforms. Vercel is great at small scale but yea the pricing as you scale is absurd, a literal 5-10x markup on AWS sucks a lot
There are videos on TH-cam on how to host Next on other platforms
If you want Serverless good luck, and SST is not a solution still young still has many problems, we tried it. So docker or vercel it is 😅
The same thing happened to me with sveltekit until I decided to just create a docker image and deploy it on railways. With docker, deployments are much easier.
@@miguelalzate4850 Really? I was thinking that sveltekit didn't have that problem, I hope that the new version of SST will fix some issues :D
I prefer sveltekit, but had to switch to nextJs because of the community and the amount of libraries and plugins. UI libraries, Datatables, Full proejct examples online, etc.
Svelte can use any vanilla js library, typically with no extra effort. Worst case scenario you simply use the library in a js/ts file and then export the functions and classes you need into your svelte file.
I'm the other way around, I come from React too and definitively don't miss it. But server components seem very appealing.
The only thing that keep me on Svelte/Kit is transitions. So easy that I can't live without it anymore. Until Leptos (Rust) or someone willing to commit to Zig and do something similar I do NOT think I will ever leave Svelte/Kit behind.
Is it easier than Vue ? I'm a Backend Dev looking to go Fullstack, trying to choose between Vue and Svelte.
@@NathanielBabalola First, I don't know Vue but taking a look at their docs seems like you need to do some CSS and this is a matter of your opinion. I think Svelte is simpler but not as customizable as Vue (although you can create custom transition in Svelte, It's a pain).
Why Svelte is simpler is that you don't need to do CSS and just
`import { fade } from 'svelte/transition'`
and just use it on element directly:
`This will fade in and out on create and destroy`
You can take a look at the examples. Just search for '{framework} transitions'.
@NathanielBabalola
If it is about transitions, In svelte it is just include "transition:fade" , "in:fade" or "out:fade" in html tag just like that. And about Vue you have to declare CSS class, I don't know if there is any other method in Vue because I just use UI framework.
If it is about front-end only framework then I don't think it is that much of a different. In Vuestate is ref() in svelte 4 is just "let" and in svelte 5 is $state(). Vue use Virtual DOM while svelte not.
If you understand how state works I don't think you will have a problem switching between different front-end framework. It is just a state with different underlying method like react state use hook, Vue state use signal.
I'm a staunch proponent of using a real backend language for your backend, like Go.
The problem is typing. And by that I mean both creating types and pushing buttons on your keyboard. When I use a typescript backend I can enforce my apis to conform to a specific model and the important part is I only have to write it once. I don't have to make sure that my models in whatever language match my models in the front end, because I can use the same models. It saves so many headaches. Go is great in a lot of ways, but writing everything in two languages just isn't worth it unless you have a specific backend use case that requires a high level of multithreading for some reason.
@@zBrain0 "writing everything in two languages just isn't worth"
Oh my fucking god. We it rock bottom. You literally just said that writing a backend in a proper language that is not fake type safety is not worth it. Just just fake type safety, good look maintaining that project dependencies in the next 5 years. I'm doing that right now and its a pain in the ass.
But yeah, If you wanna keep doing your startup bullshit and side gigs, use whatever you want.
" If you wanna keep doing your startup bullshit and side gigs, use whatever you want"
If you're saying you wouldn't write your startup in Go, aren't you agreeing with the main point of the video?@@Kats0unam1
"real backend language" is silly but I get what you're saying. There's no silver bullet and it's all tradeoffs. For a production grade application there are more things to consider, but for solo dev side projects, it's a much better experience writing everything in one language.
@Kats0unam1 ok son. Apparently you have never tried supabase. Good luck when your backend team makes a change and your api breaks because by definition you can't guarantee they are going to match. Have fun with that.
it's faster for me to finish in sveltkit so I went sveltekit
Unfortunately I don’t have time to study and stay proficient in 2 frontend frameworks, and money is currently in Next, so that’s where I am at the moment.
same with me.
bruh learning frontend is not that hard, a couple days you are ready to rock, learning ai is something challenging.
@@Indonesia_Emas_ sure, now go and center a div for me.
@@Indonesia_Emas_ couple of days to learn frontend? have you worked on a large codebase before? Implemented features no library exist to help?
If you can learn frontend + every popping frameworks + ui frameworks + libraries in just couple of days. Salute to you.
@@edgardevelops yes, the frontend logic are just same, just with different sintax
Any new video using open ai chatgpt project example ? Using sveltkit ?
Just built the example project today :)
@bmdavis419 cool 😎 you the top youtubers that I follow and like you're awesome man 👌
You can have streamed data in sveltekit as well.
True
But they are not ssr supported like nextjs
Auth with sveltekit still gets me to this day, was trying to implement the auth with supabase but the set up seem so complex
Its not actually complex, the docs just suck, just the video I just uploaded!
I found it's the other way around for me ahah
firebase already great and free and you can crate your own jwt token, you just need to practice more and gather more information.
How can one say that Svelte ecosystem is not great? I guess that's your biased "react devs". Svelte ecosystem is JavaScript ecosystem. You can use any library that is out there. On the other hand, to use libs in React you need some weird bindings (aka "the react way"), which have nothing to do with JS lib, docs often aren't there or are clanky at best, etc - eg Apache eCharts is a great example - amazing to work with in Sveltekit (even when doing the most complicated stuff well beyond the docs) and abysmal experience in React/Next world (to even run the simplest charts). And that's only one example, there are countless out there. With Svelte 5 it will be even better. React is just bloated mess at this point.
Yea this is a good point honestly, what I more mean when I say react has better ecosystem is that when a company makes an SDK for their thing, 9/10 they will have a special optimized one for react, but not for the other frameworks and you have to work around it which can be kinda annoying
I thought I was subscribed
Sorry, now I am 😊
In sveltekit the load function stop the routing until tge data fetching complete and if you are thinking about stream with promises. Then it won't be server rendered. Where in nextjs suspense data can be found in pageview html data.
Its a huge with for Nextjs
Await each data object seperately in your load return. Like return { await dataObjectA, await dataObjectB}. Then when they are brought into your page they will load individually, lazily
❤❤ great video 🎉
Speaking of more templates for Svelte, if anybody knows any templates for SvelteKit that uses Supabase Auth lemme know
I'll have a video on this pretty soon
@@bmdavis419 Awesome! Please be sure to include the repo as well 😅
Jack Harlow 😂
I can't deal with the lack of nice UI kits in Sveltekit anymore. I value my time in that matter... Writing react doesn't seem like a pain after seeing how many hours you need to spend to get a professional looking app with Svelte.
Though I prefer react as well but I saw that svelte has their own version of shadcn ui, skeleton or Melt
"I can't deal with the lack of nice UI kits" sounds like you build multiple sites a month which all of need a completly different UI
the big names are literally usable in svelte. and saying "value my time" just means ur too lazy to write your own styling. this will be an issue no matter the framework you choose
Second vote here for shad cn svelte. With either some copy and pasting or a few command lines you have a set of components that have really good defaults and if you want to you can customize them. Problem solved. React had its day in my opinion, but with tiny bundle sizes, soon to be really crazy accurate levels of reactivity in version 5 and just a hell of a lot less boilerplate for me it's not even worth considering react in 2024
what about qwikjs?
And yet another virtual dom
Qwik is not that appealing because of too many requests for user interaction, normally it is better to expend 3 seconds for the page to load and user interaction be instant than load the page instantly and user interaction takes 500ms
Astrojs with island architecture is the way if you want really good SEO scores
Nowadays people are focusing on HTMX to reduce web development complexity
Can you take a look hugo & svelte?, well explained ❤
Simplified illustration...
Very much so yes, there is way more nuance and complexity I obviously did not cover here, but this gets the high level point of the frameworks across
Yeb, indeed, the way of splitting the client side of server side in Sveltekit is pretty good, plus, if we can call it merging them in the "Form Actions" in a magical way, I think that's what makes Sveltekit more predictable when dealing with "Form Actions" !!!
nextjs suuuuucks. Just use svelte, solid, or hell even vanilla js.
I thought this dude was a Go dev…lmao wtf happened
Just here to let you all know how great Remix is. Have a good day.
remix is fire
it doesnt even have csrf out of the box
Laravel >> SvelteKit > Next.js
I used to develop using Laravel, but not going back. I really don't see what's better about it, it works even slower than node/bun based frameworks, worse type safety, the PHP itself is even worse than JS in terms of dx
We are in 2024 and you say Laravel?! 🤣🤣🤣
Here is an idea from someone who used to follow you and doesn't anymore, because I think your takes are questionable:
How about we dont use a fake type system like Typescript on the server and use a proper language (C#, Go, Java) on the backend and just use Typescript for what was intended to, aka, manipulate the DOM on the browser.
I have a medium side project that will go to prod maybe next month with Go, HTMX, Templ, Tailwind, PGX. The only js dependencies I have are arc to display some curved lines on openlayers, htmx, and tippyjs to display some tooltips on the map. I installed tailwind though the CLI which means I have 0 need for node_modules and package.json management. 0 js library dependencies and maintenance in 5 years when I want to add / bug fix my projects ? Count me in.
I'm not an expert, but SvelteKit has this nice thing were you are in a sense more "declarative" in your construction. You load all the data you need to build your page. Then you use the data to build your page. In your page you have a bunch of forms that allow the user to submit information that will potentially change the data on the server. Now the fun part is that you don't have to worry about updating all the potential parts on the page that will have to be updated with the new data - you just call to "invalidate" those fetch requests whose data may have been affected by the form submit.
You could write an API backend in Go and still use SvelteKit, but it seems the issue is that you end up writing stuff twice, types become more painful.
I've said before and I'll say again that I pretty much agree with this, its just that for MY use cases, fullstack TS is better. I am on a small team that has to move fast, I have a separate go in backend in prod rn, and it sucks to maintain. No one disagrees that Go is a faster/stronger language for the backend, its just that TS can get the job done. And it gets the job done way better then I think people give it credit for...
"you end up writing stuff twice, types become more painful" EXACTLY I WENT THROUGH THIS EXACT THING
@@bmdavis419
"you end up writing stuff twice, types become more painful"
yeah so.. what you mean is... you have to... type.. code ? Crazy concept.
You write typescript and you dont enjoy writing type for the backend schema. There is a solution for that, its called Javascript.
Ur opinion is irrelevant
Why are you watching the video then? Must be relevant to you.
based
I dont understand why people are so mean. You dont Show your face in Public as he does. You can have your own opinion but unless you dont speak in public you wont help anyone or change anything.
@bmdavis419 Keep on sharing your thoughts, always nice too see how others are looking at the current situation.
@@dave-7117 appreciate it man, honestly I don't really care if people are mean on the internet, it gives more engagement which helps the channel and I earnestly believe in what I'm saying/making and thats enough for me
Only sveltekit... forever!