Hydration & New Frameworks Like Qwik

Welcome to Syntax on this Monday, hasty treat. We're gonna be talking about quick And what hydration is within web frameworks and why it matters and how that relates to new modern frameworks And one's coming out every single day. My name is Scott Talinski. I'm a developer from Denver. And with me as always is Wes Bos.

Hey, everybody. I am stoked to hear about Quick. It's funny. Sometimes, like, sometimes we'll, like, spearhead an episode, And this is the one that Scott has spearheaded. And then I'd like before the episode, I was like, so what is quick? And he's like, well, I'm like, hold on. This is the podcast. Don't let's not do it.

Wait a second.

Maybe, maybe we should hash this out on air.

We are also going to it. Hash out 2 amazing companies here that are sponsoring this episode, Sanity and Sentry. Sentry, being the perfect place to see all of it. Your errors and exceptions happen in your website in a way that allows you to easily and completely take control over the situation.

You know you know, finding bugs is hard enough already, but fixing bugs is hard, and assigning bugs is hard, and making sure they they were fixed The next release, all that stuff isn't a lot of fun, and so that's why it really helps to have a wonderful tool like Sentry out there that can Really help you grapple with all of that. Give that to you in a big table and give you all the features that you know and want where you can it. Attach them quickly to users' releases.

You can say, oh, this, this this bug is actually kind of a big deal. Let me attach this to a GitHub issue, And that GitHub issue can then be tracked separately and connected to this issue. Then maybe this bug can be assigned to a specific release and said, hey. This was fixed in version 5.4.

You push up that new version, and you can click the check to say, hey. This was fixed. And then you can be very satisfied as that bug never ever shows its head ever again because we we all know that bugs don't come back once you fix them. Right? Right, folks. We fixed them right the first time. So Sentry at century.i0.

If you sign up today using the coupon code tasty treats, all lowercase and all one word, you'll get 2 months for free. Thank you so much to Century. This is a product that I use every single day. Let's talk about Sanity. Sanity has this idea of,

We've talked about them a 1000000 times, and you probably know that they are a place to put the content for your website or for your app or something like that. They have this idea of the content lake, which I I love. That's such a great way, a great way to put it because, at the end of the day, Sanity is where your content goes, and it lives in the lake. And how do you get that out? Well, you can get it out.

They have this thing called datasets, which is you can have multiple sort of databases to make some content private and some content public. You can query it with Grok, which is their query language. Honestly, if you get anything out of this ad read, go check out what Grok is. It's their own query language that is Super powerful. And at first, I was like, well, what's the difference between that and GraphQL? It's much more powerful than GraphQL, and you can get things much more fine grain.

They do also do have an entire GraphQL API, if that's what you'd prefer, to pull your data into your app or to your website.

And then they have an asset pipeline, which is you put your images in the pipe pipeline. You can transform them. You can resize them. You can extract the the data if you want. You know? Like, we've all heard these horror stories of somebody uploading a iPhone photo, and that has. I was watching the documentary on, who's the John McAfee. Have you watched that documentary? I haven't seen that one, but I saw another one, and I know the whole story. Like, how they found him was be a like a journalist took a photo with an iPhone, And then they just posted that photo up raw on device,

and it has

had all the exif data in it. Yeah.

So it. You could just don't do that. Use San Jose. Strip it.

Strip it out. Just don't do that. They all go through a, global CDN, Which means, that they are distributed around the world to make them nice and fast. So check it out. Sanity.i0forward/ syntax. That will get you double the free usage tier. Thank you, Sanity, for sponsoring. Cool. So,

Quick. Quick is a new web framework that many people have been talking about lately. I it. I think sometimes it's good in these hasty treats to, like, focus on some projects like this that are, you know, cutting edge or gaining traction or just Existing that are taking a different approach to things. Like, you know, we had React as being, you know, the big big boy for a long time, the big dog.

We've been running with the big dog for a little bit here, but, you know, when when these new frameworks come out, for them to do something novel or something interesting, something to gain people's attention. They have to take a slightly different approach in many ways. So, You know, QUIC is the latest of these, and, QUIC comes from, Mishko, Havery.

Mishko, I apologize if I mispronounced your last name here, but, he's the inventor of Angular, so he has a pedigree in front end frameworks.

And this is a new framework that is JSX based.

So they have very, very, bluntly on their website. If you know React, you know quick because it uses hooks. It uses JSX. It has It's a very similar function component base for creating components, which more and more nowadays, for better or for worse, you know, I'm gonna save my thoughts on that right now, but, it seems like JSX is definitely turning into one of those, Not like a standard, but it's definitely a format that a lot of people are choosing to use, whether we've seen that with Fresh is the Deno based. Yeah. Yeah. JSX based framework that's like island architecture.

I know a lot of, you know, Astro uses a JSX like syntax.

React, obviously, Preact. There there's a ton of JSX based frameworks out there. And that's that's ideal that's ideal

because

CSX is ideal if you like it. Yeah. That's true.

Because I I'm not a huge fan. So but yeah. Well, that's ideal because that's why

JSX is its own project or it's its own spec, I guess, in that instead of being A part of React. It's its own thing so that it can be used on other things. I think there's a fair amount of people who probably might not even realize that. Yeah. JSX

is not a part of React, and it is its own thing.

Rick was just using JSX because so I I don't know too many people that are writing They react to code without JSX, but you can. You know, it's a thing you can do. Yeah. There was a for a while, we had people using, like, h or something. What was that? Yeah. That would that would look a function. Gnarly. Because you you didn't need to transform for it. You didn't need to bundle it all. It's just a function calling it. So that was, like, the thing. I I personally like, I'm so deep into compilers for the web that yeah. I I don't really mind having a compiler. So to me, that's not, Like a huge, huge thing, and now the compilers are very fast. Ever since ES build and showed up, we don't have to worry about, like, compiler speed being, like, a huge thing anymore. So It's it's not a huge concern for me. Either way, QUIC is JSX based. It's SSR by default, so you get SSR by default. That's great. It's what does SSR mean? SSR, server side rendered, which is basically the the node server renders your HTML from JavaScript the same way that a server would take PHP code and ship out HTML to the user.

So the user's getting HTML at the end of the day, HTML, JavaScript, and CSS, And it it's coming the the the HTML is generated from your template code that is in JavaScript, And in this case, JSX.

It is Vite based, so it uses Vite behind the scenes, which Vite really you know, Vite showed up, And Veet just kinda said, you know what that market share that Webpack has? I'm just gonna go ahead and eat that lunch. I'm just gonna go ahead and eat all of that.

It. It's it says it looks at it looks at a webpack launch, and it says, give me that. It just goes ahead and takes it. So, Vite has now kind of taken over everything, and I gotta Yeah. I love it because I I do love Veed. It's very fast. It's very lovely, and the tooling is great.

It uses Veedest and Playwright for testing, And it is a framework reimagined for, quote, unquote, the edge.

So I think What I wanted to talk a little bit about in this episode beyond like, I don't want this to just be like, hey. This is quick. Check it out.

I I I think I wanna talk a little bit about, like, hydration and how, hydration is a thing in front end frameworks, especially server side rendered frameworks.

So in the HTML and JavaScript framework world, many times what you had was a client side JavaScript based app in the past. When that client side JavaScript Loads up, basically, just JavaScript to render your website on the client.

That's it.

No server side JavaScript whatsoever.

Then everybody started saying, well, you know, we're kinda missing a lot of that server side speed. Right? The node servers are really fast at generating HTML.

It. There are that HTML's really important for things like accessibility or for, people who run their sites without JavaScript Or for SEO even having, that available if the bots aren't able to run your client side JavaScript, At least has this HTML to back it up. Right? And that HTML is easily parsable.

So we got server side, SSR based apps, which we just talked about a bit ago.

And with server side based apps that are coming from JavaScript Frameworks, you you run into the issue of, okay. We have the server side based app. We're pushing out the client as HTML, and then we have the client side app. And now what we need to do is kind of reconcile the client side app with the server side app, and that's a process that's frequently referred to as hydration Where you could you could think of it as the server side app is a sponge, and the client side app is the water, And you're hydrating that sponge with the client side app. So you're kind of combining the client side app with the server side app where you're you're combining your component a tree with the HTML that is existing.

I I guess the the a definition I found, hydration is adding client side JavaScript and application stage to server rendered HTML where you have to you have to basically reconcile the application state, the event handlers. Right? Because event handlers are often in front end frameworks.

You're you're typically writing all that stuff in React, so or Svelte or Vue or whatever, And then you also have the component tree. So how does that component tree relate to the HTML? And that component tree step and hydration is frequently where you get this l, Div is not, cannot be found as the same as div error that you get in React when working with server side React code, and the client side JS and the server side JS it. Match up. So, basically, what you're doing is having to combine the JavaScript that's coming in client side with the server side rendered HTML.

And quick what Quick says here is Quick says hydration stinks.

Hydration is slow.

It reduces the time to interactive because what you're having to do before the site is interactive at all is you're having to hydrate the site. So, therefore, you're having to wait for that client side JavaScript to then load. Even though we're getting that initial first paint as HTML, We can't use it yet because the client side code that's doing all of the functionality hasn't been rehydrated into the app.

So Quick's approach is to not do hydration at all.

Their whole approach is to say, we wanna eliminate hydration by doing, what do they call it? They call it Resumable.

Resumable.

Yeah. They're resuming things. So they They serialize the application state and framework state into HTML upon rendering the application.

So, basically, they eliminate the need to execute any code to restore the page's interactivity.

So with hydration, you have to wait until that client side code has initialized before you can do anything with it. Where with QUIC, it. The site is usable from the jump. The server side code is usable, and it doesn't have to reinstantiate all of those things, which their their big whole thing is that it makes the site, a much faster time to interact. I don't I don't get

it. A hydration, it needs to download the JavaScript and then, like, like, reparse the site so that you can do things like Click handlers, but this just says it doesn't do that.

Like, how does it how does it work? I don't get it. It serializes

the application state.

So what it's not having to do is not having to It's not having to re reattach essentially client side framework into the server side HTML.

It's not having to then say, alright. We have like, you With a with the hydration approach, you're having to, like, essentially run the client side app and the server side app As almost 2 separate apps. The server side app runs, it spits out something, then the client side app kinda sits on top of that. This is more of like The thing that we're giving you is an interactive JavaScript attached HTML page from the jump without having to, Yeah. Without having to, like, rebuild it all, essentially.

So it's just ship it's like kind of like Angular one was where it ships HTML and some JavaScript on top of that instead of HTML, Some JavaScript to rerender all of that HTML and the JavaScript to handle. Okay. So it's it's skipping the whole Client

side rendering thing. Is that is that right? Like, does more need to happen on the server now? I I would imagine if it's saying it has to it. The entire I would imagine that means more has to happen on the server, but servers are fast, and they're good at this kind of stuff. So, You know, typically, that I think that's a good thing. You know, the client gets less JavaScript. The client gets less things they have to, load themselves, But they also get, like I said, that faster time to interactive because you don't have to wait for the client side to to to dehydrate.

You also get, like, baked in lazy loading, so you don't have to worry about or think about, like, a chunking or lazy loading your code.

So it says reduced rendering upon user interaction.

QUIC is surgical about which components it rerenders. This is done through reactivity.

It allows QUIC to minimize the rendering code, so it's not rerendering your entire component tree like React is, which to me, that was always a thing I didn't like very much.

Yeah. And it says code once. You can use the same code for your client and your server. So you know what? I I think it's really interesting.

There's also, like, this really interesting optimizer tool they have. They have something called quick optimizer that generates, JavaScript, based on real user metrics to understand the optimal way to bundle commonly used modules so that there's, like, some Analyzing going on of which modules are commonly used so that way it can bundle them efficiently.

And what I I think is really It's really interesting here is that the entire approach behind QUIC is there's a blog post that they talk about this where it says don't blame the developer for what the framework did. And that kind of, that kind of really goes along with a lot of how I've been feeling about some front end frameworks lately where it's like, you know what? I I don't want to have to optimize the framework. The framework should optimize itself, and I should just write the code, And the coach should should be fast enough, you know, unless I'm doing something stupid like an infinite loop. Yeah. I shouldn't I shouldn't be worrying about optimizing the framework. I shouldn't be worrying about memoizing a single thing. Yeah. I never want to have to use the word memoize in my friend's office. Say it. Yeah. Yeah.

Use callback. No. How about use, you how about you call me back, some other time, and I'm not gonna pick up the phone? How about how about that?

I'm just looking at the middleware on QUIC, and this is another thing we've talked about this is that on our Edge show is that a lot of these new frameworks are gonna be Edge first, and it looks kind of similar to Remix is that they have middleware for rendering it out. So they have one for Cloudflare Pages, which is Edge functions, Netlify Edge, and obviously a Node one as well. I'm imagining that we'll see Deno, BUN,

Yeah. All the other edge providers out there eventually as well. It's kinda neat. How's felt works too, and I love that. Right? Yeah. You're you're separating where you're deploying or how you're deploying the the code from the code itself. Right? I I just wanna throw in that adapter, that middleware, whatever to say. Alright. Now you can run-in this context or with this JavaScript runtime.

And, you know, that to me is is great. Those are free wins. So So there's a lot of really neat stuff here. I highly recommend checking out. There's a bunch of quick specific things, like they have their own life cycle hooks, like use mountain, Use cleanup and use client effect. There there's a lot. Like, we did we didn't really talk about the quick specific, code in this episode. I I kinda wanted to have a little bit more about, Yeah. You know, what what sets it apart? Because, you know, the syntax for these things at the end of the day is just pushing pushing pixels around in terms of, like, what's different if you do the same things. Yeah. You can do most of the same stuff on any of these things.

One thing I didn't see in here at all is I didn't see any sort of, like, a server, data loading or data actions type of stuff, which if if you know like, I've been using the SvelteKit, Process and Remix. I think SvelteKit Remix are doing such a good job of How how do you interact with the server, in terms of using HTML fundamentals to send data To the server to the server back and forth from server to client. A form or something like that? Yes. Submitting a form, grabbing data from the database, Whatever. I don't see anything about that in here, so I'm pretty sure it's not doing that. If I if I'm wrong about that, please reach out to me. But I you know, I Honestly, I've talked through these docs, and I couldn't find anything about that, that picture of it all. But there is,

if you go to routing And then retrieving data. So they have, like, a serverless function, to do a handler.

So it's very similar To a lot of these frameworks that do file based routing is that you

accept Where do you see that?

In the docs. On the quick docs, routing and then retrieving data. So you can you have a a request handler. That's the incoming.

And then they show how to use on get it. Inside of a component on the

in the, I don't wanna say client side now, but on the in the JSX could still call it. Call the client. Okay. You know, the client is, I think, consuming it. Right? I mean, it doesn't client doesn't just always refer to the browser.

Yeah. So there's an on get Function that needs to be exported from your endpoint, and that will asynchronously run. And inside of there, you can do database calls.

And then inside of your actual

yeah. That makes sense. Here's what I'm missing. Here's what I was missing. So I quick Quick is to Svelte as SvelteKit is to Quick City.

So what you're seeing is Quick City, which is Quick City.

Quick City is a meta framework for quick. So, basically, you think Next. Js to React, SvelteKit to Svelte, Quick city to quick or remix to react or, you know,

that's neat. And that's probably what most people will be using because you want routing, like, city data loading and everything like that.

Yeah. It has right. It has data loading. It has file system based routing, it. Authoring content, static site generation, meta stuff. So Quick's got it all, folks. I'm gonna delete the part That I said missing from quick in our notes here, and I'm gonna say missing from quick. Nothing. It's not missing anything. No. It looks it looks honestly great, and, It it's one of those things where I I I I totally don't like that it's in JSX, but I'm I'm sure I'm the minority opinion of that.

It. I think this is a new, a new thing in in frameworks that you're going to see more often. Now do we need a whole new framework That's React like just to do that one trick. Right? Is there is there something that could come along in in in React To do that trick to fix hydration in a different way or Svelte or Nuxt or whatever, can those frameworks themselves fix that without Having to completely rewrite the framework from scratch or honestly, I'm not smart enough to know the answer to that. But every time I see something like this that is like, oh, it's just like React Or it's just like Next. Js, but slightly different. I think, why can't Next. Js take some of those tools or fix those problems themselves, in a different way. I I don't know if you saw this because that was a whole thing with Svelte and React is is, React is now looking into doing a compiler. Did you see that? No.

Wow. What? Like, what for a compiler to like Svelte is that compiles to JavaScript.

Yeah. Because they They they basically, I think, are admitting now that, the memoization stuff is a a big deal. Let's see. Don't quote And that I swear I saw a discussion about this the other day, but the React RFCs

are there's a whole lot of stuff in here. That's there's a lot of stuff in React like that.

And, yeah, 2 years later, we don't have any of it. So take it with a grain of salt. Remember

React suspense? Yeah.

Cool.

Well, that was a quick hasty treat.

I think it's really cool to see all of these different frameworks Sort of coming out where it's like you got routing.

You've got your handler. We're using basics. We're using the platform as we just did a show about, And then it has your prefetching in your head and your middlewares and all that, so pretty pretty cool. I think we're on, like, a a verge of, Like an like a next gen framework thing

right now, and I think we've probably said that before. But I think people are are saying that That hydration is a big enough thing where you could consider, like, the next gen of frameworks to the to re I you know, there's conference talks being authored to say, alright. We have these hydration based frameworks, and now we're past that now with these new ones. But at the end of the day, I think most of those conference talks are coming from people who are working on frameworks that don't have hydration

or you know you know what I mean?

So who knows what what the next gen of the stuff is or who knows what these these, you it. You know, the end result would be I think the thing that I'm looking forward to the most is the fact that most of these frameworks and meta frameworks are all having big browser based, conventions, JavaScript fundamentals coming in here, so we're not just hitting everything with a it. Fetch a custom fetch on a JavaScript thing. We're actually using forms. We're actually using HTTP requests and doing things the way that the browser likes to be doing things.

So shout out to, fundamentals.

Beautiful. Alright. Thanks everybody for tuning in. We'll catch you on Wednesday.

It. Peace. Peace.

Head on over to syntax.fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player Or drop a review if you like this show.