There is just too much complication, right? From my experience, prerendering React is really CPU intensive. Because of that, I created my own framework, and with proper caching, it can serve up to 25k requests / second (~400MB/s throughput) on my local machine, much faster than a similar React app. Overall, I think server side React can be fast too, but there is certainly too much complication involved.
A good and detailed explanation of RSC and partial prerendering! As I understand this model, Next 14 uses Astro's paradigms: 1. Prerender static server components, that are above a ⌛ -> Deploy on Vercel 🚀 once, then send cached files 📑from CDN as initial response for every request 2. SSR dynamic server components, that use cookies🍪/ headers -> Render server component on the server on each request ♾and send new html partial 🎁to the client 💻 3. Await promises in server components that are wrapped in ⏳ -> HTTP stream 🌊html partials to the client 💻 4. Profit :D
One other point is that more of your code runs in a much more predictable environment (your own server). Even if the time to first full page render is a little longer with RSCs if the user was on a gigabit connection next to the datacenter, because you're sending a lot less data to the client, the 95% percentile time for the first full render is probably a lot shorter. The users with the worst connections are now experiencing a huge speedup. And it's way easier to measure performance and track exceptions etc on the server as well.
I'm confused about why there was confusion around the SVG loading at about 35:00. Are modern front-end devs so isolated from the concept of server side rendering that it's become a foreign concept to them? This whole server components thing seems to me, a dev who's been around since jQuery 1.11 days, like a return to form. We've come back around to building HTML templates and "rendering" them on the server, just like the early days of PHP, just with 80 more steps, and 100 more layers of abstraction. This isn't new.
TH-cam just deleted the reply I was typing in order to show me an Ad... long story short: I hear that. SEO concerns kept me away from the all-client all-the-time rendering paradigm except for side-project apps. Seems like the pendulum is swinging back, and might bring React into my regular dev toolkit now.
after playing a while with next and RSC and getting to understand how it works, it's actually crazy to have an overview how optimized things get. That is explained very well in this video
I'm surprised you skipped Josh's section on providers (the theme one). that was definitely a head scratcher for some of us. he explained things fairly well.
I loved this man you explained everything so good. I already knew a lot of it but didn't have a complete grasp on the overall concept and it's so much more clear to me thank you so much for this.
Indeed, another example of utilizing a server component is to manage the localization dictionary, avoiding the need to include it in the client-side JavaScript bundle.
25:50 good pattern for when using an interactive switcher controlled by state to switch between displaying static components that can definitely be server components (trying to make as many things URLs as possible but can't make everything a URL due to the way things are set up)
You focused a lot on initial page rendering, what about cases where what is fetched and rendered depends on user actions e.g. some sort of SaaSy, CRUDy stuff. Do you still solve this with e.g. Trpc + React Query or can I drop these tools and do everything with RSC's?
Yes, we solve this problems, the same way as before Server component enable you to render UI on server with some cache behavior and use server side modules and function It’s almost like PHP but with client side navigation preserved
Comprehensive is the right word for this. I think the major gripe (and this isn't explicit to react) is the lack of documentation/ best practices so the standard copypasta learn pattern isn't feasible, plus it's a new paradigm shift in thinking if you already had the original paradigm shift of react. Now as we approach a year, hopefully vercel isn't the only player in the game and we actually have more open dialogues and discussions other than "change bad."
Client component being restrictive reminds me of how async/await works. It felt restrictive at first because you can only use await inside async function, but it start making much more sense as you use it.
Would trying to render a datepicker on the server be possible? Is doing it a bad idea? (I'm still interested in what folks think but... having watched more of this video it seems like I should "use client" to render the datepicker and pull in my react server components as props.)
14:38 so this, to me, sounds similar to what htmx does right? makes a request to server then gets a new html with updated data. Not trying to compare the two, just trying to figure out if i understood this correctly
I definitely concede RSC is better, but with gSSP we _can_ type the props, the page component NextPage, and push the props into a typed page-wide context. It's a huge hassle! But we *do* get clearer awareness of which processes are blocking first-byte delivery. 2 years into RSC usage we might find it hard to identify all the blocking queries. But yeah, other advantages of RSC make it a clear winner.
So React can now basically do static HTML markup generation on command from the client, instead of doing it on application build. Cool. Combine that with a Redis cache and you'll have the next generation of blazingly fast Web applications.
"Next export shouldn't exist because exporting throws away Next's features" 4:22 We chose Next for a project *because* of it's ability to export to a static site. I get the argument, but for many projects a lot of the lost features are unnecessary.
The biggest thing missing from all these videos is they don't explore what happens later in client side navigation, how are things prefetched and so on.
Hey theo. I have a classic backend application with react as frontend and python flask as a backend. I am not allowed to move the database and credentials to the frontend due to security . How can i levearage this ssr and similar technologies in not Node.js backends .
I agree "use client" was a mistake. I sent l picked up nextjs after a year away and missed the memo that it will still render on the server, and was a very frustrating time until I realised this
So what about rendering video, say a pexels video on infinite loop(using the html video tag). Even hosted on vercel there are issues loading sometimes. Would server components or ssr/next solve this, or at least change where the issue is met?
I don’t think most users care that much about a short loading screen and so to burden devs with all these paradigm shifts for the sake of some optimization and improvement of user experience (most users didn’t think was too horrible) it leaves you kind of feeling like you’re building the same thing (a better website for users) and just sort of transferring the cost for that to the dev. Sure there were annoying problems and managing state can be annoying but this will bring in its own set of confusing patterns and annoyances, even if well learned. And what’s next? It’ll be some paradigm shift in a few years to solve some “problem” , meanwhile users and managers could really give af
thats exactly what a noob would say lol, the user experience is EVERYTHING. It can be diff between a bankrupt company or a thriving company. You are acting as if its just all bullshit but what we do makes or breaks a business. New devs need to learn to adapt, tech is changing fast and its all about the UX these days alot of companies are rewriting their stack with the cash they have in the balance sheet
It's not just about user experience, though. It's also about search indexing for discoverability. If the initial page load takes too long or doesn't contain the content to be indexed, search engines may just move on without gathering enough details to let people know your content even exists.
Does the project require the use of context, or was that an implementation decision based on the tools available at the time? I'm getting the feeling you can still use client side stuff like context and server components, but you just need to separate the concerns of initial loading (rendered by RSC) from the dynamic interactivity that hydrates in client side components. I think its matter of keeping the "what" distinct from the "how" in organizing the design process.
There is one use case I still don’t know how to handle with server components. Let’s say a user can switch between organizations like in any Saas app. The organization is global and defines all the content we will display. Where do I store which organization the user is logged into ? because if i store it in a context in a state, how does the server component know which data to fetch ?
Someone enlighten me plz, is it correct for me to think of RSC as an on-demand html renderer? So heavy components that depend on a lot of js can be offloaded to RSC? So these components can't be dynamic and interactive right?
but you cant use CDNs with this.. so you need to have servers running always.. so i dont think its "always better" if you have millions of clients you need to have more costs in more servers vs using a CDN. is this really that black and white?
So, let me get this straight, it's just html template + js for reactivity? Just like we did 100 years ago at Jquery times? Or better yet, it's just SSR + Hydration? Ok
Although RSC greatly mitigated the performance problem in SSR, i still find route switching to be janky than a well-built SPA (PWA mode in which it has no bundle-downloading-problem right after 1st load)...not to mention the running server problem, it is basically adding performance overhead for a non-node-js backend workshop. But it makes the prototyping phase extremely fast....I like it when doing early stage exploring.
Showing half-working UI to the user before the real thing kicks in is an unfortunate and sad state of modern UI (incl macOS/iOS etc). I hate to be confused and having no idea if it's supposed to be inert, or it's bugged, or it's still loading. But the most hated thing is sudden change of UI elements just before I click on what I see due to JS etc. starting to take over control. There are some games that actually discard user actions for a second before the updated UI becomes active but the majority (looking at you, Apple) is doing this nonsense. Please, stop. I will very much prefer to stair at empty ugly screen than you show me half-functioning UI that will jump all over the screen once everything is loaded. There is probably a way to make SSR right, but most of you won't, so I prefer to wait.
But the most ridiculous UI is in Minecraft (at least Xbox version) for already several YEARS. I have no idea what their UX team is doing if they even have one. Crap flies back and forward when the first menu screen gets loaded and they somehow think it's ok. F*ck you, Mojang/Microsoft!
I don't understand this. Why would it not be possible to use state in SSR? Because state changes? The client side pattern for showing some content that requires some initial data is very straightforward. You render the component initially with a loading progress, call the server API to fetch the data, put it in your state and re-render. Why can't the SSR simply initialize the state in a similar way you execute effect hooks or mount on client? If they could be merged into a new hook that's called in both, that would be the perfect scenario in my book. SSR would also need to send the state to the client, which can be done with a simple script tag next to the component output. I don't understand why you would need server components. To avoid hydration of components? That's like 0.001 ms if you use Preact, which gets rid of the synthetic event system. I mean you did say there are other solutions, but I think the other solutions are better than React server components.
My point is: This is going to be useless in a few years because javascript will get lighter and the internet faster, so, the loading spinner is going to be almost invisible
Server Components kinda feels like what I used to do with PHP + Ajax (usually with jQuery later ), except there isn't a s much of a gap to fill between server and client with some ad hoc solution ( mind you I'm thinking back to PHP 5.3 mostly. ) It was kinda fun to build out the communications between the front end in the browser, but you only can enjoy reinventing the same wheel so many times before it gets old. Seems like it should be nice to have server and client consistent in one codebase for dev/deployment, but kept appropriately isolated in active use. That said, I haven't build a project with react server components, yet, though, so this is just the impression that I get.
The explanation is not needed if react is doing what it is meant to do perfectly, building user interfaces.... I believe we need a way to speed up our app which is nice, but the approach nextjs followed in forcing everyone to use server components by default is still a mess
If you have a SINGLE client component that needs to be client then all next pages become loaded. You could have 100 pages and 1 heavy one and it'll kill your app. Why does next not handle this better since it's all per page?
Remember java serverfaces?, well I hate this exactly for the same reason, has nothing to do with the regression to php like code or the super shady move by Versel, the problem is trying to abstract away the server is a bad idea period.
But, RSC costs more money. You wouldn't use RSC for a blog and even an app if you can go Client Side rendering with a static hosting, right ? Who cares about these milliseconds or even a second of performance ? I care about cost effectiveness. Therefore, i will still go with cheap CDN and client side
“breakdown” is a very suitable word for describing my mental condition when working with react
Such a good comment
There is just too much complication, right? From my experience, prerendering React is really CPU intensive. Because of that, I created my own framework, and with proper caching, it can serve up to 25k requests / second (~400MB/s throughput) on my local machine, much faster than a similar React app. Overall, I think server side React can be fast too, but there is certainly too much complication involved.
Slow down. Slow is smooth, smooth is fast.
They are reinventing server side rendering and still make fun of the php and rails communities
@@ddomingo Surely you're not implying that a bunch of people online having opinions represent "React".
A good and detailed explanation of RSC and partial prerendering!
As I understand this model, Next 14 uses Astro's paradigms:
1. Prerender static server components, that are above a ⌛ -> Deploy on Vercel 🚀 once, then send cached files 📑from CDN as initial response for every request
2. SSR dynamic server components, that use cookies🍪/ headers -> Render server component on the server on each request ♾and send new html partial 🎁to the client 💻
3. Await promises in server components that are wrapped in ⏳ -> HTTP stream 🌊html partials to the client 💻
4. Profit :D
Thank you Theo! This solidified some things I was working through on all my recent apps. I haven't used Pages in weeks and I love it.
And obviously kudos to Josh! 😜 Been following his blog for years now and taken both his courses 😁 💅
This is a kick ass explanation with lots of passion coming through the examples. Thank you sir!
One other point is that more of your code runs in a much more predictable environment (your own server). Even if the time to first full page render is a little longer with RSCs if the user was on a gigabit connection next to the datacenter, because you're sending a lot less data to the client, the 95% percentile time for the first full render is probably a lot shorter. The users with the worst connections are now experiencing a huge speedup. And it's way easier to measure performance and track exceptions etc on the server as well.
Thoroughly enjoyed this past hour
I'm confused about why there was confusion around the SVG loading at about 35:00. Are modern front-end devs so isolated from the concept of server side rendering that it's become a foreign concept to them? This whole server components thing seems to me, a dev who's been around since jQuery 1.11 days, like a return to form. We've come back around to building HTML templates and "rendering" them on the server, just like the early days of PHP, just with 80 more steps, and 100 more layers of abstraction. This isn't new.
TH-cam just deleted the reply I was typing in order to show me an Ad... long story short: I hear that. SEO concerns kept me away from the all-client all-the-time rendering paradigm except for side-project apps. Seems like the pendulum is swinging back, and might bring React into my regular dev toolkit now.
Everything we need to understand all of the new and upcoming features. Thank you Theo!
after playing a while with next and RSC and getting to understand how it works, it's actually crazy to have an overview how optimized things get. That is explained very well in this video
One of your (and kudos to Josh) best videos! Really well underlined! .. and packed in a beautiful summary well done breakdown.
Amazing. Now I wish you'd read out all the tech blog articles that I can never get myself to do, but when you do it's so easily digestible.
Awesome video Theo. ❤
Love new RSCs
Bro it's videos like this that remind me why I subscribed like 12 months ago
This was amazing!!! You covered almost everything I was missing!
I'm surprised you skipped Josh's section on providers (the theme one). that was definitely a head scratcher for some of us. he explained things fairly well.
I loved this man you explained everything so good. I already knew a lot of it but didn't have a complete grasp on the overall concept and it's so much more clear to me thank you so much for this.
Common Joshwcomeau W + Banger video and demo. I wish I had this type of resources a couple of months back
Expertly explained! Love it
What happened to the studio you rented for filming? We don't see any videos from there nowadays
These desk videos are from live streams and the studio ones are recorded offline as of now. This could change, not sure.
Indeed, another example of utilizing a server component is to manage the localization dictionary, avoiding the need to include it in the client-side JavaScript bundle.
Thank you so so much Theo! These videos are both educational and inspirational. Like you content and approach so much! Thank youand have a nice day!
Just wanna say thanks, this was so helpful
Amazing video! Thanks Josh and Teo!
25:50 good pattern for when using an interactive switcher controlled by state to switch between displaying static components that can definitely be server components (trying to make as many things URLs as possible but can't make everything a URL due to the way things are set up)
Ohhh boy. Added to watch later. Pumped for this.
You focused a lot on initial page rendering, what about cases where what is fetched and rendered depends on user actions e.g. some sort of SaaSy, CRUDy stuff. Do you still solve this with e.g. Trpc + React Query or can I drop these tools and do everything with RSC's?
Yes, we solve this problems, the same way as before
Server component enable you to render UI on server with some cache behavior and use server side modules and function
It’s almost like PHP but with client side navigation preserved
Great video. Server component are really awesome, Idk how anyone can argue against it..
Comprehensive is the right word for this. I think the major gripe (and this isn't explicit to react) is the lack of documentation/ best practices so the standard copypasta learn pattern isn't feasible, plus it's a new paradigm shift in thinking if you already had the original paradigm shift of react. Now as we approach a year, hopefully vercel isn't the only player in the game and we actually have more open dialogues and discussions other than "change bad."
Fantastic video Theo!
Client component being restrictive reminds me of how async/await works. It felt restrictive at first because you can only use await inside async function, but it start making much more sense as you use it.
You've opened my eyes!
This is the way
This is the kind of content I subscribed to you for, amazing in depth explanations!
Amazing video. Thank you Theo
AMAZING CONTENT!!
I am glad most of you enjoyed , but I happen to find this session rushed through
48:13 I've been exactly wondering about "How do RSCs integrate with ?". Thanks for clearing this up!
Would trying to render a datepicker on the server be possible? Is doing it a bad idea?
(I'm still interested in what folks think but... having watched more of this video it seems like I should "use client" to render the datepicker and pull in my react server components as props.)
14:38 so this, to me, sounds similar to what htmx does right? makes a request to server then gets a new html with updated data. Not trying to compare the two, just trying to figure out if i understood this correctly
Great video!
I definitely concede RSC is better, but with gSSP we _can_ type the props, the page component NextPage, and push the props into a typed page-wide context. It's a huge hassle! But we *do* get clearer awareness of which processes are blocking first-byte delivery. 2 years into RSC usage we might find it hard to identify all the blocking queries. But yeah, other advantages of RSC make it a clear winner.
😊😊
So React can now basically do static HTML markup generation on command from the client, instead of doing it on application build. Cool. Combine that with a Redis cache and you'll have the next generation of blazingly fast Web applications.
"Next export shouldn't exist because exporting throws away Next's features" 4:22
We chose Next for a project *because* of it's ability to export to a static site. I get the argument, but for many projects a lot of the lost features are unnecessary.
great video
Thanks for the vid, now it's easier to wrap my mind around RSC. I wonder, does streaming make sense when the page is cached in a CDN?
how would all these come into play for a new full stack app with a mobile app as well that needs to make api calls
Is it really JSON if the property keys aren't doublequoted?
So, Node is PHP now, got it.
If people care so much about performance, why are they using react?
kek
Because they have a codebase which already has tens (or hundreds) of thousands of lines of code, and they can't start from scratch now.
Overall this is a great video!
The biggest thing missing from all these videos is they don't explore what happens later in client side navigation, how are things prefetched and so on.
Thanks Theo
Hey theo. I have a classic backend application with react as frontend and python flask as a backend.
I am not allowed to move the database and credentials to the frontend due to security .
How can i levearage this ssr and similar technologies in not Node.js backends
.
I agree "use client" was a mistake. I sent l picked up nextjs after a year away and missed the memo that it will still render on the server, and was a very frustrating time until I realised this
So what about rendering video, say a pexels video on infinite loop(using the html video tag). Even hosted on vercel there are issues loading sometimes. Would server components or ssr/next solve this, or at least change where the issue is met?
What to do when you have multiple consumers of your api like mobile aps?
only cry
I don’t think most users care that much about a short loading screen and so to burden devs with all these paradigm shifts for the sake of some optimization and improvement of user experience (most users didn’t think was too horrible) it leaves you kind of feeling like you’re building the same thing (a better website for users) and just sort of transferring the cost for that to the dev.
Sure there were annoying problems and managing state can be annoying but this will bring in its own set of confusing patterns and annoyances, even if well learned.
And what’s next? It’ll be some paradigm shift in a few years to solve some “problem” , meanwhile users and managers could really give af
thats exactly what a noob would say lol, the user experience is EVERYTHING. It can be diff between a bankrupt company or a thriving company. You are acting as if its just all bullshit but what we do makes or breaks a business. New devs need to learn to adapt, tech is changing fast and its all about the UX these days alot of companies are rewriting their stack with the cash they have in the balance sheet
Maybe most users don't, but Google does, and you'll rank lower in search results if you have poor CWV, which a loading screen will obliterate.
happy for the response i'll study up more on the matter
It's not just about user experience, though. It's also about search indexing for discoverability. If the initial page load takes too long or doesn't contain the content to be indexed, search engines may just move on without gathering enough details to let people know your content even exists.
@@MNbenMN yeah thats right 100%
How would u work with project that requires the use of context, I don’t think server component is that ready yet.
Does the project require the use of context, or was that an implementation decision based on the tools available at the time? I'm getting the feeling you can still use client side stuff like context and server components, but you just need to separate the concerns of initial loading (rendered by RSC) from the dynamic interactivity that hydrates in client side components. I think its matter of keeping the "what" distinct from the "how" in organizing the design process.
The server component that runs the client component that calls the server component that hydrates the client component
And when will it not be necessary to use a framework to use server components?
There is one use case I still don’t know how to handle with server components. Let’s say a user can switch between organizations like in any Saas app. The organization is global and defines all the content we will display. Where do I store which organization the user is logged into ? because if i store it in a context in a state, how does the server component know which data to fetch ?
should i store it with cookies ?
Yes, store it in a cookie
@@t3dotgg🍪🍪🍪🍪
2K23: Cookies Return :D
Someone enlighten me plz, is it correct for me to think of RSC as an on-demand html renderer? So heavy components that depend on a lot of js can be offloaded to RSC? So these components can't be dynamic and interactive right?
Yes, you can't use DOM methods and other interactivity in RSC
but you cant use CDNs with this.. so you need to have servers running always.. so i dont think its "always better" if you have millions of clients you need to have more costs in more servers vs using a CDN.
is this really that black and white?
nice shirt
Isn't this comparable to classic technologies like PHP, JSP, ASPX, ... so going back from SPA to more traditional web app development at the end?
yes, but this time it includes mixing of different components and abstracting most of the backend stuff
What's the name of the software for whiteboarding ?
I think it's excalidraw
I see why prime says go + htmx
How is this different from PHP? 😁
Old is always GOLD
Current FE path looks as: PHP -> React -> Next.js -> PHP again :D
RSC - welcome to functionality that almost every other framework supported at V1. :)
So, let me get this straight, it's just html template + js for reactivity? Just like we did 100 years ago at Jquery times?
Or better yet, it's just SSR + Hydration?
Ok
NextJS Router is just not ready for Prime Time Enterprise level... production. Its not. SO, Pages directory is our only alternative.
Although RSC greatly mitigated the performance problem in SSR, i still find route switching to be janky than a well-built SPA (PWA mode in which it has no bundle-downloading-problem right after 1st load)...not to mention the running server problem, it is basically adding performance overhead for a non-node-js backend workshop. But it makes the prototyping phase extremely fast....I like it when doing early stage exploring.
Aren't these in beta still?
@@rod6722 you are correct!
Showing half-working UI to the user before the real thing kicks in is an unfortunate and sad state of modern UI (incl macOS/iOS etc). I hate to be confused and having no idea if it's supposed to be inert, or it's bugged, or it's still loading. But the most hated thing is sudden change of UI elements just before I click on what I see due to JS etc. starting to take over control. There are some games that actually discard user actions for a second before the updated UI becomes active but the majority (looking at you, Apple) is doing this nonsense. Please, stop. I will very much prefer to stair at empty ugly screen than you show me half-functioning UI that will jump all over the screen once everything is loaded. There is probably a way to make SSR right, but most of you won't, so I prefer to wait.
But the most ridiculous UI is in Minecraft (at least Xbox version) for already several YEARS. I have no idea what their UX team is doing if they even have one. Crap flies back and forward when the first menu screen gets loaded and they somehow think it's ok. F*ck you, Mojang/Microsoft!
I see that LIL UGLY MANE vinyl box set 🔥
BISH IM MOROSE AND LUGUBRIOUS
I don't understand this. Why would it not be possible to use state in SSR? Because state changes? The client side pattern for showing some content that requires some initial data is very straightforward. You render the component initially with a loading progress, call the server API to fetch the data, put it in your state and re-render. Why can't the SSR simply initialize the state in a similar way you execute effect hooks or mount on client? If they could be merged into a new hook that's called in both, that would be the perfect scenario in my book. SSR would also need to send the state to the client, which can be done with a simple script tag next to the component output. I don't understand why you would need server components. To avoid hydration of components? That's like 0.001 ms if you use Preact, which gets rid of the synthetic event system. I mean you did say there are other solutions, but I think the other solutions are better than React server components.
Um SEO? Also javascript build on client can be crazy long - better to fetch data, pre-build then send? Kinda obvious duh?
My point is:
This is going to be useless in a few years because javascript will get lighter and the internet faster, so, the loading spinner is going to be almost invisible
37:21 I was blown up see those steps.
125th
But why use React then?
That’s it… I am going back to PHP.
only sane comment in this comment section by far.
Why
Server Components kinda feels like what I used to do with PHP + Ajax (usually with jQuery later ), except there isn't a s much of a gap to fill between server and client with some ad hoc solution ( mind you I'm thinking back to PHP 5.3 mostly. ) It was kinda fun to build out the communications between the front end in the browser, but you only can enjoy reinventing the same wheel so many times before it gets old. Seems like it should be nice to have server and client consistent in one codebase for dev/deployment, but kept appropriately isolated in active use.
That said, I haven't build a project with react server components, yet, though, so this is just the impression that I get.
idk if i try to understand next13 more i just wanna give up more
The explanation is not needed if react is doing what it is meant to do perfectly, building user interfaces.... I believe we need a way to speed up our app which is nice, but the approach nextjs followed in forcing everyone to use server components by default is still a mess
Web dev peaked with classic asp back in 2007.
dang it
If you have a SINGLE client component that needs to be client then all next pages become loaded. You could have 100 pages and 1 heavy one and it'll kill your app.
Why does next not handle this better since it's all per page?
Remember java serverfaces?, well I hate this exactly for the same reason, has nothing to do with the regression to php like code or the super shady move by Versel, the problem is trying to abstract away the server is a bad idea period.
But, RSC costs more money. You wouldn't use RSC for a blog and even an app if you can go Client Side rendering with a static hosting, right ?
Who cares about these milliseconds or even a second of performance ?
I care about cost effectiveness. Therefore, i will still go with cheap CDN and client side
It's insane how after a year of so of demos and talks about RSC so many engineer still get them wrong.
we learned nothing from yarn hype its always that
i don’t hate him, but i hate how he says “yall”
Coming from Django: duh.
Explain
after all this years people implementation php using JS
That's not how you pronounce Comeau.
2nd
1st in our ❤s
react has no business in server side rendering.
20 Megs of JavaScript. OMG..
this is all so unnecessary to me
explain
You're welcome not to use any of it, React will keep working the way it does right now.
I think it sucks.
why theo kinda….