What's up with those Hydration IDs?

[@chris_kouts]

Ryan we need video chapters please!!! You are the goat!🐐

[@zombiefacesupreme]

I'm working on it, but I had a busier Saturday than I planned and I won't be back home until late tonight. Hopefully, I'll have it done by tomorrow afternoon. Sorry, it takes at least 3-4 hours to do a decent job. I always try my best to get it done within 48 hours. If you feel like you could do it faster, feel free to volunteer for next week. 🙂

[@zombiefacesupreme]

[0:00:00] Preamble [0:05:00] The Fastify SSR Benchmark [0:11:00] How It Works & What Went Wrong [0:25:00] toFixed(2) - Small Changes/Big Differences [0:36:45] What Happens If We Turn Off Hydration? [0:43:00] What Are We Actually Testing? [0:50:30] Why Does Solid Even Have Hydration IDs? [0:57:00] 5 Places SolidJS Is Not The Best [1:02:30] Fine-Grained Hydration: Introduction [1:08:00] FGH: "In Solid... myDiv is a div" [1:21:30] FGH: Async Uncertainty & Hierarchical IDs [1:29:30] FGH: Automatic Data Serialization [1:46:15] FGH: What If A div Wasn't a div Anymore? [1:56:00] FGH: Trade-Offs (ref & children Introspection) [2:03:45] FGH: Conclusion (This Comes At A Cost) [2:07:30] Solid 2.0 Benchmarks & New Ideas [2:12:15] Alternate Reality - Props as Accessors [2:25:45] How to Debug Solid When Hydration Fails [2:45:00] Run (Throw) Once Suspense Revisited [3:05:45] Exploring New Primitives: createAsync & Async Iterables [3:16:30] ENP: Adding createProjection To The Mix [3:26:00] ENP: Keyed Approaches to Reactive Arrays [3:32:30] ENP: The Repeat Component [3:40:00] ENP: Conclusion [3:48:45] This Week in JavaScript: Solid News [3:52:00] TWiJ: Ryan Joins Sentry & SolidHack 2024 [3:58:00] TWiJ: Tanner Linsley on TanStack Start [4:02:00] TWiJ: _princesseuh on Library Size [4:04:00] TWiJ: Cheng Lou on Midjourney's Website [4:06:30] TWiJ: Astro on Preact Signals [4:13:45] TWiJ: ImSh4yy on Auth in JS community [4:22:15] TWiJ: Reacting to Jose Valim's Video - Intro [4:27:00] TWiJ: RtJVV - Single Flight Mutations [4:34:00] TWiJ: RtJVV - Is There A Ceiling Here? [4:40:45] TWiJ: RtJVV - Not Using Prescribed Patterns [4:54:00] TWiJ: RtJVV - Conclusion [5:02:45] TWiJ: Web Components & SSR [5:13:45] TWiJ: Shell Pages & Preloads (Excalidraw!) [5:23:30] TWiJ: Discussing Framework Features [5:29:30] TWiJ: "Just JavaScript" & Conclusion Congratulations on the new gig, Ryan! Sentry seems like it'll be a great fit. I'm really looking forward to SolidHack 2024!

[@zhihengzhang6288]

hi ryan is it not possible to do 1080p ? it is a pain wathing this :(

[@heshamayad396]

the stream's quality is messing up the text, it's headache inducing.

[@simonhartley9158]

I was interested in the size claims and so I decided to compare similar no build setups for Preact and Alpine. For Preact I followed their No-Build Workflows instructions which includes Preact with Hooks, HTM (not HTMX) and Signals and it uses an import map. I normalised everything to use gz compression and used Chrome to measure data actually transferred. For Alpine 16.1K was transferred as a single request. For the Preact solution, 15K was transferred and was transferred as a waterfall of 3 then 5 then 2 then 1 requests. Could the Preact solution be optimised, sure, but out the box, that's what you get.

[@ryansolid]

@simonhartley9158 yeah and alpine expects it this way and packages that while I expect preact is just ESM. That being said add the build, drop htm, and Alpine stays the same(last i checked), but Preact gets significantly smaller depending on what you use. No build is great for teaching/prototyping but otherwise kind of just limiting the quality of app you deliver to your users.

[@simonhartley9158]

I'm not a modern JS developer, so my instinct is always to dip my toes into this stuff. It seems that if Preact is going to offer this as an option, then they should release a proper asset for it. I tried building Astro Records (normal version uses Preact) using HTMX and Alpine and streaming HTML. The Lighthouse scores are almost identical. What I found interesting was that I had to change some parts of the page to also be client rendered, since otherwise I'd get layout shift from doing a server render and then having to re-layout when something large above it client rendered. By making things render together, I avoided that. To change from server to client was just adding a couple of attributes. I did find this peculiarity went away in a more recent version of Chrome.

[@ryansolid]

@@simonhartley9158 Small demos.. differences in like 20kb js are not going to really make a huge difference. Nor is the JS execution time going to be significantly different. Most of my reason for bringing it up in the stream is that No Build, Alpine side of things tends to act like their output is somehow lighter than these heavy weight frameworks. But it isn't.

[@SilencerWeb]

Please, 1080p quality

[@dzienisz]

Brother just buy a new computer XD