Great talk as per usual! The history of the web and pros/cons of each approach is money. Understanding things holistically / big picture is almost impossible to find now with all the FE bloat. These videos are truly unlocking super saiyan web dev mode inside of me. Keep it up!
3:29:00 watching this now, i wonder what the market shows after these 8-12 months, if there are obvious better solutions to sc than rsc :) i guess, i am going to find out in the newer streams, thanks a lot ryan!
This is the explanation i needed , the react team did a terrible job explaining what server components are and even worse let the big 2 run off with their own definitions which were worded in the context of their meta frameworks .
I don't get what is great about react query? It uses fetch as you render pattern, meaning it is as inefficient as its competitors and it has nothing extra ordinary or innovative. If you opt out of caching, what it has left with to offer?
With the solidstart optmistic update on mutation, when the server sends the mutation and then gets the response to render server side , would it only server render the one component (comment)? just curious if in this design it would be possible for the server to have multiple new server rendered components outside of the optimistic update confirmation. I might be missing the point on this one, but if I understand you pay the cost on the client for having a spare optimistic update component, that then isnt needed when the server re-rendered content comes back? Or is this example more for what all users would see on that page from here on out / push updates? Just trying to understand, both seem powerful to me - but I think I am missing something. And I am also curious if it is relevant to the cases I mentioned. Thanks!
And would the page/island need to rerender? if you already did the update locally optimistically, I am guessing if the response has your component. So you can diff the data over the wire based on its contents, or is this adding too much complexity to the client? And what was the granularity of the island route in this example? Just trying to crystalize this example, because I may have missed it. If anyone knows, please explain :)
@@tenthlegionstudios1343 Yes. You can also not do optimistic updates here. I was just explaining how one might do an optimistic update even if the content is "server content". This does mean the the code would be shipped to the browser to render a comment which might defeat the point a little, but you still saved the serialization of the data cost when the page loaded. The optimistic update goes away when the server responds with the actual data, and this update can be diffed. In terms of router, mutations general pattern is not to look at refreshing sections but to refresh the whole page (still diffed). I am still trying to think if we an do smarter things than just caching the data. My gut is we can. But to accomplish this the router needs to be aware of the data fetching.
@@ryansolid Thanks! This point you made here is definitely what I missed: "In terms of router, mutations general pattern is not to look at refreshing sections but to refresh the whole page (still diffed). " The router being aware of the data fetching made sense as a path to improve things. I just thought the router was fined grained within a page and on mutation was only looking at the mutated piece of the page. Then caching this new small update within the whole page render, only sending the mutated island/new UI to the user who made the mutation, and serving the new updated cached page to any new user on future requests. And this was only possible because the mutation request kept that connection to the mutated user open.
Wouldn't resumable frameworks like qwik and marco fix this issue of loading a bunch of JS into loading practically nothing? I am really impressed by qwik and how easy it is to develop apps with it. I believe resumable frameworks will be the norm for at least the next 5 to 10 years until something better comes up. I do love spa apps though so for me, frameworks like astro are a no go. There are also frameworks such as leptos which I would love to use but the insane amount of JS you need to load it's just a let down at the moment, maybe in the future will be a thing... There is also phoenix/elixir which I do not understand very well so I don't know what advantages we can get from it. I have tried to get my head around it but it's just so different from everything else that I have a hard time getting the grasp of it.
Qwik has an interesting philosophy but it still has to prove itself over the long term. The idea behind it is to only download the Javascript you need for the interactions that are going to be used. But if you are going to use all of them then all the JavaScript will be downloaded eventually. The Islands architecture is an approach that seeks to do everything on the server that can be done on the server while anything that needs to be done (or is beneficial to do) on the client will be done on the client-it aims to reduce the total amount of JavaScript on the client. Phoenix LiveView aims to do everything (for the most part) on the server with all the render logic being written in server side Elixir. The tradeoff is that it requires a continuously stable, low latency (and possibly high bandwidth) network connection to the client for reasonable UX as most interactions and DOM changes (controlling morphdom in the browser) are sent over the wire. The one advantage Phoenix LiveView has over Laravel LiveWire, .NET Blazor Server and Rails Hotwire is the excellent (and scalable) primitives of the Erlang VM for handling server side state (and fault tolerance).
Resumability focuses on the optimization. This focuses on the architecture. These aren't mutually exclusive. Whether you use Qwik or not the routing question is still relevant. Most Qwik demos today are MPAs like Astro. It's sort of understood that naive client side routing isn't great even there. Navigate to the next page with typical client routing you still download and execute all the javascript (you need to, to render the next page). Qwik(and Marko) will have routing solutions like I describe in this stream one day. My position is you solve the hybrid routing and reduce what needs to hydrate with things like Islands/Server Components and you've already reduced 80% of the work. Resumability might reduce another 10% (on initial load). Resumability is an important optimization but it isn't the architecture. It improves performance but doesn't fundamentally change what we are doing as it only really benefits initial page load.
![⚛️ Dan Abramov explores React Server Components with us! [VOD]](http://i.ytimg.com/vi/Fctw7WjmxpU/mqdefault.jpg)
Great talk as per usual! The history of the web and pros/cons of each approach is money. Understanding things holistically / big picture is almost impossible to find now with all the FE bloat. These videos are truly unlocking super saiyan web dev mode inside of me. Keep it up!
3:29:00 watching this now, i wonder what the market shows after these 8-12 months, if there are obvious better solutions to sc than rsc :) i guess, i am going to find out in the newer streams, thanks a lot ryan!
Great stream and especially timely. Thank You!
4:37:51 I don't think the "Signals Are Bad" meme ever went into general circulation on Twitter.
This is the explanation i needed , the react team did a terrible job explaining what server components are and even worse let the big 2 run off with their own definitions which were worded in the context of their meta frameworks .
Amazing!
Hello Ryan. I just want to say that the idea os Signals is very performant and fast.
I don't get what is great about react query? It uses fetch as you render pattern, meaning it is as inefficient as its competitors and it has nothing extra ordinary or innovative. If you opt out of caching, what it has left with to offer?
With the solidstart optmistic update on mutation, when the server sends the mutation and then gets the response to render server side , would it only server render the one component (comment)? just curious if in this design it would be possible for the server to have multiple new server rendered components outside of the optimistic update confirmation.
I might be missing the point on this one, but if I understand you pay the cost on the client for having a spare optimistic update component, that then isnt needed when the server re-rendered content comes back? Or is this example more for what all users would see on that page from here on out / push updates? Just trying to understand, both seem powerful to me - but I think I am missing something. And I am also curious if it is relevant to the cases I mentioned. Thanks!
And would the page/island need to rerender? if you already did the update locally optimistically, I am guessing if the response has your component. So you can diff the data over the wire based on its contents, or is this adding too much complexity to the client? And what was the granularity of the island route in this example? Just trying to crystalize this example, because I may have missed it. If anyone knows, please explain :)
@@tenthlegionstudios1343 Yes. You can also not do optimistic updates here. I was just explaining how one might do an optimistic update even if the content is "server content". This does mean the the code would be shipped to the browser to render a comment which might defeat the point a little, but you still saved the serialization of the data cost when the page loaded. The optimistic update goes away when the server responds with the actual data, and this update can be diffed.
In terms of router, mutations general pattern is not to look at refreshing sections but to refresh the whole page (still diffed). I am still trying to think if we an do smarter things than just caching the data. My gut is we can. But to accomplish this the router needs to be aware of the data fetching.
@@ryansolid Thanks! This point you made here is definitely what I missed: "In terms of router, mutations general pattern is not to look at refreshing sections but to refresh the whole page (still diffed). " The router being aware of the data fetching made sense as a path to improve things. I just thought the router was fined grained within a page and on mutation was only looking at the mutated piece of the page. Then caching this new small update within the whole page render, only sending the mutated island/new UI to the user who made the mutation, and serving the new updated cached page to any new user on future requests. And this was only possible because the mutation request kept that connection to the mutated user open.
"It's the story of how they killed signals" 😂
Wouldn't resumable frameworks like qwik and marco fix this issue of loading a bunch of JS into loading practically nothing? I am really impressed by qwik and how easy it is to develop apps with it. I believe resumable frameworks will be the norm for at least the next 5 to 10 years until something better comes up. I do love spa apps though so for me, frameworks like astro are a no go. There are also frameworks such as leptos which I would love to use but the insane amount of JS you need to load it's just a let down at the moment, maybe in the future will be a thing...
There is also phoenix/elixir which I do not understand very well so I don't know what advantages we can get from it. I have tried to get my head around it but it's just so different from everything else that I have a hard time getting the grasp of it.
Qwik has an interesting philosophy but it still has to prove itself over the long term. The idea behind it is to only download the Javascript you need for the interactions that are going to be used. But if you are going to use all of them then all the JavaScript will be downloaded eventually.
The Islands architecture is an approach that seeks to do everything on the server that can be done on the server while anything that needs to be done (or is beneficial to do) on the client will be done on the client-it aims to reduce the total amount of JavaScript on the client.
Phoenix LiveView aims to do everything (for the most part) on the server with all the render logic being written in server side Elixir. The tradeoff is that it requires a continuously stable, low latency (and possibly high bandwidth) network connection to the client for reasonable UX as most interactions and DOM changes (controlling morphdom in the browser) are sent over the wire.
The one advantage Phoenix LiveView has over Laravel LiveWire, .NET Blazor Server and Rails Hotwire is the excellent (and scalable) primitives of the Erlang VM for handling server side state (and fault tolerance).
@@PeerReynders thank you Peer! It was very helpful reading your reply.
Resumability focuses on the optimization. This focuses on the architecture. These aren't mutually exclusive. Whether you use Qwik or not the routing question is still relevant. Most Qwik demos today are MPAs like Astro. It's sort of understood that naive client side routing isn't great even there. Navigate to the next page with typical client routing you still download and execute all the javascript (you need to, to render the next page). Qwik(and Marko) will have routing solutions like I describe in this stream one day.
My position is you solve the hybrid routing and reduce what needs to hydrate with things like Islands/Server Components and you've already reduced 80% of the work. Resumability might reduce another 10% (on initial load). Resumability is an important optimization but it isn't the architecture. It improves performance but doesn't fundamentally change what we are doing as it only really benefits initial page load.