“Javascript rules them all” idea has been a smart choice to handle both frontend and backend by a single language. server actions brings the same react conventions rather than nodejs or api routes paradigm and makes to adopt this approach easier. But I don’t know if it’s good or bad news for frontend devs since we all are becoming full stack devs gracefully like the old days (php+jquery). Nowadays having smaller teams is becoming a trend even for big companies after all.
It's not a smart choice, it would have been if the node ecosystem wasn't a mess and if there were better frameworks for it, a lot of people thus don't want to write their backend code in JavaScript and that's understandable. (Big) Companies would never use NextJS for the backend of a serious and not very small application.
@@heroe1486 The reason I think it’s smart is that you can make a website without php but you cannot make a website without javascript. Of course I refer to today’s standards and php can be replaced with any other language in this context. I’m also not a huge fan of node and don’t enjoy backend scripting that much. But apparently things are going to evolve around this approach.
Full stack is indeed a future. Businesses will not be paying specialists anymore, they will expect us to be able to deliver apps from UX to deployment. But that obviously has it''s cons. Knowing a little bit of everything means we will not be excelling in anything which can lead to overall lesser quality. Of course, talking about simple to medium projects. Big and complex projects with uber business logic will always require specialists and domain experts.
When tooling being upgrading year after year, frameworks, ai, etc. Frontend developers will convert to Fullstack developers, and Backend developers only be necessary in a microservice arquitcture or big apps, no need in small apps.
@@timebroua that's why backend developers will be not removed. Frontend developers will transition to fullstack and backend developers will be needed to be more expert. As backend developer, you really want to create the endpoints for a frontend developer? and then argue with him because comuncation problems?
InertiaJS also reloads components without needing to build an API, while also preserving state without a refresh, all from your backend router from ROR or Laravel. I don't like having server and client code in the same file, but that's just me.
Using server actions defined somewhere in client components even with having to use useTransition is still really cool and probably going to be my most used feature.
I’m thinking that NextJS is turning into Ruby on Rails, which most people didn’t like because of how “magicky” it felt. In the other hand, if you understood how it works, then using RoR offered a big advantage.
@@marusdod3685 i meant the code's scalability (i think the better word would be maintainability). i can't imagine writing so much non relevant code to achieve something simple. at least that's where ror shines...
after seeing Remix, literally every framework after it implemented server action. and its good, the frameworks are better because of this feature. for anyone wondering about leaked credentials, just remember, if you are using it in a server component, then a leak is impossible since the code will never run on the client and the env will be undefined in the browser anyway if it is not prefixed with NEXT_PUBLIC_. If you are using server actions in a client component, then it may be a potential leak. But remember that server actions only run on the server + the envs will not be available if not prefixed with NEXT_PUBLIC_. And server actions are currently in alpha so their security will be improved in the future.
In practice "move your app to a different backend" will almost certainly involve a lot more than simply changing a url. Many frontends are typically strongly coupled to a particular backend and vice versa with the backend only existing for that frontend, and the argument is that in many cases having additional abstraction around this coupling can make us less flexible rather than more. React has always been bullish on removing barriers between code and challenging theory about how we should divide things up, remember "separation of concerns not separation of technology" so this is par for the course for them. Of course if you feel you do need that abstraction and explicit separation you are still welcome to write APIs and separate client side UI. But if that UI is the only consumer of that API then this may be a decent way to create it that's clearer, less complex and more performant. What's more if you further down the line realise you need the API then the pathway to going from server side to API led is probably a lot smoother than it was.
Refetching everything is usually and actually a very good thing as you won't need to engineer complex situations. But, as far I understood in this situation, it will only refetch the specific component.
I don't know, part of me really liked having react apps be frontend, and the ability to have something entirely different as my backend. I know i'm not being forced into this, but I kind of like the systems that we have now more than this. Will need to play with it more.
You can do that without reloading via Laravel + livewire, Phoenix + Liveview, Rails + Stimulus, Django + Reactor and so on. As always they're reinventing features that existed for a while elsewhere and making it like it's a new thing. We're a ton to use React/Next because of its simplicity and because we actually want separation of concerns.
@@YuriG03042 It's in response to the Abramov's "With PHP you have to reload" And welll yes that's what they're trying to convey, just look at their Apple like conferences and overall marketing for things that have been here in other frameworks/PAAS for years, same for the "it's going to reshape the industry" kind of reactions from the public.
@@Gogonel290 All of that without needing to couple your backend code with your frontend one and not being forced to use Node, React Query makes everything very easy. And as a bonus it also works with Vue Svelte and Solid
NextJs server actions looks like aspnet postback update panels from 2000. Seems to work the same way. It even posted back via ajax and didn't do a full page refresh. What is new is old.
Could you please describe more about database usage in actions? Because it is a more tricky thing, when you need to open a connection, then close it, or even open one connection over all actions ?:) I use surrealdb + server actions, and there are some interesting things with open and close connection :)
Reloading the page or not, both PHP and Next.js server actions tend to mix frontend and backend stuff into spagethi code. That's why we used MVC for so long, separation of concerns.
Impossible, that's not the same audience, most or their users are beginners or small companies that benefit from it for pennies before scaling a bit (and realizing the pricing isn't worth). But yeah the hype isn't deserved, it's overpriced (40x the price of a VPS or CDN for bandwidth) because most people can't figure out docker, how to use a CDN and GitHub actions and think they're doing crazy stuff that no one can reproduce.
@@heroe1486 I mean, every 3rd party service operates like that. It abstracts all of this stuff to be few clicks as possible so it's convenient. You are paying for the convenience, that's mostly it.
@@heroe1486 on your point about the vps and cdn being cheaper, if I'm making a portfolio site or just want something quick and usable, I don't wanna go through all those steps. for a production project, yes it makes sense to have more fine tuned control in order to solve those issues but for a personal/hobby project not worth the extra hassle (which leads to effort invested that may demotivate me from finishing the project in the first place). Theres still even an argument that that overhead is worth it: sure you'll save money on deployment but you instead pay more on labor/knowledge cost.
I'll be honest, when I first heard about all this I couldn't help but think how overcomplicated React was getting, but this video reversed my thinking.
@@gaborkrisko They are not served from cache, because there's a different ?v=123123 on each of them, each time they load. But maybe it's due to the development/local server and how it ensures that files are always fresh?
yeah, next13 is entirely "inspired" by remix - and likewise the new routing system in remix v2 is inspired by nextjs13 - its a win win for all frameworks.
So this is better than it was? Still looks like a lot of code and things to keep in mind for such simple thing to do. It would be 5 lines of code in Sveltekit
Someone correct me if I'm wrong, but I think the benefit of mutating directly on the component isn't that great considering that in any organized app we would have to write the logic in separate files, like we already do with Next's APIs. As for optimistic updates, the useSWR hook, which is also maintained by Vercel, is a very simple and effective tool to handle the rendering of API requests
Ill say this. As a maintainer of an OSS library using SWR, server actions completely decimated its use case in web. For RN, and non next apps SWR is still useful, but in next 13 it’s completely useless. I almost discourage using SWR in next 13 app dir.
I'm not sure I like the idea of mixing server and frontend code together. Writing server-related code in API routes and serverless functions is more convenient, IMO. I really hope they won't deprecate "pages-components-api" way of writing applications in the future
Something about mixing server side code and client side code, in the same language in the same file, is giving me a lot of anxiety. I expect server secrets to be leaking a lot if this becomes popular.
@@agungokill php didn't use the same language for server and client, so it had better separation, if only marginally. But here since it's all JavaScript, simply forgetting to write "use server" feels like enough to leak something.
@@MrMudbill that's the point, if php do it better why need something like similar to php again to some extent. just improve php to able to passing component tho
everything looks great, but one thing has me thinking, how are we thinking about authentication? Like checking auth status in server actions, using cookies or tokens, login and register. I know you can say just use next-auth but that would increase too much dependence on a third party library.
Seem promising but for now its painful to await a server action with revalidatePath then `router.back()` (to the list screen) to close a parallel routes modal.
Every day I am more and more inclined to switch to embedded programing, or any other field. Web Dev is going to become so easy and at the same time less demanded due to the fact that one dev will be able to do same amount of work that required 2-3 devs just few years ago. Every day you get some new service/framework that replaces something on the web. Sooner or later we gonna get great AI powered web builders too and then my grandpa will be able to create a website in a day and connect it to 54 Vercel services with authentication, storage, cache, database etc... The industry obviously decided to automate out web development.
Can you please make a short video on how to upload the image using this server actions from client component to server component to get that image URL.. Please make video I am very struggling with it.
Is “API first” principle obsolete nowadays? How can Server Components allow other clients to use the same backend? That was the whole point of SPAs, mobile clients communicating only over REST/GraphQL so that you can add more clients/automation/consumers later
I laughed so hard at "a classic React feature, huge productivity boost with plenty of ways to shoot yourself". I love React, I have React brain, but having read so much code from my co-workers where they shoot themselves, I've come to accept React has some major shortcomings.
indeed, came here to say the same. since actions and loaders are making their way onto router soon, all react based approaches will have these features. vercel always seems to be all about that onboarding. next they'll depart their hierarchal routes in favor for 'their own' divisive flat routing
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
If you like this style of content, check out the full course for more. Use NEXT30 to get 30% off (expires this sunday) fireship.io/courses/nextjs
Purchased! Can't wait to get started.
Is this nextjs course with latest updates? Like next13
like the miniature of the video
Take my money 💸
Any chance Nuxt3 course happens? And/or sveltekit. Good stuff though.
Like how you specifically chosen dogs for this tutorial so you could have upDog as a function. Well played
What’s updog
@@invinciblemode not much, sup?
“Javascript rules them all” idea has been a smart choice to handle both frontend and backend by a single language. server actions brings the same react conventions rather than nodejs or api routes paradigm and makes to adopt this approach easier. But I don’t know if it’s good or bad news for frontend devs since we all are becoming full stack devs gracefully like the old days (php+jquery). Nowadays having smaller teams is becoming a trend even for big companies after all.
It's not a smart choice, it would have been if the node ecosystem wasn't a mess and if there were better frameworks for it, a lot of people thus don't want to write their backend code in JavaScript and that's understandable.
(Big) Companies would never use NextJS for the backend of a serious and not very small application.
@@heroe1486 The reason I think it’s smart is that you can make a website without php but you cannot make a website without javascript. Of course I refer to today’s standards and php can be replaced with any other language in this context. I’m also not a huge fan of node and don’t enjoy backend scripting that much. But apparently things are going to evolve around this approach.
Full stack is indeed a future. Businesses will not be paying specialists anymore, they will expect us to be able to deliver apps from UX to deployment. But that obviously has it''s cons. Knowing a little bit of everything means we will not be excelling in anything which can lead to overall lesser quality. Of course, talking about simple to medium projects. Big and complex projects with uber business logic will always require specialists and domain experts.
When tooling being upgrading year after year, frameworks, ai, etc. Frontend developers will convert to Fullstack developers, and Backend developers only be necessary in a microservice arquitcture or big apps, no need in small apps.
@@timebroua that's why backend developers will be not removed. Frontend developers will transition to fullstack and backend developers will be needed to be more expert. As backend developer, you really want to create the endpoints for a frontend developer? and then argue with him because comuncation problems?
InertiaJS also reloads components without needing to build an API, while also preserving state without a refresh, all from your backend router from ROR or Laravel. I don't like having server and client code in the same file, but that's just me.
I would love to see a video with frameworks and languages portrait as tribes and nations that fight over the Web like it was an history class
Definitely the best next.js tutorial on youtube, touching everything worthy fastly
Using server actions defined somewhere in client components even with having to use useTransition is still really cool and probably going to be my most used feature.
same
when using a server action in a client component, does the action still happen on the server side?
yes@@alulaleak
@@alulaleak yes
Awesome! Best programming channel on TH-cam. This is the perfect level of information to jump into the docs without getting in over your head 👍
I’m thinking that NextJS is turning into Ruby on Rails, which most people didn’t like because of how “magicky” it felt. In the other hand, if you understood how it works, then using RoR offered a big advantage.
agreed
I think next is unnecessarily more complex in terms of syntax. Doesnt seem that scalable now... Ror on the other hand is easy to understand...
I see now why most of the elder devs that were really successful were RoR devs (in my region at least)
@@_sevelin you're talking about scalability, almost all companies that used ruby on rails migrated away from it because it was dogshit slow
@@marusdod3685 i meant the code's scalability (i think the better word would be maintainability). i can't imagine writing so much non relevant code to achieve something simple. at least that's where ror shines...
Fantastic content. Information rich with no filler but seasoned with a little levity and entertainment. Perfect.
after seeing Remix, literally every framework after it implemented server action.
and its good, the frameworks are better because of this feature.
for anyone wondering about leaked credentials, just remember, if you are using it in a server component, then a leak is impossible since the code will never run on the client and the env will be undefined in the browser anyway if it is not prefixed with NEXT_PUBLIC_.
If you are using server actions in a client component, then it may be a potential leak. But remember that server actions only run on the server + the envs will not be available if not prefixed with NEXT_PUBLIC_. And server actions are currently in alpha so their security will be improved in the future.
Do you know what’s great about api endpoints? Freedom to move your app to a different backend
exactly
In practice "move your app to a different backend" will almost certainly involve a lot more than simply changing a url. Many frontends are typically strongly coupled to a particular backend and vice versa with the backend only existing for that frontend, and the argument is that in many cases having additional abstraction around this coupling can make us less flexible rather than more.
React has always been bullish on removing barriers between code and challenging theory about how we should divide things up, remember "separation of concerns not separation of technology" so this is par for the course for them. Of course if you feel you do need that abstraction and explicit separation you are still welcome to write APIs and separate client side UI. But if that UI is the only consumer of that API then this may be a decent way to create it that's clearer, less complex and more performant. What's more if you further down the line realise you need the API then the pathway to going from server side to API led is probably a lot smoother than it was.
How often do you do that though? I'd say for most indie projects that's not a big concern
It's Laravel without reload
but you will never, it will never happen :)
Server Actions are the feature I literally needed the most right now, I had two github-discussions running which where closed now because of this.
Yep, revalidate all page resources after every form submission. This is a revolution!
P.S Already a year in remix and svelte 🤪
React router dom v6 has it too?
@@ianbdb7686 it's not new and in react. Got a long time in remix
Refetching everything is usually and actually a very good thing as you won't need to engineer complex situations. But, as far I understood in this situation, it will only refetch the specific component.
I don't know, part of me really liked having react apps be frontend, and the ability to have something entirely different as my backend. I know i'm not being forced into this, but I kind of like the systems that we have now more than this. Will need to play with it more.
Its similar to developing in Ruby On Rails framework.
@@kodekorp2064 How is it similar to RoR framework for people not familiar with it?
You can do that without reloading via Laravel + livewire, Phoenix + Liveview, Rails + Stimulus, Django + Reactor and so on.
As always they're reinventing features that existed for a while elsewhere and making it like it's a new thing.
We're a ton to use React/Next because of its simplicity and because we actually want separation of concerns.
it's a new thing in React, which is what Next is meant for. you are acting like they claimed to build a new base on the moon or something
Stop trying to sell us your shitty boomer frameworks
@@YuriG03042 It's in response to the Abramov's "With PHP you have to reload"
And welll yes that's what they're trying to convey, just look at their Apple like conferences and overall marketing for things that have been here in other frameworks/PAAS for years, same for the "it's going to reshape the industry" kind of reactions from the public.
Also same stuff exists in SvelteKit for quite a while
@@buldezir And apparently in Remix too
The AI Audio is pretty good in this one.
Dam I didn’t even realise this was AI generated voice?
@@yellowboat8773 yeah it’s especially funny during the jokes because AI can’t get the cadence quite right.
for non-native english speakers, it's far too fast
This is going completely over my head lol, probably because i dont have a concept of how this was done originally.
+1
Remember we were all using Next because "it's just React but with extra goodness (file based routing, handy utility functions, middleware etc)"
I feel like using react query its more easier, readable and intuitive, and can be used outside of html forms
@@Gogonel290 All of that without needing to couple your backend code with your frontend one and not being forced to use Node, React Query makes everything very easy. And as a bonus it also works with Vue Svelte and Solid
Same
Fact : I learned everything I need from this vid
loved the timing with the like button glow up!
I knew it was coming, I was prepared for the punchline, it still got me. Every. time. Curse you upDog!
thank you, I finally started to understand developing technics thanks to your videos
Damn. First time I’m seriously considering the pro membership.
NextJs server actions looks like aspnet postback update panels from 2000. Seems to work the same way. It even posted back via ajax and didn't do a full page refresh. What is new is old.
Yeah and it worked like a charm...no page reload!
Love your humour dude, thanks for the content! 😊
Thanks. best tutorial video ever seen.
Amazing video. Thank you ! So excited about those updates 🔥
Very clear you explanation, you're awesome bro
Could you please describe more about database usage in actions?
Because it is a more tricky thing, when you need to open a connection, then close it, or even open one connection over all actions ?:)
I use surrealdb + server actions, and there are some interesting things with open and close connection :)
Another great video that makes me to want to quit web development 🙂👍
Awesome explanation, thank you
Reloading the page or not, both PHP and Next.js server actions tend to mix frontend and backend stuff into spagethi code. That's why we used MVC for so long, separation of concerns.
Yep
This update is so crazy good🙌🏻
Great video! Loves your coding tutorials!
I like SvelteKit approach more: it's quite similar but you still maintaining separation of execution concern (BE/FE).
Mark my words, Vercel will become the new, bloated, unpayable AWS in 5 years time. Keep hyping it, everyone...
Impossible, that's not the same audience, most or their users are beginners or small companies that benefit from it for pennies before scaling a bit (and realizing the pricing isn't worth).
But yeah the hype isn't deserved, it's overpriced (40x the price of a VPS or CDN for bandwidth) because most people can't figure out docker, how to use a CDN and GitHub actions and think they're doing crazy stuff that no one can reproduce.
Their pricing is obnoxious.
@@heroe1486 I mean, every 3rd party service operates like that. It abstracts all of this stuff to be few clicks as possible so it's convenient. You are paying for the convenience, that's mostly it.
@@heroe1486 on your point about the vps and cdn being cheaper, if I'm making a portfolio site or just want something quick and usable, I don't wanna go through all those steps. for a production project, yes it makes sense to have more fine tuned control in order to solve those issues but for a personal/hobby project not worth the extra hassle (which leads to effort invested that may demotivate me from finishing the project in the first place).
Theres still even an argument that that overhead is worth it: sure you'll save money on deployment but you instead pay more on labor/knowledge cost.
That whats up dog killed me
You're a machine! Enjoyed the video.
I'll be honest, when I first heard about all this I couldn't help but think how overcomplicated React was getting, but this video reversed my thinking.
2:06 Interesting. I usually put the server-side data into a state so I can update it immediately from the response I get back from the server
Geez this stuff is cool!
I was just wondering about the three CSS http calls, are they necessary?
Was wondering just the same, especially if they are identical, which I suppose they are.
@@amatzen in that case the are probably served from the browser cache
@@gaborkrisko They are not served from cache, because there's a different ?v=123123 on each of them, each time they load. But maybe it's due to the development/local server and how it ensures that files are always fresh?
Just the Dev server, wouldn't happen in prod
Nice one. Loved it
Did you not apply any custom font here because it causes jitter in the UI when you revalidate the page?
Serious question, how are you so productive? How big is your team? Very impressed by your publication rate/quality
Oh look! Something SvelteKit already has!
Nah it's actually a cool feature and I'm happy it comes to more frameworks! :)
Look what they have to do to mimic a small portion of our power
The opimistic update feature is cool but it requires JS again, whereas normal form actions can execute without JS
Great video as always! but Isnt Remix doing this or somthing simular with loaders and actions?
yeah, next13 is entirely "inspired" by remix - and likewise the new routing system in remix v2 is inspired by nextjs13 - its a win win for all frameworks.
Okay, Remix has to step up their game
fantastic content
So this is better than it was? Still looks like a lot of code and things to keep in mind for such simple thing to do. It would be 5 lines of code in Sveltekit
Server, server... The client side first was also useful
it's not 2017 anymore
@@axelramirezludewig306 yeah it's 2001
Someone correct me if I'm wrong, but I think the benefit of mutating directly on the component isn't that great considering that in any organized app we would have to write the logic in separate files, like we already do with Next's APIs. As for optimistic updates, the useSWR hook, which is also maintained by Vercel, is a very simple and effective tool to handle the rendering of API requests
Ill say this. As a maintainer of an OSS library using SWR, server actions completely decimated its use case in web.
For RN, and non next apps SWR is still useful, but in next 13 it’s completely useless. I almost discourage using SWR in next 13 app dir.
server actions can be defined inside components, imported from other files or passed as props.
This is not the same DX as using SWR or react-query.
This was great, tnx!
I love php working style happy to see nextJS mixing it with javascript.
next js moving up in the directory!
Yup, that's like Livewire in Laravel
Very like the old way PHP
Fullstack for the win
Thanks dad!
i fucking love you Jeff Delaney
I'm not sure I like the idea of mixing server and frontend code together. Writing server-related code in API routes and serverless functions is more convenient, IMO. I really hope they won't deprecate "pages-components-api" way of writing applications in the future
It seems extremely unlikely that they'd ever actively prevent you from doing it that way.
Something about mixing server side code and client side code, in the same language in the same file, is giving me a lot of anxiety. I expect server secrets to be leaking a lot if this becomes popular.
they already did lol, i saw a tweet of people accessing server side env variable in client console
php already did long time ago lmao
@@agungokill php didn't use the same language for server and client, so it had better separation, if only marginally. But here since it's all JavaScript, simply forgetting to write "use server" feels like enough to leak something.
@@MrMudbill that's the point, if php do it better why need something like similar to php again to some extent. just improve php to able to passing component tho
@@agungokill I don't think I understand what you're suggesting
She is amazing ❤
This is really awesome 😲😍🤩😌😘
All of this is for s simple form handling :) hahaha nice one keep it up
everything looks great, but one thing has me thinking, how are we thinking about authentication? Like checking auth status in server actions, using cookies or tokens, login and register. I know you can say just use next-auth but that would increase too much dependence on a third party library.
that's what we call vendor locking
Middleware
You can use pretty much any authentication package you want? All you are doing is either decoding a JWT or doing a session cookie lookup.
historical lessons of software engineering thrown out of the window as long as "IT DOESN"T RELOAD THE PAGE BRO"
awesome. thaks
Seem promising but for now its painful to await a server action with revalidatePath then `router.back()` (to the list screen) to close a parallel routes modal.
Ready to modify all backend code until the next update
nice, i didn't know what all the hype was about, cheers for clarifying with the video
PHP is waving
Every day I am more and more inclined to switch to embedded programing, or any other field. Web Dev is going to become so easy and at the same time less demanded due to the fact that one dev will be able to do same amount of work that required 2-3 devs just few years ago. Every day you get some new service/framework that replaces something on the web. Sooner or later we gonna get great AI powered web builders too and then my grandpa will be able to create a website in a day and connect it to 54 Vercel services with authentication, storage, cache, database etc... The industry obviously decided to automate out web development.
You're forgetting one thing: the pricing of Vercel services. It's just not feasible when scaling up to millions of users.
@@someonewhowantedtobeahero3206 yeah, every "magic" turn to shitshow when scale and costs come into play
I'm a Vue Fanboy that wants Server Actions in Nuxt!
Can you please make a short video on how to upload the image using this server actions from client component to server component to get that image URL..
Please make video I am very struggling with it.
i knew that updog joke was happening 😂
The course is 20 bucks! 20! I thought it would be like 300. Fucking hell I am getting two, just for the sake of it!
Guys it is 20 bucks!
Will the React course ever become a single purchase?
You must really love Bruce Lee!!
haiyya don't use vercel kv, use normal sql mysql or postgres and prisma
don't want vendor lock tho
Should be trivial to replace the function calls once you want to move to a different database
Vercel's keynotes creep me out. It's like they're trying to be the Hooli of Javascript frameworks.
I would feel so filthy if I spent a day authoring code that winds up looking like this stuff
Do you know what is good about api endpoints?
Creating mobile apps that uses the same backend.
you can use this with the src directory right?
Nice
thanks 🔥🚢
i thought i knew some react and next but now i am mind fucked
Will it replace react-hook-forms?
I am starting with Next... why using frontend server actions to update database instead a dedicated backend? What is the benefit?
🎉🎉
I would like to see how frontend devs will deal with high-load, scaling and security 😅
Is “API first” principle obsolete nowadays? How can Server Components allow other clients to use the same backend? That was the whole point of SPAs, mobile clients communicating only over REST/GraphQL so that you can add more clients/automation/consumers later
I think same as you, but looks like people don’t care and are just hyped
So more like Elixir Phoenix Liveview but alómala there 😎
Isn't that the same thing sveltekit does for svelte?
Is there a way to set the default playback speed to .5 for this channel only?
yes, but why?!
Yesterday, I finished reading the f**king docs for the pages directory
I laughed so hard at "a classic React feature, huge productivity boost with plenty of ways to shoot yourself".
I love React, I have React brain, but having read so much code from my co-workers where they shoot themselves, I've come to accept React has some major shortcomings.
Remix run is better than next js. Things are much simpler and cleaner way. Nobody is talking about remix these days.
Bruh I agree with you. Remix is much more simpler, next just overcomplicates things.
@@chuksben8175 exactly even Next js is slower than Remix.
indeed, came here to say the same. since actions and loaders are making their way onto router soon, all react based approaches will have these features. vercel always seems to be all about that onboarding. next they'll depart their hierarchal routes in favor for 'their own' divisive flat routing
Updog? What's up dog?