[0:00] Preamble [5:00] Q&A: Shorter Videos? Component Libraries? [11:00] Q&A: Imba? neo.mjs? Rakkas? Angular? Remix? [19:30] The Friction Between Data Loading Paradigms [27:45] ui = fn(data)(state) - Unidirectional? [33:30] Where Does the State Live? [49:00] What Is Hydration? [1:03:45] It's More Than Adding Event Listeners [1:10:00] Hydration vs. Rendering [1:26:00] Performance vs. Removing Complexity [1:44:00] What Is An HTML Partial? [1:52:30] Once State is Updated, Islands Can't Hydrate [1:59:00] Islands vs. Server Components / MPA vs. SPA [2:15:00] Island Lifecycles & The Double Data Problem [2:28:00] HTML Is Lossy [2:38:30] Render vs. Mutation / GET vs. POST [2:47:45] The Mutation Slippery Slope: Direct Mutation [2:52:45] MSS: Revalidation - Key-Based & Route-Based [2:59:45] MSS: Server Components [3:05:45] MSS: Weighing the Tradeoffs [3:12:00] MSS: Is There a Silver Bullet Solution? [3:22:30] MSS: Conclusion - Where Do We Go From Here? [3:31:30] Derivations in Reactivity [3:39:30] DiR: Derivation vs. Synchronization [3:47:00] DiR: Push vs. Pull [3:52:30] DiR: Pull (Scheduling) [4:03:30] DiR: Push (Events) [4:08:15] DiR: Conclusion - Push-Pull (Signals) [4:24:35] This Week in JavaScript: Solid News [4:27:45] TWiJ: Solid's JSX Transform [4:44:45] TWiJ: The React use Hook & Remix Demos [4:50:45] TWiJ: Lightning Round [4:58:00] TWiJ: Remix SPA Mode & Framework Comparison [5:04:00] TWiJ: The React Backlash [5:20:00] Conclusion: The Framework Should Disappear?
3:27:22 I hope you're right and we end up with better browsing experiences on the web for everyone, but sometimes I can't shake the feeling that SPAs were the peak future of simplification and innovation, and now it seems like we're going back in time (not exactly back, I know, but you get my point).
Even back in 2015 people like Peter-Paul Koch opined (web vs. native: let’s concede defeat) that the app model wasn't a great fit for the web. So in that context, SPAs could be an oversimplification, at least for the majority of use cases.
One way to look at it is that client rendering is good enough for patching the DOM which is something vDOMs leverage (aside: signals improve things primarily in situations when they need to change even less; vDOM transforms immediate mode virtual rendering to retained mode deltas while signals focus directly on the deltas). The other issue is what amounts to minimizing the ”cold start” cost. • native browser code is faster at building a full page DOM from HTML than JS • building DOM from HTML can run in a separate thread (or core) • building DOM from HTML can start before JS has finished fetching, and parsing. Finally typical CSR encourages a do everything on the client mentality which isn't the best approach when you cannot control the computational capabilities of the client nor the quality of the connection to the client. Given that The web is the most hostile software engineering environment imaginable a defensive (Generation 3) strategy of Do it on the server where possible, on the client only when needed simply makes sense and ultimately leads to the islands architecture.
… though in this particular context it's probably about reducing round trips. Imagine having a disclosure toggle that starts out collapsed. You don't want to negatively impact UX by having to go back to the server to fetch the content when the visitor expands the toggle. And if you are shipping the data to the client already you might as well have it sitting ready to go in the DOM, rather than rendering it on expansion.
@@PeerReyndersI guess I was thinking that all the JS would be eagerly loaded so only the landing page would be SSRd. Islands/ClientComponents + Partials/ServerComponents would minimize subsequent cold start costs so no need for subsequent SSR/hydration. But obviously Ryan thinks subsequent SSR/hydration still is needed
@@OuterProduct351 Perhaps I'm misunderstanding but while applications have a starting screen, web solutions represent their core state via the URL which itself is a route and with SSR any route can be rendered by the server at the start of a new session. So if you let authentication persist across sessions the HTML will vary by URL. And even if the JS bundle is cached it still has to be parsed and evaluated when a new session is started. As Addy Osmani has pointed out since his first The Cost of JavaScript in 2017, JS has cost beyond download, i.e. parse and eval.
[0:00] Preamble
[5:00] Q&A: Shorter Videos? Component Libraries?
[11:00] Q&A: Imba? neo.mjs? Rakkas? Angular? Remix?
[19:30] The Friction Between Data Loading Paradigms
[27:45] ui = fn(data)(state) - Unidirectional?
[33:30] Where Does the State Live?
[49:00] What Is Hydration?
[1:03:45] It's More Than Adding Event Listeners
[1:10:00] Hydration vs. Rendering
[1:26:00] Performance vs. Removing Complexity
[1:44:00] What Is An HTML Partial?
[1:52:30] Once State is Updated, Islands Can't Hydrate
[1:59:00] Islands vs. Server Components / MPA vs. SPA
[2:15:00] Island Lifecycles & The Double Data Problem
[2:28:00] HTML Is Lossy
[2:38:30] Render vs. Mutation / GET vs. POST
[2:47:45] The Mutation Slippery Slope: Direct Mutation
[2:52:45] MSS: Revalidation - Key-Based & Route-Based
[2:59:45] MSS: Server Components
[3:05:45] MSS: Weighing the Tradeoffs
[3:12:00] MSS: Is There a Silver Bullet Solution?
[3:22:30] MSS: Conclusion - Where Do We Go From Here?
[3:31:30] Derivations in Reactivity
[3:39:30] DiR: Derivation vs. Synchronization
[3:47:00] DiR: Push vs. Pull
[3:52:30] DiR: Pull (Scheduling)
[4:03:30] DiR: Push (Events)
[4:08:15] DiR: Conclusion - Push-Pull (Signals)
[4:24:35] This Week in JavaScript: Solid News
[4:27:45] TWiJ: Solid's JSX Transform
[4:44:45] TWiJ: The React use Hook & Remix Demos
[4:50:45] TWiJ: Lightning Round
[4:58:00] TWiJ: Remix SPA Mode & Framework Comparison
[5:04:00] TWiJ: The React Backlash
[5:20:00] Conclusion: The Framework Should Disappear?
3:27:22 I hope you're right and we end up with better browsing experiences on the web for everyone, but sometimes I can't shake the feeling that SPAs were the peak future of simplification and innovation, and now it seems like we're going back in time (not exactly back, I know, but you get my point).
Even back in 2015 people like Peter-Paul Koch opined (web vs. native: let’s concede defeat) that the app model wasn't a great fit for the web.
So in that context, SPAs could be an oversimplification, at least for the majority of use cases.
Great stuff 💪
2:16:14 Ah, I here's the insight into the problem of HTML Partials. Although, I'm not sure why only client rendering isn't good enough
One way to look at it is that client rendering is good enough for patching the DOM which is something vDOMs leverage (aside: signals improve things primarily in situations when they need to change even less; vDOM transforms immediate mode virtual rendering to retained mode deltas while signals focus directly on the deltas).
The other issue is what amounts to minimizing the ”cold start” cost.
• native browser code is faster at building a full page DOM from HTML than JS
• building DOM from HTML can run in a separate thread (or core)
• building DOM from HTML can start before JS has finished fetching, and parsing.
Finally typical CSR encourages a do everything on the client mentality which isn't the best approach when you cannot control the computational capabilities of the client nor the quality of the connection to the client. Given that
The web is the most hostile software engineering environment imaginable
a defensive (Generation 3) strategy of
Do it on the server where possible, on the client only when needed
simply makes sense and ultimately leads to the islands architecture.
… though in this particular context it's probably about reducing round trips.
Imagine having a disclosure toggle that starts out collapsed. You don't want to negatively impact UX by having to go back to the server to fetch the content when the visitor expands the toggle. And if you are shipping the data to the client already you might as well have it sitting ready to go in the DOM, rather than rendering it on expansion.
@@PeerReyndersI guess I was thinking that all the JS would be eagerly loaded so only the landing page would be SSRd. Islands/ClientComponents + Partials/ServerComponents would minimize subsequent cold start costs so no need for subsequent SSR/hydration. But obviously Ryan thinks subsequent SSR/hydration still is needed
@@OuterProduct351 Perhaps I'm misunderstanding but while applications have a starting screen, web solutions represent their core state via the URL which itself is a route and with SSR any route can be rendered by the server at the start of a new session.
So if you let authentication persist across sessions the HTML will vary by URL. And even if the JS bundle is cached it still has to be parsed and evaluated when a new session is started.
As Addy Osmani has pointed out since his first
The Cost of JavaScript
in 2017, JS has cost beyond download, i.e. parse and eval.
love it.. "musings" 5 1/2 hr video LOL
Was gonna say this is iron man level ability to discuss
Time stamps pleasee 😢