I agree with what tanner said. The directive that nextjs went for is too magical. How do we pass headers? How do we alter how its sent? I didnt think it would be useful due to my bias towards vercel but it is deffo useful
'use client' is bad enough, why would I want to control caching through a string? I can only imagine the headaches that will come from self hosting where Next overwrites cache headers...this is the same issue that makes Laravel annoying
Nice content !!!!! What about the state of request ? I mean we can use suspense to show loading, we can handle error and show some user feedback's, in this case we dont need more trpc ? More performant ?
Honestly, these days all I like to build with is Tanstack Router in a mono repo with Hono RPC + OpenAPI Typegen. Serve my client on a CDN for free, run my Hono API on a machine. Life is just easier this side of the fence.
Hi Abdul. I'm curious how do you set this up. Do you mind if you shared any repo for us to look at? It really interest me to jump out of this. Thank you.
tanstack start is such a fresh start and such a logical and intuitive way to add server layer on top of the already amazing router. next is shovelling their way too hard, the way that most of us do not want to be the default, plus next router is crap compared to tanstack
A nice change to the TS router/start example would have been to follow the Remix pattern where to fn is called through something like useFetcher and the server fn returns the updated value of the count. Avoids doing another request for the loader
That's just generally good advice. Not so much the getting fired part. But the "use what the rest of the company is using" advice is pretty good unless you have an extremely compelling business based case not to.
I think I've read on twitter that single request mutation + invalidation will come to Tanstack Start, so in your example there wouldn't be a separate request to re-fetch the loader data. It would all happen in a single request like it happens in Next.js All in all, Tanstack Start seems very promising.
@@rand0mtv660 I wouldn't doubt it. I think the intention is to have all of the functionality of NextJS covered and then some. But currently Start doesn't work with 19. Which means that RSCs are currently not supported. So returning an RSC update payload, which is what Next does in this case, would at least right now, not be possible. Which leaves returning new loader content, but that would need to be an interesting hybrid (maybe multipart encoded) payload since you've got the return of the server function itself as well as the loader content coming back. And then there is also the issue of whether or not you are using RSCs when they do become available. Next has the advantage in that case that we don't have a choice, you have to use RSCs, so you can architecturally depend on them. That wouldn't hold true for Start if he supports both RSC and non-RSC cases. Woof, this stuff is getting complex.
@@jherr Don't complicate it that much. We have always been able to return json from an api endpoint. The main difference with server functions is that they now have transferrable context on top of the payload/result going/coming across the wire. So it should be trivial without 19 or server components to allow middleware to send/receive additional data (like single-flight mutation payloads/streams) on top of what appears on the surface as a simple server function that mutates or fetches some data.
Just learn React and then NextJS. Everyone used to say React will die when Vue was released, yet it's the most popular technology to build apps. Just ignore these shiny stuff and learn what companies use. NextJS is used by a lot of companies. Web dev is just frustrating.
This is looking nice. I really prefer Astro as my main "base" as I can have islands that are not React. React is ok, but it always bothers me the various anti-patterns and, in a large way, lack of innovation compared to Solid, Svelte, etc. SSR is great for Vercel in revenue. They sell servers after all. But I am way more into hybrid or SSG approaches when available.
Funny how Next.JS is still not 100% type safe... and one man solved what hundreds of engineers couldn't. :D Whenever I see stringly based APIs I feel a sense of repulsion. :P
Tanstack start is a copy of Remix. But it's nice, I like this approach really. Just hope people will remind that this server approach should be useful, not to just please frontend developers. Full backend API and full front is still the best stack.
Sure, some similarities, but every framework will inevitably have similarities on good ideas. I happily used Remix for 2 years because I liked *some* of it a lot. But so much is entirely different both in API design and definitely implementation. TanStack Router and Start were architected and written from the ground up to allow for things that the Remix/RR team were unwilling to collaborate on, including much needed features and design upgrades from the community, some of those coming from me (type-safety, state-management, caching, etc).
between nextjs, remix, and tanstack start, the only reason i use any of this shit is because i can start the server and the client with a single command for my local project apps. I wont ever use ssr until the day aws supports it as natively and cheaply as they do serverless. Until then, most of these changes from react and the rest have just been useless to me as im only doing spa for real apps.
Oh, this thing again? I honestly could not give less f*** than I already did with these things. For me, anything that works, I'll take it. Just let me know what the tradeoffs are, so that I can measure them.
@@youarethecssformyhtml Agree. Just use whatever the heck that works for you. Nothing else actually matters. Corporations argue over these things all the times. No wonder their job postings look like they just smoke 10,000 kilograms of weed
const count = await getCount() -- that appears much cleaner compared to separate loader(). It pretty much vanilla js, very easy to understand, and does not require to learn a specific API. Same can be told about `export async function serverFunc()` compared to createSserverFN()
I see Tanstack, I press like
Man of culture
tanner is a genius 🤯, tanstack-start is awesome, when it hit stable v1 many devs will move to using it instead of next.js.
Indeed, I am starting to look at it now. Thanks Jack!
I am waiting for stable release as well. Been using NextJS for a while and honestly it's getting more of a hassle to do things in it.
@@Hypawolf the feel i am feeling when switch from react-router to tanstack-router, life is soooo much much easier
isnt this exactly what people say when a new js framework is launched, I remember people said the same thing about remix svelte qwik etc
@@KaranSethia24Everything gets bloated over time. Next.js started out lean and fast, then obesity roared its ugly head.
Returning WebStream from Server Functions -- definitely a great feature!
Can’t wait to use it. Hopefully beta and v0 will come soon enough. Great video, as usual ❤
I agree with what tanner said. The directive that nextjs went for is too magical. How do we pass headers? How do we alter how its sent? I didnt think it would be useful due to my bias towards vercel but it is deffo useful
'use client' is bad enough, why would I want to control caching through a string? I can only imagine the headaches that will come from self hosting where Next overwrites cache headers...this is the same issue that makes Laravel annoying
@@PraiseYeezus more trouble for opennext people
@@PraiseYeezus "use tanstackstart" is the best directive
super helpful video for understanding our options in 2025! Thanks for a great video!
Nice content !!!!! What about the state of request ? I mean we can use suspense to show loading, we can handle error and show some user feedback's, in this case we dont need more trpc ? More performant ?
great content as always! 🔥
Honestly, these days all I like to build with is Tanstack Router in a mono repo with Hono RPC + OpenAPI Typegen.
Serve my client on a CDN for free, run my Hono API on a machine.
Life is just easier this side of the fence.
That's a good SPA setup.
Hi Abdul. I'm curious how do you set this up. Do you mind if you shared any repo for us to look at? It really interest me to jump out of this. Thank you.
Check out ts-rest, its what all these wannabe RPC-like things wannabe. And yes I've used Hono RPC too.
Only god knows, how and where the "use cache" stores the cached values? Is it in memory or is it http caching or what ?
The standard adapter is in memory. But you can override the adapter to put it wherever you want. You just need to implement get/set.
@jherr Thanks a lot, I was searching through the docs but didn't find it.
tanstack start is such a fresh start and such a logical and intuitive way to add server layer on top of the already amazing router. next is shovelling their way too hard, the way that most of us do not want to be the default, plus next router is crap compared to tanstack
I cant stress enough how much I hate how Nextjs server actions works
Does it make any sense to use GraphQL with Tanstack Start? Are there any examples?
Great video 👍
A nice change to the TS router/start example would have been to follow the Remix pattern where to fn is called through something like useFetcher and the server fn returns the updated value of the count. Avoids doing another request for the loader
This is coming and will be built on the new server function middleware/context primitives we just merged in.
@@tannerlinsley cant we just call server get function at the end and modify the state to get the latest data instead of going for router.invalidate
I will use whatever my organization using whether tanstack or next😂
If you don't you're fired
That's just generally good advice. Not so much the getting fired part. But the "use what the rest of the company is using" advice is pretty good unless you have an extremely compelling business based case not to.
I think I've read on twitter that single request mutation + invalidation will come to Tanstack Start, so in your example there wouldn't be a separate request to re-fetch the loader data. It would all happen in a single request like it happens in Next.js
All in all, Tanstack Start seems very promising.
That'll be interesting to see.
@jherr hopefully I didn't just read something wrong, but it popped up briefly on my Twitter feed.
@@rand0mtv660 I wouldn't doubt it. I think the intention is to have all of the functionality of NextJS covered and then some. But currently Start doesn't work with 19. Which means that RSCs are currently not supported. So returning an RSC update payload, which is what Next does in this case, would at least right now, not be possible. Which leaves returning new loader content, but that would need to be an interesting hybrid (maybe multipart encoded) payload since you've got the return of the server function itself as well as the loader content coming back.
And then there is also the issue of whether or not you are using RSCs when they do become available. Next has the advantage in that case that we don't have a choice, you have to use RSCs, so you can architecturally depend on them. That wouldn't hold true for Start if he supports both RSC and non-RSC cases.
Woof, this stuff is getting complex.
@@jherr Don't complicate it that much. We have always been able to return json from an api endpoint. The main difference with server functions is that they now have transferrable context on top of the payload/result going/coming across the wire. So it should be trivial without 19 or server components to allow middleware to send/receive additional data (like single-flight mutation payloads/streams) on top of what appears on the surface as a simple server function that mutates or fetches some data.
what is your vscode color theme?
Night wolf
Hey Jack, punted you a mail re: audio sync. Hopefully it reaches you.
Thanks again for another great video.
Hi Jack, which font do you use for VS Code?
That's Cursor not VS Code
JetBrains Mono. Specifics are in the description.
I am so confused with all the updates I a newbie in react where should I start please anyone answer me
Just learn React and then NextJS. Everyone used to say React will die when Vue was released, yet it's the most popular technology to build apps. Just ignore these shiny stuff and learn what companies use. NextJS is used by a lot of companies. Web dev is just frustrating.
@youarethecssformyhtml learn from where bro I don't even know react tbh
@@abhi.r8 you can learn from their official website (just google it)
You can learn it from the official website
I'm a fan of tanstack 🎉🎉🎉🎉
What happened to this framework when Tanner cannot keep working on it for any reason?!
A community forms while he's still active. Tanner hasn't been the top contributor to TanStack Query for a while now.
Can't way to move on from Next.js!!!
Wait, Next doesn't support streaming in server functions???
Tanstack is the manstack
This is looking nice. I really prefer Astro as my main "base" as I can have islands that are not React. React is ok, but it always bothers me the various anti-patterns and, in a large way, lack of innovation compared to Solid, Svelte, etc. SSR is great for Vercel in revenue. They sell servers after all. But I am way more into hybrid or SSG approaches when available.
Tanstack Start vs React Router + Vite?
I literally built this out of frustration with RR lol😅
@@tannerlinsley :D Thanks, I'm excited to fire it up.
@@tannerlinsleyayoo im waiting your router because frustation with RR 😂
Tanstack router is really powerful. I believe in Start!
Both of them are cool, I like both and use both of them :|
Funny how Next.JS is still not 100% type safe... and one man solved what hundreds of engineers couldn't. :D
Whenever I see stringly based APIs I feel a sense of repulsion. :P
At least Tanstack app makes it easier to debug .. NextJS is too ambiguous
Tanstack start is a copy of Remix. But it's nice, I like this approach really. Just hope people will remind that this server approach should be useful, not to just please frontend developers. Full backend API and full front is still the best stack.
Sure, some similarities, but every framework will inevitably have similarities on good ideas. I happily used Remix for 2 years because I liked *some* of it a lot. But so much is entirely different both in API design and definitely implementation. TanStack Router and Start were architected and written from the ground up to allow for things that the Remix/RR team were unwilling to collaborate on, including much needed features and design upgrades from the community, some of those coming from me (type-safety, state-management, caching, etc).
9:29 If it's just a GET, just co-locate that in as a fetch function with GET instead of making non-mutational things a server action?
Remix?
is now React Router + Vite
between nextjs, remix, and tanstack start, the only reason i use any of this shit is because i can start the server and the client with a single command for my local project apps. I wont ever use ssr until the day aws supports it as natively and cheaply as they do serverless. Until then, most of these changes from react and the rest have just been useless to me as im only doing spa for real apps.
I still prefer Remix over these two
Oh, this thing again?
I honestly could not give less f*** than I already did with these things.
For me, anything that works, I'll take it. Just let me know what the tradeoffs are, so that I can measure them.
Yeah I'm also sick of this field with this endless number of frameworks. I'll just use Next
@@youarethecssformyhtml
Agree. Just use whatever the heck that works for you. Nothing else actually matters.
Corporations argue over these things all the times. No wonder their job postings look like they just smoke 10,000 kilograms of weed
Who can please explain how it diff from just call rest api from FE?
What benefit from all these server actions if I don’t use SSR?
Rule of thumb: if you don't see any benefit, you probably don't need it.
At this point, I'm sick of this field (web dev). I'll just use Next and switch to another field after I get a job.
const count = await getCount() -- that appears much cleaner compared to separate loader(). It pretty much vanilla js, very easy to understand, and does not require to learn a specific API. Same can be told about `export async function serverFunc()` compared to createSserverFN()
But you wouldn’t/ shouldn’t fetch data with server actions? Hence always POST. Just have the call directly in the server component no ?
Directives are like decorators: one of the worst design patterns to ever exist!
boost
And here we are coding counter with making requests to the server
It's just an example.
Don't be hard on yourself 😂
Eww
Again a new lib/framework?? Pfff 🤢