[0:00] Starting Soon... [3:00] Preamble [11:30] Frontend vs. Backend & Too Much Change? [20:30] 1993-1997: The Static Web [38:15] 1997-2005: Dynamic Web & AJAX [47:15] 2005-2010: Split-Model Thinking [57:45] 2010-2016: JS Frameworks & CS Routing [1:14:30] 2016-????: SSR [1:34:30] The Dark Ages & Abstraction [1:44:15] Hydration & State Boundaries [1:53:15] The Trade-Offs of Resumability [2:02:30] Unified Client/Server Data Model [2:09:00] Is This Worth The Added Complexity? [2:19:45] Q&A: Back to Basics? Performance? Elm? [2:26:30] Q&A: DX? Local-First? React Crisis? [2:33:15] Q&A: WebSockets? We Don't Know! [2:39:15] Q&A: Signals? React? JS Paradox? Jobs? [2:44:15] Q&A: State Mismatch? Tooling? WASM? [2:57:00] Gift Sub Bonanza!! [3:05:30] Q&A: Caching? MST? Space Jam? SWs? [3:18:00] Conclusion: Finding What's Important [3:34:30] One Month of SolidStart Beta 2 [3:44:00] OMoSSB2: Streaming & API Routes [3:53:15] OMoSSB2: Base Path Fiasco & vs. [4:04:30] OMoSSB2: To Wrap or Not to Wrap? [4:16:00] OMoSSB2: Conclusion & New Experiments [4:33:30] This Week in JavaScript: Data Loading [4:38:15] TWiJ: Is Solid 10x Better? [4:44:45] TWiJ: Next.js vs. Rails [4:53:00] TWiJ: Solid News [4:55:30] TWiJ: The Balance of Complexity [5:10:00] The Future of These Streams
You made me smile at 30 years. Authorware director and mTropolis. Table layouts cutting images for the table animated gift and the web safe color palette. A simpler days
Best web dev content on the internet. Loving this web-nerd content. I wish marko + solid-islands would be a thing!! Right now Astro + solid-islands is some great DX with top-tier UX & CWV. Also keeping a close eye on Qwik too.
Now I don't like frontend because it seems like I am just wasting my time simply using abstraction over abstraction over abstraction and I don't know what the hell is going under the hood. 😂
Wow didn't know about this channel! Great stream! I've been a web dev for over a 10 year, for me the biggest problem with Next 14 and current shift is that it's really slow, and if we want that to be out gateway to BE services the cost is going to be big compared with downloading from CDN SPA app, I don't know just think that this is going fast and we are going to see problems soon, also now you have one more BE service to maintain, fun times :)
There is a reason why caching in Nextjs 14 is opt-out and not opt-in, I'm scared to do a benchmark Nextjs vs PHP + htmx not even to mention Golang + htmx
@@igortalic2021 I know.. cache as an architecture raises some concerns for me as well. Comparing to CDN is sort just debating where the catch is. Like CDN SPA that delays its data fetching until JS loads in should be slower than an initially server rendered streamed site. Like JS on the server might cost you 10s of ms.. but network waterfall avoidance saves the end user 100s of ms. While RSC solutions are still working through cache solutions, caching can always be added on top. My concern is less about external network here and more about it falling flat for write heavy workflows that lead to a lot more traffic on the backend. When people made Multi-Page Apps in the day you knew that you needed to be careful with how often you went back and forth because it would slow things down. This model basically lets the server re-render the whole page (and fetch all the data for it) every time you interact with. Not saying people will have to do that. It's just that without clear patterns for data ownership things are pushing that way. Mostly because people want to offload the data loading and we are looking at 2 different patterns where it might be clear what goes where.
@@ryansolid I completely agree with you, I think caching should always be opt-in and yes definitely we need clear patterns. This is going to be great once we figure things out, I like the new ideas framework makers are coming up with, like you, you do an amazing job, solid is great. It would be also really good for devs to decide how they want to host the app now, I think the community doesn't talk about this that much, but pricing going from SPA to SSR/RSC is also different, now you have a BE service that you need to scale and monitor an not all companies can go for lambdas or edge, and when you look at nextjs they just recently started providing cache solution for docker, and SST puts everything in 1 lambda when code grows cold starts start to be really bad. As I said this is now going to be are gateway to other BE services it would be nice to have a decent performance, I know this is a hard problem to solve, and we still have a lot of things to figure out, but it looks to me like everybody is going head first with RSC, if needed Im sticking with SSR for some time till we sort things out :D
Thinking about hydration from an MVC perspective: Traditional MVC has all 3 (M, V and C) on the server. The traditional Model is a collection of trees (a simple array would be many branches at depth 1). The traditional View is affectively a single block of (dynamic) HTML. The traditional Controller is a single entrypoint and logic to get to the Model and View. When making an SPA, we're moving the Model, View and Controller to the client. The Model pieces come from API calls, while the View(s) and Controller(s) become JS files. Every time we move something to the client we have to pay some bandwidth cost. We mitigate this with a mix of splitting, laziness and caching anything static. When hydrating we're trying to leave some things on the server and have some of the Model on the client. We do our best to make static or deferrable parts of the Model not be serialized. What about if we tried to split our Model up? Do we want to have e.g. islands which can hydrate separately (with caveats for deduping)? If we wanted parallel deserialization would we need to use workers? Does an asynchronous worker per island make any sense? Are they just overhead? Would they require prefetching? Do they fight against streaming? Islands are of course just one level of granularity.
Almost all of this comes down to the fact we use declarative models that are data driven. Like Islands vs not, Client components vs Server components are a way of basically splitting that data. Its just tricky to handle the different sources of truth. Like once the app is in the browser, "islands"/Client components can't ever be server rendered again as partials as they won't be hydratable because the server would not be aware of the current client state. Some of these new models are doing ok at automanaging this for you, but they either ask a lot in terms of developer awareness of potential serialization boundaries. The actual execution of the islands themselves etc isn't as big of a concern compared to the win we get simply by adopting some of these patterns to make sure we aren't hydrating everything else. But what I've been finding is not only have we raised the need to be thinking about this stuff, we introduced more and more concepts while the solutions themselves are getting more complex trying to navigate working around this shared declarative model. In the process we are being less effective at what we are trying to solve in the first place.
Could you therefore start to think of laziness as tiered hydration? We hydrate initially to pass data and enough code for bootstrapping, then later we send enough code so that the client can do rendering itself and just needs data to update however many areas of the page that are interested.
I think that I'm starting to get your point about server and client components being optimized for different scenarios. So even if the data fetching API is the same in both worlds, switching from server to client components has big consequences and can lead to most of the code having to be shipped to the client (nullifying the partial-hydration and data-serialization gains you get from server components). This means that apps that (1) do a lot of granular writes (which are the ones to benefit the most from signals) and (2) apps that need to persiste state between routes, will not benefit much at all from aaaall the work that you as a framework developer have to do to implement server components: they have to hydrate almost everything anyways and they have to serialize data for twice on initial page load. So now, I think that I understand more the dilemma you are facing having to choose what to develop first in Solid: Solid 2.0 with lazy hydration (aka. resumability) which benefits all SolidJS apps but that will only make a significant impact to apps with medium to large client bundles... Or developing Server Components first which benefit "sites" and read-mostly apps that persiste client state on navigation. The question seems to be reduced to: Should we do Partial hydration or Lazy hydration first? Especially since the realization that partial hydration is easily breakable by legitimate uses of the framework.
Some of what I wrote is wrong. "(2) apps that need to persiste state between routes" will in fact benefit from server components since server components can project server rendered content inside client components.
solid is the best framework. it's not sluggish like react. i have a rust backend and i found this library called rspc. it's the trpc equivalent of rust and i've been using the solid client with it. i hope that solid will continue to support spas in the future.
the way i see it is, the majority of apps do not require a framework. there's very few companies that are building the next twitter or amazon. most things that people are building are static sites with limited interactivity. everyone is so quick to jump on the framework bandwagon without asking themselves _why_ . when it makes sense to use them, we should use them, but otherwise what are we doing.
That's true. Mind you most of the people building frameworks traditionally targetting apps. The desire to pull these tools into the site space may be misguided but yet here we are. More so every year.
Ryan your quality on this content is unparalleled. It feels like a free lesson from one of the best. Unfortunately, it's tough for me to digest 5 hours weekly. I really hope there's comes up a way where this content could be somehow summed up in a 1-2 hour long maybe.
Yeah I realize. Unfortunately that takes up a lot more time then I have time for. I could possibly pay people to edit and break the content apart. I'm just trying to get the ideas out of my head and learn while I go.
@@ryansolidPersonally, I would definitely a written summary than a video one for this kind of content. You could maybe try extracting its transcript and feeding it to GPT. It may do quite a decent job for all its worth. Just an idea.
Microservices made cloud companies rich but did not provide promised redundancy or performance to users. SSR forces more work to be done on server also raising cloud costs. SSR looks like another version of Microservices, misleading users but making cloud companies rich ... er. It's funny the companies that penalize you for using "too much" js on client for SEO are also the companies with the most cloud services to sell ...
Bro ive been deploying client webapps on cloudflare pages for free.. why would I pay to host the same app on SSR when almost every page is already behind auth(for SEO). I dont get the hype behind it tbh.
I understand cloud companies are trying to sell their products. But it's not really an evil plan as such. They just build solutions for whatever direction the industry is going in and sell that. SSR is not a hype only tech. It has significant advantages in sites that usually require to take actions that make money for them. eCommerce is the obvious example. And there have been countless reports and studies on SSR that it's a proven tech and nothing superstitious 😊
One thing i have to say that there are solutions scattered across every framework for the problems but all are not together what me seeing it happen. The problem that you were saying that how wo presist state between page loads if we dont have a client side routing and react both are not there, the solution is there in Astro using the view transitions for the first time i thought that if i made the video be a link and the video is playing and then i click the link to another page the video would stop but with view transitions the state is persisted and the video keeps playing even when the transition is happening and the page is loading and the page is refreshing as Astro is MPA and not SPA so how it happens i dont know the inner working but i know that the solution is there i would suggest our take and info for this how is that working?
Astro solution has tearing/hydration solution. I you watch my stream with Mathew Phillips you will see it. Astro hasn't solved it either unfortunately. React is actually the closest from a technical level, but I'm not sure I'm happy where it ends up.
because it is indeed THE BEST for browsers, it's easy, dynamic, not lot of rules, you can develop shits quickly. If anything breaks, oh well it's just a web, it's not like it will break your computer. Imagine building static simple landing page and little functionality with C#, or Java. I'd choose js any day for the job
Content ⚠️ Warning: Mouth Noises and loud Swallowing. (srsly, please try to remember to mute your microphone when you go for a drink, or use a noise filter like Krisp or Nvidia Broadcast. You can even run the recording through one after the fact before you upload the stream to UA-cam)
Yeah.. that's never going to happen consistently. I don't upload to UA-cam after the fact. It's all live. I will see if I have time to look into noise filter. But if I have that sort of time I probably should be doing something else.
This is the intellectual corner of web development. Have checked other streams from Ryan, really dense and in depth conversations.
[0:00] Starting Soon...
[3:00] Preamble
[11:30] Frontend vs. Backend & Too Much Change?
[20:30] 1993-1997: The Static Web
[38:15] 1997-2005: Dynamic Web & AJAX
[47:15] 2005-2010: Split-Model Thinking
[57:45] 2010-2016: JS Frameworks & CS Routing
[1:14:30] 2016-????: SSR
[1:34:30] The Dark Ages & Abstraction
[1:44:15] Hydration & State Boundaries
[1:53:15] The Trade-Offs of Resumability
[2:02:30] Unified Client/Server Data Model
[2:09:00] Is This Worth The Added Complexity?
[2:19:45] Q&A: Back to Basics? Performance? Elm?
[2:26:30] Q&A: DX? Local-First? React Crisis?
[2:33:15] Q&A: WebSockets? We Don't Know!
[2:39:15] Q&A: Signals? React? JS Paradox? Jobs?
[2:44:15] Q&A: State Mismatch? Tooling? WASM?
[2:57:00] Gift Sub Bonanza!!
[3:05:30] Q&A: Caching? MST? Space Jam? SWs?
[3:18:00] Conclusion: Finding What's Important
[3:34:30] One Month of SolidStart Beta 2
[3:44:00] OMoSSB2: Streaming & API Routes
[3:53:15] OMoSSB2: Base Path Fiasco & vs.
[4:04:30] OMoSSB2: To Wrap or Not to Wrap?
[4:16:00] OMoSSB2: Conclusion & New Experiments
[4:33:30] This Week in JavaScript: Data Loading
[4:38:15] TWiJ: Is Solid 10x Better?
[4:44:45] TWiJ: Next.js vs. Rails
[4:53:00] TWiJ: Solid News
[4:55:30] TWiJ: The Balance of Complexity
[5:10:00] The Future of These Streams
mvp
I Started JavaScript Programming back when MySpace was a thing (2005 - 2009).
Today I learned these were the D A R K ± A G E S
thx
It’s completely off topic: I’m sick at home and listening/partially watching the recording and it gives me so much joy
You made me smile at 30 years. Authorware director and mTropolis. Table layouts cutting images for the table animated gift and the web safe color palette. A simpler days
Ryan your streams are best web dev content out there. I've learnt a bunch from most of them. Thank you honestly!
Excellent work Ryan, I love your streams!
Great session as usual
Best web dev content on the internet. Loving this web-nerd content. I wish marko + solid-islands would be a thing!! Right now Astro + solid-islands is some great DX with top-tier UX & CWV. Also keeping a close eye on Qwik too.
Now I don't like frontend because it seems like I am just wasting my time simply using abstraction over abstraction over abstraction and I don't know what the hell is going under the hood. 😂
Well if your new for one. Your NOT LEARNING how to code or develop. I moved on to Golang
I Started JavaScript Programming back when MySpace was a thing (2005 - 2009).
Today I learned these were the D A R K ± A G E S
27:50 it’s saved as a rich text file, think that’s the problem. Hit shift-cmd-t to make it plain text and save it as plain text with a html extension.
Wow didn't know about this channel! Great stream! I've been a web dev for over a 10 year, for me the biggest problem with Next 14 and current shift is that it's really slow, and if we want that to be out gateway to BE services the cost is going to be big compared with downloading from CDN SPA app, I don't know just think that this is going fast and we are going to see problems soon, also now you have one more BE service to maintain, fun times :)
There is a reason why caching in Nextjs 14 is opt-out and not opt-in, I'm scared to do a benchmark Nextjs vs PHP + htmx not even to mention Golang + htmx
@@igortalic2021 I know.. cache as an architecture raises some concerns for me as well. Comparing to CDN is sort just debating where the catch is. Like CDN SPA that delays its data fetching until JS loads in should be slower than an initially server rendered streamed site. Like JS on the server might cost you 10s of ms.. but network waterfall avoidance saves the end user 100s of ms. While RSC solutions are still working through cache solutions, caching can always be added on top.
My concern is less about external network here and more about it falling flat for write heavy workflows that lead to a lot more traffic on the backend. When people made Multi-Page Apps in the day you knew that you needed to be careful with how often you went back and forth because it would slow things down. This model basically lets the server re-render the whole page (and fetch all the data for it) every time you interact with. Not saying people will have to do that. It's just that without clear patterns for data ownership things are pushing that way. Mostly because people want to offload the data loading and we are looking at 2 different patterns where it might be clear what goes where.
@@ryansolid I completely agree with you, I think caching should always be opt-in and yes definitely we need clear patterns. This is going to be great once we figure things out, I like the new ideas framework makers are coming up with, like you, you do an amazing job, solid is great. It would be also really good for devs to decide how they want to host the app now, I think the community doesn't talk about this that much, but pricing going from SPA to SSR/RSC is also different, now you have a BE service that you need to scale and monitor an not all companies can go for lambdas or edge, and when you look at nextjs they just recently started providing cache solution for docker, and SST puts everything in 1 lambda when code grows cold starts start to be really bad. As I said this is now going to be are gateway to other BE services it would be nice to have a decent performance, I know this is a hard problem to solve, and we still have a lot of things to figure out, but it looks to me like everybody is going head first with RSC, if needed Im sticking with SSR for some time till we sort things out :D
Thinking about hydration from an MVC perspective:
Traditional MVC has all 3 (M, V and C) on the server. The traditional Model is a collection of trees (a simple array would be many branches at depth 1). The traditional View is affectively a single block of (dynamic) HTML. The traditional Controller is a single entrypoint and logic to get to the Model and View.
When making an SPA, we're moving the Model, View and Controller to the client. The Model pieces come from API calls, while the View(s) and Controller(s) become JS files. Every time we move something to the client we have to pay some bandwidth cost. We mitigate this with a mix of splitting, laziness and caching anything static.
When hydrating we're trying to leave some things on the server and have some of the Model on the client. We do our best to make static or deferrable parts of the Model not be serialized. What about if we tried to split our Model up? Do we want to have e.g. islands which can hydrate separately (with caveats for deduping)? If we wanted parallel deserialization would we need to use workers? Does an asynchronous worker per island make any sense? Are they just overhead? Would they require prefetching? Do they fight against streaming? Islands are of course just one level of granularity.
Almost all of this comes down to the fact we use declarative models that are data driven. Like Islands vs not, Client components vs Server components are a way of basically splitting that data. Its just tricky to handle the different sources of truth. Like once the app is in the browser, "islands"/Client components can't ever be server rendered again as partials as they won't be hydratable because the server would not be aware of the current client state. Some of these new models are doing ok at automanaging this for you, but they either ask a lot in terms of developer awareness of potential serialization boundaries. The actual execution of the islands themselves etc isn't as big of a concern compared to the win we get simply by adopting some of these patterns to make sure we aren't hydrating everything else.
But what I've been finding is not only have we raised the need to be thinking about this stuff, we introduced more and more concepts while the solutions themselves are getting more complex trying to navigate working around this shared declarative model. In the process we are being less effective at what we are trying to solve in the first place.
Could you therefore start to think of laziness as tiered hydration? We hydrate initially to pass data and enough code for bootstrapping, then later we send enough code so that the client can do rendering itself and just needs data to update however many areas of the page that are interested.
Just noticed that you said progressive hydration, rather than tiered.
I think that I'm starting to get your point about server and client components being optimized for different scenarios. So even if the data fetching API is the same in both worlds, switching from server to client components has big consequences and can lead to most of the code having to be shipped to the client (nullifying the partial-hydration and data-serialization gains you get from server components).
This means that apps that (1) do a lot of granular writes (which are the ones to benefit the most from signals) and (2) apps that need to persiste state between routes, will not benefit much at all from aaaall the work that you as a framework developer have to do to implement server components: they have to hydrate almost everything anyways and they have to serialize data for twice on initial page load.
So now, I think that I understand more the dilemma you are facing having to choose what to develop first in Solid: Solid 2.0 with lazy hydration (aka. resumability) which benefits all SolidJS apps but that will only make a significant impact to apps with medium to large client bundles... Or developing Server Components first which benefit "sites" and read-mostly apps that persiste client state on navigation.
The question seems to be reduced to: Should we do Partial hydration or Lazy hydration first? Especially since the realization that partial hydration is easily breakable by legitimate uses of the framework.
Some of what I wrote is wrong. "(2) apps that need to persiste state between routes" will in fact benefit from server components since server components can project server rendered content inside client components.
solid is the best framework. it's not sluggish like react. i have a rust backend and i found this library called rspc. it's the trpc equivalent of rust and i've been using the solid client with it. i hope that solid will continue to support spas in the future.
the way i see it is, the majority of apps do not require a framework. there's very few companies that are building the next twitter or amazon. most things that people are building are static sites with limited interactivity. everyone is so quick to jump on the framework bandwagon without asking themselves _why_ . when it makes sense to use them, we should use them, but otherwise what are we doing.
That's true. Mind you most of the people building frameworks traditionally targetting apps. The desire to pull these tools into the site space may be misguided but yet here we are. More so every year.
Ryan your quality on this content is unparalleled. It feels like a free lesson from one of the best. Unfortunately, it's tough for me to digest 5 hours weekly. I really hope there's comes up a way where this content could be somehow summed up in a 1-2 hour long maybe.
Yeah I realize. Unfortunately that takes up a lot more time then I have time for. I could possibly pay people to edit and break the content apart. I'm just trying to get the ideas out of my head and learn while I go.
@@ryansolidPersonally, I would definitely a written summary than a video one for this kind of content. You could maybe try extracting its transcript and feeding it to GPT. It may do quite a decent job for all its worth. Just an idea.
Microservices made cloud companies rich but did not provide promised redundancy or performance to users. SSR forces more work to be done on server also raising cloud costs. SSR looks like another version of Microservices, misleading users but making cloud companies rich ... er. It's funny the companies that penalize you for using "too much" js on client for SEO are also the companies with the most cloud services to sell ...
Bro ive been deploying client webapps on cloudflare pages for free.. why would I pay to host the same app on SSR when almost every page is already behind auth(for SEO). I dont get the hype behind it tbh.
I understand cloud companies are trying to sell their products. But it's not really an evil plan as such. They just build solutions for whatever direction the industry is going in and sell that.
SSR is not a hype only tech. It has significant advantages in sites that usually require to take actions that make money for them. eCommerce is the obvious example.
And there have been countless reports and studies on SSR that it's a proven tech and nothing superstitious 😊
do you need new stream ideas? if yes I'm sure the community would be happy to propose some
One thing i have to say that there are solutions scattered across every framework for the problems but all are not together what me seeing it happen.
The problem that you were saying that how wo presist state between page loads if we dont have a client side routing and react both are not there, the solution is there in Astro using the view transitions for the first time i thought that if i made the video be a link and the video is playing and then i click the link to another page the video would stop but with view transitions the state is persisted and the video keeps playing even when the transition is happening and the page is loading and the page is refreshing as Astro is MPA and not SPA so how it happens i dont know the inner working but i know that the solution is there i would suggest our take and info for this how is that working?
Astro solution has tearing/hydration solution. I you watch my stream with Mathew Phillips you will see it. Astro hasn't solved it either unfortunately. React is actually the closest from a technical level, but I'm not sure I'm happy where it ends up.
@@ryansolidhmm okay i will see the stream.
35:45 So basically Incremental Static Regeneration (ISR) 🤣
20:00 there is too much change because what we are using know sucks and is either SLOW, unnecessarily complex, too huge, and not robust (error prone)
It just always comes back to 'why did they think js for browsers was the best way to go'
because it is indeed THE BEST for browsers, it's easy, dynamic, not lot of rules, you can develop shits quickly. If anything breaks, oh well it's just a web, it's not like it will break your computer. Imagine building static simple landing page and little functionality with C#, or Java. I'd choose js any day for the job
One solution I found was to create aggregation in dynamodb and use graphql/cache .
things being discussed are wayyy above my pay-grade
720p?? only
Yeah I downgraded to save money. I'd rather money in Solid's open collective to go towards development than improving the video quality.
@@ryansolid ha ha
Time stamps😢
Patience, young padawan
Content ⚠️ Warning: Mouth Noises and loud Swallowing.
(srsly, please try to remember to mute your microphone when you go for a drink, or use a noise filter like Krisp or Nvidia Broadcast. You can even run the recording through one after the fact before you upload the stream to UA-cam)
Yeah.. that's never going to happen consistently. I don't upload to UA-cam after the fact. It's all live. I will see if I have time to look into noise filter. But if I have that sort of time I probably should be doing something else.
cant believe how bad macOS is when people pay that much for it
What are you smoking 🤣
hot take: learn Backend