[0:00] Starting Soon... [1:45] Preamble [7:00] Why Are We Talking About Waterfalls? [17:30] What Is a Waterfall and Why Do We Care? [25:00] The Benefits of Grouping Requests [32:00] The Tradeoffs of Grouping Requests [44:00] The Internet's Inherent Waterfalls [1:00:00] Data Fetching & Client State [1:16:00] Streaming, Spinners, & Suspense [1:25:00] RSCs & Componentized Data Fetching [1:32:45] Await Means Stop [1:42:00] The Remix Approach & Loaders [1:52:45] Server Waterfalls Are Real [2:01:15] The DataLoader Example [2:08:00] Single Flight Mutations [2:19:15] Conclusion: More Than One Way [2:25:15] Are Server Components Actually Composable? [2:41:00] Q&A: Publish This? Composition? Slots? [2:51:30] This Week in JavaScript: Solid News [3:00:30] TWiJ: The Trough of Disillusionment [3:06:00] TWiJ: A Framework for Future Developers [3:18:00] TWiJ: Bobae Kang - React, Solid, & HTMX [3:23:00] TWiJ: Brenley Dueck - Vinxi Article [3:28:00] TWiJ: HTMX Notion App [3:33:00] TWiJ: Qwik 2.0 [3:45:15] TWiJ: You'll Never Need These APIs Again [3:55:00] TWiJ: React Blog Post - React Compiler [4:16:15] TWiJ: React Blog Post - Actions & Resources [4:23:45] TWiJ: JS Framework Benchmark Fun [4:32:45] TWiJ: Signal Memes & Reactivity History [4:45:30] Conclusion & Future Stream Schedule Sorry for the delay!
What would happen if you allow fetching in components but not awaiting them. After you render the component tree once, you collect all started fetch calls and then, once they resolve, you apply their result (with reactivity or by rerender, it should not matter much for my example). This may cause more fetch-calls to happen, but I want to make an argument on why that may be ok: 1. The subsequent fetch-calls need the result of the previous once as input. This is a natural waterfall and pretty much unavoidable without a change in the external API. 2. The subsequent fetch-calls itself is only needed in specific cases depending on the previous one. They could be run in parallel, but the result may need to be discarded/the fetch be cancelled once the other data was gathered. I think this would be a strategy to have fetch in components, but also avoid waterfalls. But I may be completely wrong.
I mean this is basically what we do in Solid. 2 things get in the way of it. Guards people will put up anyway. Like conditionals based on the loaded data to decide when deciding where to show it blocking children. This can often be avoided but it is common. Routes in the client are almost always code split which means that code then fetch waterfalls are pretty common. Also when considering nested route sections.
Ensure things remain on the server even when client routing. Client routing moves the topmost decision point high enough in your application that many of the savings Qwik makes no longer apply. It can still lazily load the code but it can't make the same data serialization savings guarentees to my knowledge.
![FNAF vs TF2 - Episode 2 [SFM]](http://i.ytimg.com/vi/z5b3V2-VLb0/mqdefault.jpg)
[0:00] Starting Soon...
[1:45] Preamble
[7:00] Why Are We Talking About Waterfalls?
[17:30] What Is a Waterfall and Why Do We Care?
[25:00] The Benefits of Grouping Requests
[32:00] The Tradeoffs of Grouping Requests
[44:00] The Internet's Inherent Waterfalls
[1:00:00] Data Fetching & Client State
[1:16:00] Streaming, Spinners, & Suspense
[1:25:00] RSCs & Componentized Data Fetching
[1:32:45] Await Means Stop
[1:42:00] The Remix Approach & Loaders
[1:52:45] Server Waterfalls Are Real
[2:01:15] The DataLoader Example
[2:08:00] Single Flight Mutations
[2:19:15] Conclusion: More Than One Way
[2:25:15] Are Server Components Actually Composable?
[2:41:00] Q&A: Publish This? Composition? Slots?
[2:51:30] This Week in JavaScript: Solid News
[3:00:30] TWiJ: The Trough of Disillusionment
[3:06:00] TWiJ: A Framework for Future Developers
[3:18:00] TWiJ: Bobae Kang - React, Solid, & HTMX
[3:23:00] TWiJ: Brenley Dueck - Vinxi Article
[3:28:00] TWiJ: HTMX Notion App
[3:33:00] TWiJ: Qwik 2.0
[3:45:15] TWiJ: You'll Never Need These APIs Again
[3:55:00] TWiJ: React Blog Post - React Compiler
[4:16:15] TWiJ: React Blog Post - Actions & Resources
[4:23:45] TWiJ: JS Framework Benchmark Fun
[4:32:45] TWiJ: Signal Memes & Reactivity History
[4:45:30] Conclusion & Future Stream Schedule
Sorry for the delay!
Hey @zombiefacesupreme maybe we could work out a schedule to take turns for this and post the time stamps earlier for the viewers??
@@boomshakalaka656 Sure, buddy. You can do the next one, and we can switch off each time. 🙂
@@zombiefacesupreme would you mind if moved this conversation elsewhere to discuss further info?
This is useState vs Signals all over again. Tying state to the component vs having it available anywhere
1:50:32 If everything looks like a nail - you need a hammer
Or everything looks like a nail if you have a hammer
What would happen if you allow fetching in components but not awaiting them. After you render the component tree once, you collect all started fetch calls and then, once they resolve, you apply their result (with reactivity or by rerender, it should not matter much for my example). This may cause more fetch-calls to happen, but I want to make an argument on why that may be ok:
1. The subsequent fetch-calls need the result of the previous once as input. This is a natural waterfall and pretty much unavoidable without a change in the external API.
2. The subsequent fetch-calls itself is only needed in specific cases depending on the previous one. They could be run in parallel, but the result may need to be discarded/the fetch be cancelled once the other data was gathered.
I think this would be a strategy to have fetch in components, but also avoid waterfalls. But I may be completely wrong.
I mean this is basically what we do in Solid. 2 things get in the way of it. Guards people will put up anyway. Like conditionals based on the loaded data to decide when deciding where to show it blocking children. This can often be avoided but it is common.
Routes in the client are almost always code split which means that code then fetch waterfalls are pretty common. Also when considering nested route sections.
Can anyone please explain to me what denefit there could be to qwik have a serverComponent$
Ensure things remain on the server even when client routing. Client routing moves the topmost decision point high enough in your application that many of the savings Qwik makes no longer apply. It can still lazily load the code but it can't make the same data serialization savings guarentees to my knowledge.
5:30 React
6:30 every time I've seen water, gravity has been involved.
Great stuff as usual 💪
Time stamps 😢
I see u often asking the same question. If u need timestamps it's best to wait a couple of days so zombiefacesupreme had time to do them.
2:27:44 Hmm for me it's not really stop it's just do other stuff instead.