Thanks for the huge shout out, it really means a lot to me 🙏 Just wanted to add that the Vite plugin was driven by Pedro Cattori just as much as me and it wouldn’t have happened without him 🍻
Am I the only one who no longer finds any of these front-end frameworks exciting? Am I fatigued out? I watched Theo's entire video and all I can hear is blah blah blah.. blah..
Me too. Honestly, this whole RSC stuff is weird. It's like the worst of all worlds. JS was meant to be a lightweight language that adds interactivity to the client. React took that paradigm and made it better and more streamlined. Now we're writing server code in JS for the frontend... that's also mixed up with the backend?
Server components never really clicked with me in the context of Next.js. I get the idea, I see the potential benefits. But with the Next.js implementation right now I don't feel like it's guiding towards a maintainable codebase. And the pages router in Next.js was also flawed. This concept is executed much better in Remix. So I'm really optimistic that the Remix folks will also find a great way of integrating server components. Yeah, I'm as hyped as you are!
I use Remix all day every day and it’s great as it is. If you need data in a component you can use a fetcher and use a resource route it’s untrue you are bound to only use route-level fetching..
@@mattiarasulo9934 Yes you can do so but whenver i do it feels like I'm being naughty. Like really remix wants me to route-level fetching for everything but it just humors me doing it with useFetcher/useSubmit
Good wrap-up video on Remix, however I believe the claim that loaders and actions are BAD DX is subjective. I have used both RSC in Next, and loaders and actions in Remix and actually love actions and loaders. In my (subjective) opinion, the DX is actually like Tailwind: You may have mixed feelings when you see it from a distance, but wouldn't do it any other way once you used it!
Could not agree more with this statement, was a big Next fan, initially thought I didn’t like the action loader pattern and now (just like Tailwind) I can’t stand working with anything else.
So... This route level data actually composes quiet well when working with nested layouts. It is an alternative solution to the problem mentioned of product detail component having it's own data.
The “lots of components that need data” pattern is the problem in react. People abstracting too many components. in a ton of react projects I see, I'd say that 90% of the non-primitive components are used in 1 route, yet they are in some “shared” component tree
This is kinda solved in React App Router by having localized components that live next to page.tsx. Still allows separation without throwing them into a shared tree.
@@adtc 100%. No different to having a bunch of “private” functions. And because they are in the same “scope”, with Remix/App Router, you can still use “loader data” in those components. The best of both worlds IMO
remix's "route level data fetching" works much better imo when combined with react query. the loader just contains some `ensureQueryData` and then the component has the normal query in it. best case is the same as "normal" remix but everything is normal again, worst case is a minor waterfall.
@@ccccjjjjeeee have you played around with using react query in combination with the new clientLoader/clientAction? What you have described is something I've been thinking could be a pretty solid pattern with those new APIs, but I haven't found time to test it out.
Server components were enough for me to start looking at other libraries and ultimately I've moved to Svelte(kit). Maybe I'll be proven wrong in time about server components but I think Remix & Sveltekit just have a better DX.
Sorry, but this is a question that really interests me. His mustache is brown,just like mine. But his hair is blond. Mine hair is brown. It is so stange. Is it genetics?
Data fetching with server component is deeply rooted to react, but I don't know about server action and revalidation part. Is it some next's crazy implementation??
No, it is not Next Magic, it is built on top of React APIs. You can import function called cache from React or you can import unstable_cache from Next.js (and that is tied to Next).
To me, “type safe CSS” means two things: 1) If your markup assumes a class name exists in a CSS file when attaching it to an HTML element, TypeScript validates that the class does indeed exist. 2) You’re using TypeScript as your preprocessor rather than a domain specific language like Sass. This means that TypeScript will complain if your CSS preprocessing logic has a type error even if you haven’t run the build yet.
⏱ CHAPTERS ⏱(by TimeSkip AI) 00:00:00 - Introduction to Remix Framework 00:01:48 - Understanding Server Components 00:02:59 - Challenges with Data Fetching in Remix 00:04:40 - Server-Side vs Client-Side Waterfalls 00:06:40 - Conclusion and Final Thoughts
Remix's DX is great - I've enjoyed building with it, but completely abandoned it because the community (leadership) set a really strange tone, and butt heads with other dev communtiies in unproductive ways. That's enough to make me shy away.
I have been using Remix, and it's great compared to nextjs. NextJs just keep releasing new features without thinking why and how. Just for the sake of fanboys to adopt. Remix is simple and easy to use.
@@jamesdenmark1396 While I think I can understand the gist of what you're saying, I'm a little sus any time someone starts throwing around "fanboys". It's not a productive conversation. Have something more substantive to say?
@@jamesdenmark1396 > NextJs just keep releasing new features without thinking why and how. You should try to read RFCs and join discussions if you think just release features "without thinking". Just as an example, The first RFC for React Server Components was published in December 2020 and was released in May 2023 as an experimental feature in React 18-that's 3 years of discussion, evaluation and implementation. Most of these conversations happened in the React repo and summits. Thanks to Next.js' adoption and ability to move things forward, the core maintainers, some of which work at Vercel, were able to push this forward much faster so that a wider audience so it can be improved for more general use cases.
I really need the RSC so i don't have to expose all the data to the frontend all the time. Since everything you return from loader is exposed to frontend, with the RSC only the component will be exposed, when do we expect this to be released?
But you still can't use rsc for all data fetching its just not possible in some cases when you want to use browser apis like window or need to use hooks
Good points, I want to use them to render stuff only. I think you still can attach events and such so when it runs on the client, the events works as expected.
@@jim..... that and also people are stuck with a decade old mindset. modern php and the laravel ecosystem is so much cleaner, faster, better than the modern js ecosystem.
Thanks for the huge shout out, it really means a lot to me 🙏
Just wanted to add that the Vite plugin was driven by Pedro Cattori just as much as me and it wouldn’t have happened without him 🍻
Am I the only one who no longer finds any of these front-end frameworks exciting? Am I fatigued out? I watched Theo's entire video and all I can hear is blah blah blah.. blah..
Me too. Honestly, this whole RSC stuff is weird. It's like the worst of all worlds. JS was meant to be a lightweight language that adds interactivity to the client. React took that paradigm and made it better and more streamlined. Now we're writing server code in JS for the frontend... that's also mixed up with the backend?
Skill issue
@@reanukeavesbecause it makes the dev experience way better
It’s because AI will need to control frontend and backend in the same project to streamline code generation.
That’s my take on it.
@@kkebo I bet the house you've not shipped a single project into production with a team.
Server components never really clicked with me in the context of Next.js. I get the idea, I see the potential benefits. But with the Next.js implementation right now I don't feel like it's guiding towards a maintainable codebase. And the pages router in Next.js was also flawed. This concept is executed much better in Remix. So I'm really optimistic that the Remix folks will also find a great way of integrating server components. Yeah, I'm as hyped as you are!
I use Remix all day every day and it’s great as it is. If you need data in a component you can use a fetcher and use a resource route it’s untrue you are bound to only use route-level fetching..
But you are doing a client side data fetching request right ?
I’m new to remix and want to see demos of this. Can you link to some examples?
@@manupadev No you can fetch the resource route from another loader as well!
@@mattiarasulo9934 Yes you can do so but whenver i do it feels like I'm being naughty. Like really remix wants me to route-level fetching for everything but it just humors me doing it with useFetcher/useSubmit
Remix DX over Next is like 10x more productivity without any shithole.
Ikr, it's a no brainer
It’s dumb to dismiss route loading so heavily. It works, and is clear + productive.
Theo is no longer my favourite vercel employee...?
Ikr, it almost like they are late on their monthly sponsor payment or something.
@@MrStupiuno 😂😂
I thought you were a simple advert Vercel shill. This is a breath of fresh air tbh.
Vite, single fetch, SPA mode, RSC, middleware, server context. Remix is getting loads of interesting improvements.
Good wrap-up video on Remix, however I believe the claim that loaders and actions are BAD DX is subjective. I have used both RSC in Next, and loaders and actions in Remix and actually love actions and loaders.
In my (subjective) opinion, the DX is actually like Tailwind: You may have mixed feelings when you see it from a distance, but wouldn't do it any other way once you used it!
Could not agree more with this statement, was a big Next fan, initially thought I didn’t like the action loader pattern and now (just like Tailwind) I can’t stand working with anything else.
And then "Everything fell apart". Last 15 years of js and Frontend development summed up in 3 words
its insane how things have "evolved"
i like DX more on Remix than Nextjs, also i like Remix embraces the good old web platform
So... This route level data actually composes quiet well when working with nested layouts. It is an alternative solution to the problem mentioned of product detail component having it's own data.
remix gang rise up
The “lots of components that need data” pattern is the problem in react. People abstracting too many components.
in a ton of react projects I see, I'd say that 90% of the non-primitive components are used in 1 route, yet they are in some “shared” component tree
Part of that is to optimize what rerenders
This is kinda solved in React App Router by having localized components that live next to page.tsx. Still allows separation without throwing them into a shared tree.
@@adtc 100%. No different to having a bunch of “private” functions. And because they are in the same “scope”, with Remix/App Router, you can still use “loader data” in those components.
The best of both worlds IMO
Since I use HTMX, server components are not much appealing to see.
It's just good to know I've been right.
Remix has a useMatches hook using which you can access data of any route in any component. So whats the problem with route level data fetching?
i love remix's router, and i'm excited to see how they fit rsc into it. theres still issues, but ive been getting somewhat remix pilled too lately.
remix's "route level data fetching" works much better imo when combined with react query. the loader just contains some `ensureQueryData` and then the component has the normal query in it. best case is the same as "normal" remix but everything is normal again, worst case is a minor waterfall.
@@ccccjjjjeeee have you played around with using react query in combination with the new clientLoader/clientAction? What you have described is something I've been thinking could be a pretty solid pattern with those new APIs, but I haven't found time to test it out.
6:30 Where's the video in the corner about "SSR and how all of this stuff works"
Remix needs to stay clean, more bloat != better product
Server components were enough for me to start looking at other libraries and ultimately I've moved to Svelte(kit). Maybe I'll be proven wrong in time about server components but I think Remix & Sveltekit just have a better DX.
wooooow!! finally I can hear about remix on this channel!! I have been really looking forward it! thanks!!
I'm so pumped that you're getting into remix.
RSC by default is pain
Sorry, but this is a question that really interests me. His mustache is brown,just like mine. But his hair is blond. Mine hair is brown. It is so stange. Is it genetics?
What about Modern.js? They are also working on RSC and Server Actions are being negotiated.
Will you make a video about it? :)
Really interesting video, I think we need more videos or specific video about waterfall data fecthing, is really an interessing topic :)
I really hope that the flickering in this video is a one-time thing. It is very distracting.
Thumbs up for the really clear explanation of server components, and the benefits. It hadn't really clicked for me before. Thanks!
awesome! i am still using vike + telefunc though, but good news for those using remix
5:40 Dai-shi just released Waku, which is exactly that.
Route level data fetching ? How is that different to ssr
Data fetching with server component is deeply rooted to react, but I don't know about server action and revalidation part. Is it some next's crazy implementation??
No, it is not Next Magic, it is built on top of React APIs. You can import function called cache from React or you can import unstable_cache from Next.js (and that is tied to Next).
what about waku?
This black curtain is dope 🤩🗿
shhhh ... don't tell anyone.
Can you do a tutorial on how to make fake Tweet thumbnails? 🙏
simply open up dev tools and change the text i guess
React relay kinda neat
it's no secret that...
This was a good video
what does" type safe css" even mean.
To me, “type safe CSS” means two things:
1) If your markup assumes a class name exists in a CSS file when attaching it to an HTML element, TypeScript validates that the class does indeed exist.
2) You’re using TypeScript as your preprocessor rather than a domain specific language like Sass. This means that TypeScript will complain if your CSS preprocessing logic has a type error even if you haven’t run the build yet.
❤ 💿
Long live Laravel.
I know right? Decade ahead of its time.
PHP better
⏱ CHAPTERS ⏱(by TimeSkip AI)
00:00:00 - Introduction to Remix Framework
00:01:48 - Understanding Server Components
00:02:59 - Challenges with Data Fetching in Remix
00:04:40 - Server-Side vs Client-Side Waterfalls
00:06:40 - Conclusion and Final Thoughts
Remix's DX is great - I've enjoyed building with it, but completely abandoned it because the community (leadership) set a really strange tone, and butt heads with other dev communtiies in unproductive ways. That's enough to make me shy away.
I have been using Remix, and it's great compared to nextjs. NextJs just keep releasing new features without thinking why and how. Just for the sake of fanboys to adopt. Remix is simple and easy to use.
@@jamesdenmark1396 While I think I can understand the gist of what you're saying, I'm a little sus any time someone starts throwing around "fanboys". It's not a productive conversation. Have something more substantive to say?
@@jamesdenmark1396 > NextJs just keep releasing new features without thinking why and how.
You should try to read RFCs and join discussions if you think just release features "without thinking".
Just as an example, The first RFC for React Server Components was published in December 2020 and was released in May 2023 as an experimental feature in React 18-that's 3 years of discussion, evaluation and implementation. Most of these conversations happened in the React repo and summits.
Thanks to Next.js' adoption and ability to move things forward, the core maintainers, some of which work at Vercel, were able to push this forward much faster so that a wider audience so it can be improved for more general use cases.
I really need the RSC so i don't have to expose all the data to the frontend all the time. Since everything you return from loader is exposed to frontend, with the RSC only the component will be exposed, when do we expect this to be released?
But you still can't use rsc for all data fetching its just not possible in some cases when you want to use browser apis like window or need to use hooks
Good points, I want to use them to render stuff only. I think you still can attach events and such so when it runs on the client, the events works as expected.
Guys, Full page reload is OK, internet speed is fast now. :D We don't need complexity in UI anymore with React/Svelte/Vue etc.
Just use HTMX!!!!!
Frontend is modern hell now. We are over-complicating everything for saving some milliseconds and reducing build size by some KBs. :/
HTML, CSS and JS. How we’ve gone from that into all this craziness is crazy.
People should really look at PHP again. Frontend devs are such sheep.
php is gross, would rather use go or rust as an alternative
@@bear458ziif-s sure use anything else apart from the js ecosystem
@@bear458ziif-s How is it gross? Always extremely dubious when people make stupid comments like this without justification.
I think php gets a bad name because of wordpress.
@@jim..... that and also people are stuck with a decade old mindset. modern php and the laravel ecosystem is so much cleaner, faster, better than the modern js ecosystem.