Dan Shappir takes the lead for this week's panelist episode as he talks about hydration. Hydration is the technique of using client-side JavaScript to enhance server-rendered HTML with application state and interaction. In the context of Web performance, he explains why it is regarded as such an issue and its impact.

The second part of this episode is reviewing various ways in which modern frameworks, such as Qwik, Astro, Remix, and NextJS are trying to alleviate the impact of hydration:

Hey there and welcome back to another episode of JavaScript Jabber. This week on our panel we have AJ O'Neill.

 

Yo, yo, yo, coming at you live from a sunny place in Utah. cold.

 

it is sunny is cold cold uh... steve edwards

 

Hello from a sunny and cold place in Oregon.

 

Dan Shapir

 

Hi, I'm a warmish and sunny Tel Aviv.

 

I'm Charles Max Wood from Top End Devs, and this week we're going to be talking about hydration. So take your HTML, just add water, right?

 

Mm.

 

Exactly. Yeah, because that's what HTML always needed. Water. Lots and lots

 

that's

 

of water.

 

right

 

hydration.

 

alright now before

 

It's

 

you

 

got

 

ruin

 

what

 

your computer

 

HTML needs.

 

Yeah.

 

Ha ha ha.

 

It's got electrolytes.

 

Yeah.

 

Sure. So Dan, you're the one that proposed this topic and have been looking into it. Do you wanna just kind of give us a rundown about hydration? Cause I think we all have in our heads, kind of a mental picture of it, you know, the JavaScript loads and it does magic and stuff works. Ha ha. And that's it. I hope you enjoyed this video.

 

Yeah.

 

I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed

 

Yeah,

 

it.

 

more or less, I mean, that's what JavaScript is, magic. Yeah, this is an interesting topic and one that's near and dear to my heart because of the performance implications that it has. And as you guys all know, I'm all about web performance. This is actually a topic of a talk that I'm proposing to various conferences. So it's something that I've researched both as part of my day job also for the purpose of a conference talk. And it's also something that's really kind of in the headlines because all of a sudden we've got a lot of frameworks coming out, like they're coming out of the woodwork literally. And it seems that one of the main motivations for all of these frameworks coming into existence and the differences between them have to do with this whole thing, this whole concept of hydration. sense to kind of start by talking about what hydration actually is and why it even exists. And by the way, this is not the first time we're covering this topic. We've discussed it in the past with Mishko Hevery when he came over to talk about Qwik. We also touched on it when we spoke with Fred about astro. And also I talked about it in the past, you know, like a couple of years ago in an episode on SSR. So it does tend to come up. is just an indication of how important and central this issue is. But again, from speaking with a lot of developers, I think that many of them don't fully understand what this is despite all of this coverage. So what is hydration? Hydration is something that came into being because of all the JavaScript frameworks that we're using. that were created to implement single-page applications or SPAs. Before we had these, hydration wasn't a thing. So in the world of, let's say, PHP or ASP.NET or JSP or whatever, and jQuery on the front end, if that, we did this concept of hydration did not exist at all. But then, long came Angular and all the rest. switched over to using these JavaScript frameworks to render our front-ends and do it as a single-page application. And initially it was mostly done with client-side rendering, which means that the HTML that you got from the server was effectively an empty page. It was an empty body that all it did was these JavaScript files arrived at the client, they would perform various Ajax requests in order to get the relevant data, and then they would construct the HTML totally on the client side, as I said, it's what's called CSR or client side rendering. And it kind of worked, but it had several issues. One issue is always great for SEO. Initially, search engines had a really significant problem dealing with that. Then they kind of became more sophisticated. For example, Google uses an evergreen chromium-based engine inside of it. And as a result, it can actually deal quite well with these client-side rendered pages. But that's not... We spoke about this at length when we had proof. I forget his name.

 

Hit it out, you can do it.

 

Yeah, we'll probably want to edit this. Split, his last

 

Mm-hmm

 

name is Martin Split.

 

Martin split? Yeah.

 

Exactly, Martin Split from Google. We had him on this double episode, where we talked at length about this.

 

I

 

And

 

remember

 

he,

 

I specifically asked him about this because it was of interest.

 

yeah, exactly. Because it's something that a lot of JavaScript developers or web developers have misconceptions about, that search engines really need can't really handle client side rendering. Well, at least Google can. Maybe some of the other search engines can't. But, you know, Google is usually the most important one, at least for now, until chat GPT maybe replaces it or something like that. But for now, it's still the top dog. But it's still, as Martin explained to us, it can still be beneficial. if you had some content and links in the HTML itself. So, because for example, it enables the search engine to find stuff faster. It doesn't need to run the JavaScript on the client side just so that it could know about the other pages in your website, for example. And again, some other search engines have problems dealing with it. So that's one problem, but the bigger problem is performance. Because basically, If you have content in the HTML, the content is rendered up front. You have an image tag in the HTML. As soon as that portion of the HTML arrives, it doesn't even need to wait for the entire page. It immediately can start downloading the image and then display that image as soon as that image finishes downloading. On the other hand, if you use client-side rendering, you need to download the entire HTML, download the JavaScript, parse the JavaScript, do the Ajax, parse the data, and then build the DOM structure for the HTML, and only then would the image even start to download. So obviously, the initial loading time of client-side reddit applications was much, much worse than if you delivered content in the HTML upfront. Now, this may not matter in some cases. I guess, for example, if you're building some sort of or for let's say you're using Grafana, for example, then

 

Mm-hmm.

 

you care less about that sort of thing, but for most websites, you definitely care about that. If you're building, let's say, an online store, you want your products to appear as quickly as possible. You don't want to wait for all this thing to take place before you can even see the product. And moreover, if your JavaScript breaks or fails for some reason, then with client-side rendering, You're stuck with that blank empty page, which is obviously not a great user experience.

 

So I would offer a litmus test for this, which is people click to get to that resource from other pages or from search. And it isn't a resource that people are in for hours at a time. So basically it's not a web app, it is a web site or a web page or something that has content that is predominantly static and the dynamic parts like the price goes on sale or a new comment is added to the page are not that they're not important, but they're not the bulk of the content. They are trivial by comparison in terms of the value or the cost of getting them versus the cost of rendering them. So, that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point.

 

I tend to agree, although the term static might be misconstrued, because for example, it might be a news website and your news updates every minute or you know, but it's still something that you get to from search and you still want to have fast low time. So it's, but I do totally agree with your presentation. You're presenting it as more of a web page or website than a web app. In any event, the first framework that proposed a solution for this problem, so one option would have been to just give up on JavaScript frameworks, but JavaScript developers didn't want to do that. So the first JavaScript framework that came up with a solution for this problem was React, and the solution that React came up with was server-side rendering, which basically means that you can the same React code on the server side and the client side. And in fact, you run it first on the server side, where instead of constructing a DOM, it constructs effectively an HTML string, and then sends that string down as the response to the initial request. So basically, you kind of get the theoretically the best of both worlds. display is done on the server side and you might even cache it or do something known as static site generation which means that you might even run that react code at build time rather than at runtime and then have that HTML ready from the get go from for all the visitors but at the end of the day you still have all that react code also on the client side because you have not switched back to using multi-page applications, you're still using it as a single page application, which means that the navigation to the second page and the third page within that website happened client side rather than server side. So the display of the first page is done on server side, either at runtime or at build time, but then all subsequent navigations happen on the client side, assuming everything worked properly. But that raises an interesting situation. question because, okay, I can run the React code, which generates a VDOM, we discussed this at length in those episodes about how React works, and I can take that VDOM and instead of using that VDOM to update the actual DOM, I can serialize that VDOM into an HTML string and send it over the wire. And then I've got the HTML representation of the initial view of that website or web page, but it's like just the HTML. There's no logic associated with it. There's no interactivity associated with it beside the interactivity that's kind of built into the HTML. So links will work. Form submit button that has the appropriate action in the HTML would work. But if there's like a menu, work because the JavaScript that operates the menu, it's not there. So effectively what I've got is like a picture of the site, almost, rather or the page, rather than the actual functioning page. In order to have the page actually work, I need to have all the framework and application code set up on the client side. side rather than on the server side. So far so good. And...

 

Yeah, and that's what quick is purporting

 

Thank you. Bye.

 

to do is that they set up the event handler. They have a global event handler that has some sort of data in the DOM associated with it that when you, everything can be rendered, but then they kind of simplify the state management and that they don't have to fetch the stuff that the event is tied to and all the state that might be related to that until the event actually bubbles up.

 

Yes, but again, but you're kind of jumping the gun.

 

Okay.

 

But you're definitely correct. We're jumping the gun because when I'm going to talk about the various ways in which modern frameworks strive to deal or overcome or circumvent hydration, and what you described or what Quick uses, which is called resumability, is a way to kind of replace hydration with something else, which better and we'll get to that a little bit later on. But the way that React dealt with it is completely not that way. What React did or does is basically say the following. In order to be a truly interactive React application, I need the HTML but I also need the the VDOM that represents that HTML and all the that are associated with this VDOM. Now, I created all this stuff on the server, but then I basically just serialized the data into the HTML and threw all this data away. So I don't have all this application state that I need. So the way that I'm going to get it is basically by recreating it. So I'm going to rerun all the code Either again either at runtime or at build time doesn't really matter But I'm gonna run it at runtime on the client side in order to recreate the exact same state that I had on the server and That's and then when I recreated that state I can match it up with the HTML that I have and I'm good to go and This is called read or hydration or rehydration because I'm I'm like taking this freeze-dried thing, this HTML, which

 

Mm-hmm.

 

was kind of like I said, a picture of a page, and I'm giving it interactivity or functionality by filling in all these data structures in memory that are associated with it from, you know, from within or from behind. Now in order to be able to do that, I need to have, for example, all the data that was used. So for example, if I'm displaying some data from a database, on the server side, I did a database query, I got all this data. I also now need all this data on the client side in order to reproduce the exact same UI that I already have. So there are two ways really in which I can go about it. One way which is not popular and I'm not aware of any framework doing it, but it's still doable is effectively I can make all these queries again. I can do Ajax calls from the client side, get this data again from the database. The problem with that is that I I kind of have to wait for this round trip. Also, maybe the data in the database was slightly updated. So maybe the data that I'll get is slightly different. And then I'll get a divergence. I'll get a situation in which I'm trying to hydrate, but with slightly different data. And I can run into all sorts of problems. So a more popular approach is to basically take all this data that I need and embed it within the HTML, let's say, as JSON data. Indeed, if you look at, let's say, pages built using Next.js, I assume the same is true for NUC, Steve, correct me if I'm wrong, and you do a view source, you will see this kind of data duplication, that the same data is effectively presented both in the HTML itself, and again, in some sort of JSON string embedded within that HTML. And on the client side, what they do is they take the data directly HTML and then use it as an input for that same React code to regenerate the exact same VDOM. But doing it this way, at least, I know that I'm using the exact same data and I don't need to download it again. I get it directly out of the HTML. The cost, of course, is that the size of my HTML is effectively kind of doubled because I have the data in that HTML twice. Another problem, of course, is that the hydration doesn't take place until I actually download the JavaScript. And I literally need to download all the JavaScript because I'm running everything again. So let's say I use Moment.js in order to do some sort of date calculations or whatever. I need to download Moment.js down to the client. Everything that I ran on the server, I need to run on the client as well. need to download everything, rerun everything, and that is

 

Thank you.

 

obviously

 

Thank you. 

 

a performance problem. It's potentially even more of a performance problem because most frameworks, at least the way that they used to work, is that they did this reconstruction, this hydration process in one go, in one shot. So they basically called a hydrate function which ran and ran it basically blocked the main thread. Because as we all know, JavaScript runs on the main thread and while JavaScript is running, the main thread is blocked and will not respond to user interactions. So let's think about what the user experience actually turns out to be in this sort of a scenario. The user sees the user interface really quickly. And then obviously, the user tries to interact with it. Now, If the connection is quick and the network and the device is quick enough and the user maybe thinks a little bit about what they want to do because they've never been at this page before, so it takes them a while to figure out what's what and where they want to click, then hopefully by the time that they actually click on something, this whole process of hydration will have finished and everything will be great. But suppose that's not the case. either the network is kind of slow or it's a ton of JavaScript which is often the case and the device is kind of slow because it's a mobile device so it takes a while to run all this JavaScript or the user is maybe familiar with this website. They've been here before and so they know where they want to click so they try to click it and then that's it. There is a is somewhere between a performance problem and a usability problem. And it's really kind of interesting to think about how it impacts performance in the way that we currently mostly measure it, which is using Core Web Vitals. Because unfortunately, the fact that it can result in a really bad user experience is not always reflected in the Core Web Vitals score. But before I go into that, are there any thoughts or comments? comments about what I've said so far. Okay, everybody seems to be on board, so that's nice. So if you remember, there are three core web vitals that kind of measure performance. Currently, they are largest contentful paint, which measures how quickly something is drawn on the screen. Well, if you think about it with SSR, that one's supposed to be really good because you get the visual content really quickly. You know, the fact that you can't really interact with it yet is not measured by LCP. how quickly it's shown. So if you do SSR and you do it correctly, you'll probably get pretty good LCP. You know, maybe not, maybe all downloading all this JavaScript conflicts with downloading the visual resources, so you may need to kind of work on your prioritization. You know what is more important than what, but still LCP can be good, especially again if you're maybe you're caching that HTML in a CDN or something like that. CLS, which measures visual stability, is again, wholly not impacted by this whole thing. You might have good CLS, you might have bad CLS, but that has more generally to do with how you arrange your fonts and style sheets and whatnot. It doesn't really usually have to do so much with a JavaScript. The one that we expect to be impacted is the third one, which measures interactivity, and measurement is called first-in-put delay or FID and it measures the time from the first interaction, just the first interaction, until the browser is able to process that interaction. So from when you let's say clicked on a button until when the browser is able to execute the on-click handler for that button. That's what is measured by FID. to be shorter than 50 milliseconds. Now that one you expect to be impacted and often it is but the problem with this measurement is that it's kind of broken. It's a bad metric. Google came up with with core vitals, they came up with two good metrics and with one metric that is unfortunately not that good which is why they're actually looking to replace this one. about this with the Google Performance Team, if you remember, they were on their show and they talked about how they hopefully intend to replace FID with INP or interaction to next paint. But let's start with first of all why FID doesn't necessarily measure this so well. First of all, if in fact you do click on the button while the hydration is running, then indeed you'll probably get because if let's say the hydration takes 300 milliseconds and a good FID is under 50 milliseconds then obviously 300 is more than 50 and you'll get a bad score on that metric. But what happens if you actually click that button before the JavaScript even finishes downloading before the hydration even starts executing? You just have a button that's not connected to everything to anything. Do you know how quickly a button that reacts to a click. really,

 

It's

 

really

 

really

 

very

 

quickly,

 

fast.

 

fast.

 

really, really fast,

 

Yeah.

 

because it literally does nothing. You can click this button for, you know, as many times as you want, nothing will happen. So in fact, the site might be even slower, because you've got so much JavaScript that it's taking a long time to download, and the user is getting really frustrated because they're clicking stuff all over your website, nothing happens, but you're getting excellent FID metrics. So that's kind of the problem that. And that's what I'm hoping INP will resolve, because INP has two main differences. First of all, it doesn't just measure the first interaction, it measures every interaction on the page. That's the input. It kind of looks at the slowest one, but it basically picks the slowest one out of all the interactions. So assuming you've got a long hydration time, there's a good probability that the user will try to interact with the page during the even if it's not the first interaction. And the second is that NINP doesn't just measure the time until the browser can process the event. It actually measures the time until something visual actually happens in response to that button press or whatever. So if nothing happens, then it doesn't really count as an interaction. So hopefully, when Google moves over ID to INP, the performance metrics, scores for websites that use frameworks will reflect that by getting a lot worse, which is kind of sad because they're already pretty bad.

 

Ha ha ha!

 

So yeah, another talk that I give is one where I compare the performance scores of various frameworks. And I tend to show that the good Core Web Vitals scores for a website, the probability that you get good Core Web Vitals, if you build your website, let's say using React or Vue, is something like 30-something percent. That's it. So like 2-3rd probability that your performance will be bad, and a third is the probability that the performance will be good. And once Google switches over from FID to INP, Substantially so instead of I don't know 30% will be 20 something percent maybe even less time will tell but but yeah so obviously Hydration is a performance problem even if Currently core vitals doesn't always reflect as this fact and From my perspective, it's actually worse because it's not just a performance problem It's a usability problem because if you navigate into a site and the website loads immediately and it's there and you try to interact with it. You click the purchase button because you really like the picture of that product and nothing happens. I'm betting that you won't enjoy your experience and there's a good probability that you'll go somewhere else and take your business along with you because you'll consider it to be a broken website, not just a slow website but a broken website. I hope you agree with that. Okay

 

Yep.

 

then, so given that hydration is problematic, we kind of fixed or fudged even almost the metrics, we get good LCB, we get good CLS, we even get good FID, but the user experience is bad, verging on broken, and this is because of this whole hydration mess, because this whole concept of running all the code twice, both on the server side, and blocking the main thread while you're doing it. This is a problem. And so now what I'm basically gonna do is going to run down through various different methods that are available in order to either circumvent this problem or alleviate it or do away with it altogether, various different strategies used by very different frameworks and developers and what not. So, The first option that we've got is the fairly obvious one, is to just avoid using a framework to begin with. If I'm not using a framework that uses hydration, if I build my website, let's say using WordPress, because WordPress doesn't use any one of these frameworks, it's just PHP on the back end and maybe jQuery on the front end, no hydration, problem done. Thing is, again, for better or worse, most developers these days to use a modern JavaScript framework when building their websites. Now you can argue whether it's a good idea or not. I think we're going to have Alex Russell on an upcoming episode who will argue vehemently that it's probably a better idea to just you know forgo frameworks altogether but I think that unfortunately the the I don't know the ship has sailed, the train has left the what

 

Yeah.

 

you will. That's what's being taught at boot camps. That's how people build websites these days, unfortunately perhaps, but that's just the way it is.

 

I'd

 

Now don't forget the cow has left the barn.

 

be really interested.

 

The cow has left the barn too, that's an important one.

 

Yeah.

 

The cow has left the barn too, that's an important one. The cow has left the barn too, that's an important one. The cow has left the barn too, that's an important one. The cow has left the barn too, that's an important one. The cow has left the barn too, that's an important one. The cow has left the barn too, that's an important one. The cow has left the barn too, that's an important one. The cow has left the barn too, that's an important one.

 

Yeah.

 

I'd be really interested to see what the alternative is, because I think that it's true if you don't use a framework, you will build your own.

 

I guess it really depends also on your website. And we'll get to it, but some frameworks have actually intentionally chosen an approach that's almost equivalent to not using a framework. So at least on the front end. So some of them are kind of, you think like, you know, we are a framework. If you wanna use a framework, we are definitely a framework, but you know, at the end of the day, they hardly have a framework so they kind of approach or achieve similar results to just not using a frontend framework. But I'm just pointing it out that the web works perfectly well without frameworks. If you don't want to use them, like 50, almost like 40 something percent of the web runs on WordPress, and WordPress doesn't use a frontend framework. So yeah, it's definitely doable.

 

true.

 

Okay, so that would be option

 

WordPress

 

number one.

 

is also riddled with bugs, security vulnerabilities. I don't have you ever met a WordPress developer that said, man, you know what? Developing WordPress is just a great experience. I love it.

 

Well, I can't look. I totally agree with what you're saying, but I do know a lot of, because of my history at Wix, there are a lot of die hard WordPress developers. There are a lot of people who've built their career on WordPress, love WordPress, and still create a lot of WordPress websites, and would get really annoyed when you tell them that maybe it's not the best thing in the world, but I totally agree with you, in particular about the security issues, but I don't think that these security issues related to the fact that WordPress doesn't use a framework. And if you built your website, let's say using Ruby on Rails or whatever, you won't necessarily have all these security issues or whatnot.

 

why

 

Well the other

 

it's

 

thing

 

still,

 

is

 

I

 

is

 

think...

 

the... Good.

 

I was going to say it's the lack of having a, the dictionary definition framework or pattern of where things should go so that there's a directed flow of connection between this and that. And then the, just the willy-nilly nature of it, it leads to a certain set of problems that can be avoided by not being willy-nilly.

 

I totally agree. I think that if you're building a sufficiently sophisticated website and you're not using a framework, you'll end up creating your own framework, which is in fact kind of happened to eBay when they created the Marco framework. That's essentially what happens. If you look at some of the bigger players, they've effectively created either their own framework or their own meta framework. For example, Wix, where I used to work, are using React. using a framework, but they're not using Next.js or some other meta framework. Instead, Wix has built their own.

 

Well, I don't think that's some, I think that's 100%. Every single large company has built their own framework. They're not using something else because they're building it for their use case that's different from the other companies. If you want a Facebook feed, React is the best way to create

 

Ya benden de...

 

it. And that's what we're doing. We're doing a lot of things that are not just for the sake of the company, but for

 

maybe.

 

the sake of the company. And that's what we're doing. And that's what we're doing.

 

Oh yeah, for sure. The thing about React is React was first and foremost created to address the Facebook use case. And it's being enhanced and maintained on that basis as well, which is maybe not something that all React developers like to hear, but I totally agree with you on that. Anyway, so we covered this option. Let's move on to the second one. The second one is also fairly obvious and say, you know, maybe I'm gonna say hydration is a fact of life. That's the way that these kind of frameworks have to work. So my approach would be to basically if I can make hydration faster, if I can make my framework faster and consequently I can make hydration faster then the problem is still there. It's also just not as bad potentially. That's currently the approach of frameworks like Svelte, like Solid. The interesting thing about it is that they're not saying that they won't adopt eventually any of the other types of approaches. They're taking more of wait-and-see attitude. They're saying for us, the problem is not a severe, maybe because we use a compiler as part of our build process, so we generate smaller, more efficient code. So the code downloads faster and executes faster, so the problem is not as severe. We look at how the other players work on solving this problem. If it turns out that one of them finds a winner, then we'll potentially adopt that strategy as well. But for now, we can make do just fine by just working faster. And that's also a reasonable approach. And like I said, that's kind of the approach taken by frameworks that use compilers like Svelte and Solid. One thing to notice though with some of these frameworks is sometimes there's like a tipping point that while your application is small enough, it kind of works, but then when your application or web application becomes sufficiently large and sophisticated, It increases like linearly. So once you go beyond a certain point it becomes too high Like you the same situation that you have with the more let's say mainstream frameworks, but but still especially if your website is smaller and lighter than perhaps by using these one of these frameworks then Practically hydration won't be a problem for you So that's that's the second approach The third approach is something that's, again, a lot of frameworks are kind of looking to embrace, but I think that Remix was the one that really brought it to the forefront, and that's a progressive enhancement. Basically, they're saying the following thing. If, let's say, I have a link in my page. Now, after hydration, If a user clicks that link, I want to do a client-side navigation. I want to intercept that click, bring the data using an Ajax call fetch, and then do the rendering client-side. But a link is a link. If that link is rendered as a proper HTML link, then it should work as a proper HTML link even before hydration takes place.

 

Right.

 

to that scenario where the user is so quick that they actually click the button that link, even before the JavaScript finishes downloading, that link will work. It will result in an actual page navigation. So it won't be, it will work like a multi-page application instead of a single-page application, but it'll still work. So the whole idea of a progressive enhancement is basically saying if the user tries to interact before hydration, then I will fall back to and use the built-in web functionality of a submit button or a link or whatnot. And I actually heard an interesting talk given by Noam Rosenthal, who was also a guest on our show, explaining how you can use various DOM functionality and simple JavaScript and CSS create fallbacks for a lot of the sophisticated functionality that you would then get after hydration. But that brings up an interesting point, which is if I can achieve the appropriate behavior and functionality without hydration, without the framework, then why do I need the framework? I mean,

 

Right.

 

if the page works just fine before the JavaScript finishes downloading, then why am I even downloading the JavaScript? And, you know, and to an extent, Remix, it kind of embraced that. Remix literally say that you can configure your, when you're building a website with Remix, you can either configure it to download the JavaScript or configure it to not download the JavaScript, and it can work either way. It will work, you know, as a single-page application if you do download the JavaScript, and it will work as a multi-page application if you decide not to. work. But that kind of pulls us back to that original idea of not using a framework at all. Basically, I'm just using a framework on the back end, you know, using React on the back end instead of PHP or Rails. It's not really being used as a front-end framework in a lot of ways, if you understand what I'm trying to say.

 

Mm-hmm.

 

But, you know, it can work. Again, you're kind of potentially constrained in the sophistication of the interactions that you achieve. Another problem is that, let's say I am using progressive enhancement, but I click after the hydration process starts. And again, if the hydration process runs for half a second, then again, the UI won't react to my interaction for that half a second. It will react once that process is done, but it'll be just really janky in that regard. So just progressive enhancement, assuming you do download the actual JavaScript and perform the hydration, does not overcome that problem of hydration blocking the main thread for potentially extensive periods of time. But again, it's an approach. Interestingly, with React 18, Remix was able to kind of enhance this, the behavior of a progressive enhancement by coupling it with something called hydration slicing. So you might say that if you're using Remix and React

 

Ooh,

 

18,

 

interesting.

 

then, and the idea behind hydration slicing is that instead of blocking, if let's say again that the hydration is supposed to take half a second. I can just break up that hydration slicing. process into 10 sections 50 milliseconds each.

 

I like that and it makes sense too because whatever's above the fold, unless somebody scrolls immediately, which I think most people, you know, they kind of watch it load

 

Hmm

 

and then, and then start interacting.

 

Yeah,

 

I like

 

but

 

that.

 

yeah, but it really depends on how how sophisticated that process is whether it

 

Mm-hmm.

 

it makes us let's say 10% of the page actual actually Interactive or it just breaks it only makes it be interactive at the end, but it can we can

 

Mmm.

 

actually process DOM events in the middle.

 

right.

 

So if it still even process. just process the DOM events, if you couple it with progressive enhancement, again, that might be good enough. You'll get the multi-page behavior, but you'll never block for more than 50 milliseconds. So that. But you're right. If I'm also able to slice the hydration in a way that hydrates the page, let's say, sort of in strips, going from top to bottom, that you're already seeing, but that's potentially more difficult because it assumes that the React components are exactly properly ordered and stuff like that and it turned out that it was actually really difficult to implement the slicing because let's say that React kind of finished building part of the VDOM and then got interrupted. Okay?

 

Mm-hmm.

 

say that that interruption did something that impacts the VDOM. So now I've got the VDOM in a sort of an inconsistent state. You understand what I'm trying to say? It kind of needs to

 

Mm-hmm

 

reconcile what the work that it's already done with changes that are a response to whatever the user did is part of that interaction. And that reconciliation of the VDOM turned to be fairly difficult to pull off, which is one of the reasons that React 18 took something like three years until they came up with a reasonable model to handle this sort of a thing, where they created these sort of suspense boundaries where each one of them is wholly independent and then can be rendered kind of independently and they don't impact each other of the V-dom much much more difficult. which again, the price we pay is that React 18 took such a long

 

Mm-hmm

 

time to come out and that it's such a, and it turned out to be such a monster when it did.

 

right.

 

But again, by the way, an interesting thing about that hydration slicing, so once the way you can slice is basically just, you know, have like this like a timer, every try to slice every 50 milliseconds, which can be kind of difficult if you're inside some sort of recursive function and you want to bail out, it can be fairly challenging. Interestingly, Chromium browsers have this API that's currently not supported by any other browser engine, which is called isInputTending, where you can check whether there is an event in the event queue. And then you can decide to bail out actually try to interact with the page, which is interesting. But like I said, currently only implemented in Chromium-based browsers. Anyway, moving on. The next interesting approach that we see is called Islands of Hydration, which I think is a term that was coined by Jason Miller, who created Preact, although I've also heard that he might have taken it from someone else. But he can certainly be. accredited with popularizing the term if not really inventing it. And it's the technique that's used by Astro and by Fresh, which is that framework built on top of Dino with Preact. And this approach it goes as following. If you consider most web applications, most web pages, most of the web page is mostly static. You've only got certain parts of the page that actually need to to be interactive. Let's say it's a blog post. The blog content itself is wholly static. The comments section might be interactive. I might have a view counter, which needs to be potentially interactive, a like button maybe, but those are like small parts within that page as a whole. So the concept of Highlands of Hydration basically says, I'll render the whole page statically just on the server side. And instead of rehydrating or hydrating as a whole, I'll just hydrate those parts of it that need to be interactive. And it sounds like a great

 

ლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლ 

 

idea, doesn't it? Yeah, I

 

Yep.

 

think.

 

No. Well, yeah, I mean, it sounds harder to implement, but yeah.

 

Well, the way

 

Yeah,

 

that

 

that's Astro for you.

 

Astro does it, Astro does it kind of generically for essentially any framework that you choose to use. Basically you just

 

Well,

 

say,

 

you got to have adapters for it. I mean,

 

yeah,

 

it's not just

 

that's

 

plug and

 

true.

 

play. You got to have something written for it. But yeah.

 

Basically, you're assuming you've got an adapter. So let's say you're using React for which an adapter exists. You just drop a React component into that Astro page, and just that React component will hydrate, or you can drop multiple React components, and each one of them will hydrate separately from each one of the others. So the Astro page as a whole doesn't need hydration, one of those React components that is embedded with it will first render on the server by Astro and then will be hydrated on the client side again by Astro. But just these particular components and they could be much, much smaller than what you would need for the pages a whole. What are the problems with this approach? Problem number one, it can be challenging to share data between these components. If these components each talk directly to the backend, then it's great. like a global paid state that they all listen to, it's kind of challenging because they all run totally independently of one another. They don't know about the existence of each other. You can do all sorts of things with the window object, put data stores directly on the window, but then you get into all sorts of synchronization issues. Basically, that's one problem of how to share data between all these components without having to go back to the server, let's say.

 

Well, you can plug and play your own state management stuff too. I mean, they say in the docs, if you want to use Vuex, your opinion or something like that, at least from the view side, you can.

 

Oh, you can. I'm just saying it's more complicated. It's not something you get out of the box when you're using something like Next.js. Now again, usually you don't care in an astro type environment, because again, if I'm going back to my blog example, the comments section doesn't care about the like button and the like button doesn't care about the view count. So each one of them works effectively independently to share client-side state. But again, you can if you want to, but it's on you as it were. Another issue with islands of hydration is that they effectively require the page to be a multi-page application. You don't get single-page application behavior. You don't get client-side routing if you're using islands of island of hydration because each one of these components is a small component within the page. The page itself, the routing code is never downloaded. The whole idea of islands of hydration is that you never download the code required to generate a page as a whole. That just exists on the server side.

 

Bye.

 

So if you look at Astro or you look at Fresh, they work as multi-page applications. Now it can be totally fine. being primarily for content type websites. And again, and also if we look at some of the new innovations coming out of the Chrome team, so to enable transitions between pages in a multi-page application, maybe we'll get to a point where you don't really need single-page applications. But if you decide that you want to build your website or web app as a single-page application, then

 

Thank you.

 

the

 

Thank you.

 

vibration approach isn't really appropriate

 

Thank you.

 

for

 

Thank you. 

 

you. On the other hand, if you can build it as a multi-page application, then Astro is probably a great solution for you. We had Fred on our show. It's a great solution. It's gaining a lot of popularity and justifiably so. And by the way, it's getting

 

Well.

 

excellent core vitals.

 

Yeah, I think, I mean, part of this discussion, I think, is that it's the right tool for the job. You can't, you know, don't want to be that, you know, everything's that, nail and I've got a hammer, as I used to be, you know, when I first got in the web development work with Drupal back in early 2000s. You know, Astro is great for specific use cases. There's some ways you can stretch it, and there's some ways you can't. And if it doesn't work, then you find another tool. So, you know, I can think of three different tool sets I use depending on what kind of application I'm using

 

Yeah, but to be honest,

 

to build something.

 

I think you might be more the exception than the rule. From what I see, most web developers like to pick their tool of choice and then try to stick with it. There are those web developers who like to jump around between the various different frameworks and tools and whatnot and always try the latest and greatest. But I think most web developers who just want to get the job done and then go home and watch Netflix or something like that,

 

Thank you. 

 

they will use what they know. So if they know react the next JS, they will use react the next JS for everything including situations in which you know astro would have been a much better choice. You know, you're free to disagree with me but that's what I'm saying.

 

Yeah,

 

that.

 

some people will, some people won. I've just always said the best tool, use the best tool for the job. And

 

Yeah.

 

that way you're getting the

 

Well,

 

most

 

I think

 

out of your tool.

 

you should learn a minimum of set of tools. You should not learn every tool. The younger you are, the more sense it makes to cast your net widely. But as you move towards senior positions, you want your net to be more and more narrow so that you have specific knowledge and specific tools. And if you can hone in on which tools address, I kind of this and that we hate perfect things video there's usually in any system there are three constraints and you can make a trade-off where you capture any two of the constraints so if you inside of a system you should be able to find three tools where each tool captures two of those sets of constraints and the generic problem

 

Thank you. Thank you.

 

to this is the I want it fast cheap and high quality you can either have it fast and high quality or high quality and cheap, but you can't have all three.

 

Yeah, I totally agree. And again, the reality is that most people just

 

Eugh

 

want to get the job done. Also, most organizations like to, you know, prefer betting on the sure thing. So, you know, React and Next are considered to be mainstream technologies. Others, other frameworks might be, you know, they might be great, but they're considered more like out there and who knows if we'll be able to find developers for them and whether they'll even be around in a year or two. And yeah, so I guess that a lot of people just like to play it safe. Anyway, moving on to the next one. So we covered islands of hydration. The next one is kind of similar. It's sort of similar to the extent that, you know, some people kind of get confused between the two because it seems to be working in the same sort of a way, but it's actually really different in the way that it's implemented. And those are server components. And they are implemented, let's say, as React server components in the context of the next JS13 together with React 18. Interestingly, Shopify's Hydrogen embraced them big time, and then they basically threw this all the way and embraced Remix instead. And Remix is taking wait-and-see approach about server components, they basically saying that they don't feel they're ready for primetime yet, so they are kind of doing without for the time being. Anyway, what are server components? The idea is really similar to the idea of the islands of hydration. Basically, you're saying, but a large portion of the page is effectively static, doesn't require client-side interactivity, so why do I even need to download that JavaScript? I'll only download the JavaScript for those components that actually need to be interactive on the client side. And in this kind of a system, all the components that are only generated once and then remain the same, those static components are implemented as server-side components, and all the components that have interactivity are called client-side components, even though they actually also run on the server, but are then hydrated on the client. So it's kind of a misnomer, but that's the terminology that they're kind of using in order to confuse everybody. So how is this different than the Islands of Hydration approach? Well, for one thing, server components can be embedded inside of a page that's rendered on the client side. So they do work with single-page application. Now, that sounds really weird. a client-side routing happening, and then using stuff that's rendered on the server side. But if you think about it, basically you can make, or do like a call to the server and get the HTML of that component in an Ajax, for example, or maybe JSON that you then transform into HTML, and then just embed it in the relevant part of the page. It's kind of like doing an and then doing inner HTML equals whatever you get back. And

 

Mm-hmm.

 

so you can actually get that working with single page application. And you can even embed client side components within that server side component. So React is really sophisticated about how it manages, it does a lot, a lot, lots and lots of magic and pulls, you know, lots of rabbits out of the hat get this whole thing working. By the way, with React 18 and Next 13, all components are server components by default. So the default behavior is to be a server component. If you want client-side interactivity, if you want you have to have your own component state, because it only makes sense to have state if you're interactive, then you need to explicitly declare yourself as being

 

Thank you. 

 

a You know how you put use strict in, in, in, uh, we used to put use strict in order to signify, uh, JavaScript strict mode, which is kind of now the default for ESM modules. Well, with React 18, you actually need to put use client at the top of the file to signify that what you're building is a client side component. Kind of funny what they're doing there. So one big difference is that server side components can be part of a single page application unlike islands of hydration. Another thing is that they're actually leveraging HTML or HTTP streaming. The server components, unlike React client components, can be asynchronous. And the end result is that when the server starts executing the code, let's say you've got three components, each one making a request to some back end service. and one backend service is really fast, another kind is medium speed and the third one is slow, you'll get the HTML response in three chunks. One for the first component, then for the second component, and then for the third component, and React can actually take all these parts of that HTTP response and merge them all together in order to create the unified UI for the application. can put in loading spinners or placeholders for the parts that haven't downloaded yet. So your HTML kind of instead of arriving as one block is kind of streamed down

 

Thank you. 

 

to the client as soon as you know parts of it are finished and are ready to render on the client side. So you can actually have without any client side code so to speak. of showing data as quickly as it's ready, kind of a behavior, which kind of reminds me of this, you know, this tweet that I tweeted once, you know, we all use Twitter for hot takes and stuff like that. So I tweeted that, how do you recognize a modern web application that it has lots of small spinners instead of one big one? So yeah, so with React server components, you can think about each one of these components you see a page full of spinners kind of coalescing into a page with content as soon as any piece of content becomes available and you can do that as if or effectively without having to write any client-side JavaScript. So server components sound really great but there are of course trade-offs with them. to like a readjustment or of how you code and react. Basically, all the people moving to next 13 are kind of effectively relearning next and react to a great extent. It's a big mental shift. You're not writing the components the way that you used to. Now you can make your move in a gradual sort of a way. You don't have, it's not an all or nothing, But if you want to actually take advantage of these features, you're effectively having to learn a new mental model. So that's our new set of APIs and a new way of building your React application or your next application. So that's problem number one. Problem number two is one that Ryan Cognato, the creator of SOLID actually explained to me. out that he's actually playing with all of these approaches. He's trying each and every one of them effectively in the context of solid and trying to see which one works best. And he brought up an interesting point. He said, let's say you've got React Next application that's currently 100k JavaScript download, you know, minify, gzip and whatnot. And thanks to using server-side components, you're able to cut this in half. And it's now only download. Sounds great. But it turns out that the overhead of of server of React server components in the React framework itself is something like 70k. So you...

 

Oh wow.

 

now I'm just throwing them the numbers. I'm not exactly sure what

 

Uh-huh.

 

the numbers are. But React itself has and especially with Next has become bigger and heavier in components. So effectively you might end up in a situation where you've transitioned to React 13, to next 13, you've done all the work of transitioning and embracing and using React Server components and then you measure your actual download size and it turns out that you've not saved anything, maybe you've gotten even bigger because you're downloading lot more react the next cut. Yeah, which is one of the reasons that Ryan is still kind of on the fence with this one. He said that he's actually playing with this part, partial implementation that he's got going in solid, which is, he says, much more like to wait, but still, he's still on the fence with this approach. But, it does work. The final one, because the show is kind of long, so I'll make this quick

 

Mm-hmm

 

and pun intended, is resumability. Resumability basically says that I can

 

Ha ha ha!

 

have my cake and eat it too. I can use a modern framework and what would, you know, in the type of coding approach that would normally require hydration, but without using any hydration at all. And the magic that is used to achieve it is called Resumability. This is the concept that's being used in Quick. It's also, per my understanding, part of the next version of Marko, which whenever that comes out. But the basic idea is that instead of rerunning the framework, work and application code on the client side in order to recreate the application state. Instead of performing this whole process of hydration, I actually don't throw away the state that I created on that I had on the server back when I created that HTML string in the first place. Instead I kind of serialize both of them and send them down to the client. So instead of just serializing the data that I need in order to create a new client, I run all the code, I actually take a sort of a snapshot of the memory of the framework, serialize that, send it down to the client, and then basically just run from where I was as if the code just keeps on running. So like bridging the divide, like taking that memory is sort of like memory dump from the server side, loading it on the client side, the analogy that Mishko, Mishko, I have a creator of Quick, likes to use, is similar

 

Mm-hmm.

 

to a virtual machine where you suspend it and then you resume it. You don't need to reboot it in order to get to where you were. You just resume it and it's instantly on from where it was. Now, they don't actually, you know, the problem with a virtual machine is that those memory images take up a huge amount of space and that's not obviously something that you can send over the wire for a web page But they're much more sophisticated about it Also, they're sophisticated about which parts they actually run you kind of touched on that in the beginning of the show AJ when you said that they put an event handler way up at the top on the window object and then identify what needs to run and then they just Make sure that that piece of code has the, they set it up with the appropriate state and have it run from where it needs to. It's a great approach. There are prices to pay. For example, they're wholly asynchronous in event handling, which can be problematic in some cases. For example,

 

Well, they, yes and no. It's the important thing to understand is that it is, the components are not asynchronous. They, as an async, none of it uses the async standard. There is no top level error handling. It is not async in the way that you would think of modern JavaScript async. It is async in the way you think of 90s JavaScript async, which is an important that I did not realize the first couple of times we talked about it.

 

The consequence, for example, is that very often in event handlers, you want to cancel the default action. You can't do that in JavaScript by putting on the event object there is this property, like what's it called, prevent default, that you just set to be false. You cannot do it this way with Quick, because by the time you process it, the event handler is already returned back to

 

Thank you. 

 

its finished executing.

 

Thank you. 

 

So you kind of need to declaratively tell quick that you want quick to do this for you sort of a thing if you understand what I'm trying to say. You kind of have to specify your event as being passive instead of doing you know prevent default is asynchronous to the capturing of the event. That's the thing I'm trying to kind of convey. But again, it might not matter in many cases, but the bottom line is that it does kind of work differently than other frameworks. Another interesting thing is that in most cases, resumable frameworks actually end up running as NPAs rather because you never end up downloading and executing on the client side the routing code. So the routing ends up still happening on the server side in many many cases. Again that's how Ryan explained it to me. So that might be a good thing or that might be a bad thing but it's just how they tend to behave. So don't expect to resumable frameworks So, resumable frameworks kind of look and the developer experience is very similar to working with the more standard frameworks. So, for example, quick intentionally picked JSX just so that it looks as much as possible like React. But it turns out that in many ways

 

Thank you.

 

at the end of the day,

 

Thank you.

 

when

 

Thank you. 

 

you look at how that web application actually works, it actually works in a very different way. But the big benefit is that you do away with the cost of hydration, which means that you can get really great performance and user experience, because the UI is never blocked on this lengthy hydration process. If again, if our listeners want to get more information about quick and resumability, we had two great episodes with Mishko, because it was such a sophisticated concept explain we had to have him on to explain it twice. But yeah.

 

Thank you. 

 

And you know there are other things that I can touch on like edge computing is also kind of relevant to this because if you can execute your back end on the edge then you can respond more quickly which means that you can move more logic from the front end to the quote unquote back end because edge isn't exactly back end. And there are other concepts but these are really the primary event we've been running pretty long in this episode anyway. So I think this is more or less where I'll wrap things up. unless there are any questions

 

Yeah, but it's

 

or

 

cool

 

comments.

 

stuff.

 

So would you want this as a conference talk at your conference? Ha ha ha.

 

Yeah, because I think some visuals might help. I mean, it's pretty involved as far as topics go, but yeah.

 

Yeah, for sure. I know that Mishko, for

 

sense

 

example, has some great graphics that kind of highlight the difference between hydration and his roomability that he shows when he gives talks about quick. So yeah, I would

 

Yep.

 

likely steal some of his visuals if I were to do a conference presentation about this.

 

Yep.

 

with credit of course.

 

All right, well, let's, yeah. All right, well, let's go ahead and do our self-promos and then our picks. Steve, let's start with you. What are you working on that people should know about?

 

I'm working on prepping my dad jokes for the week. It's always the high point of every episode, right? Anyway,

 

Yeah, well that-

 

so the other day, my wife texted me and she says, what does IDK stand for? And I said, I don't know. She goes, dang, nobody knows. Right? So a couple of deep

 

Who's

 

thoughts.

 

on first kind of a joke?

 

Mm-hmm.

 

I'm sorry, what?

 

It's a kind of a who's on first type of a joke, isn't it?

 

Uh, I guess sort of, if you want to think about it that way, I hadn't thought about it that way. Uh, let's see, moving on. Some deep thoughts, if anybody remembers the Saturday Night Live, you know, uh, frequent feature of deep thoughts with Jack Handy. This is sort of long those lines. So first of all, there's a person who takes care of chickens called a chicken tender.

 

Hmm.

 

Right?

 

Hmm. These

 

And...

 

are important questions we have to ask.

 

Before electricity was discovered, more electric yields called.

 

Demons.

 

And then, I actually, believe it or not, I went and looked that one up. I was looking up the history of electric eels and what they are and why they're called that. And I couldn't find anything that addressed that. So I was sort of disappointed. And then lately, my wife has been threatening to leave me for never putting the toilet seat down, you know, a common complaint. I figured, well, that's good. I was getting tired of carrying it around anyway. Anyway, those are my picks.

 

All right. AJ, what are you working on that people should know about?

 

Did I already mention the DuckDNS shell script before?

 

I think you mentioned it last week.

 

Well, I'll mention it again,

 

Ha ha ha!

 

because

 

All right.

 

Once is never

 

it's,

 

enough.

 

well, yeah, once it's never enough. I haven't done any more work on it, but it got one more star. It was trending so hard, it got 23 stars and then it just stopped. So I have to announce it on the show again, I guess. But yeah, if you're, there is literally in 2023, there is no reason that you should ever, ever, ever using local host as how you're doing development. You should never use that. There are so many problems with it in terms of you get differing security policies, you get differing differences in the way APIs are exposed. It is just such a bad practice. And with things like DuckDNS and Cati, you get HTTPS on a real domain. That means you get separate cookies, you get separate local storage. You know, you can do actual Development as if it were a real app now I mean I'm of course going to say what you should be doing is developing on something like digital ocean So that you actually have the full network activity loop and you're not you're not mocking out things that are gonna break Once they get in production at all that everything should work on the internet from the start I realize that some people are in a position where you have such poor internet connectivity They're working on a VPS just doesn't work because the the round trip ping time is too slow You'd be watching your characters So at the very least use something like DuckDNS and Caddy and then you have your own local storage. You can have multiple domains. You can be able to check how your app interacts and an SSO, the single sign on type of situation. You can check how it works doing API requests between it. You can have a separate API domain and a separate front end domain. You know, it opens up the whole actual real world of how web apps work to you when you're using a web app. a real domain on your local system. And since Cadi will issue both real SSL, or TLS, pardon my French, TLS certificates through Let's Encrypt and zero SSL and all of the others. And as well as it will also allow you to generate dummy domains as well. So even if you didn't want to use Duck DNS, you wanted to be completely DNS free and just do Etsy hosts, screw up your Etsy host and have example.dev and food.example.dev and bar.example.dev and example.net and just totally muddle your Etsy host and Catty will happily serve you fake certificates for those that all you have to do is click a button and then it will be accepted and your browser won't even give you a red lock because it'll put it in your system T-Chain for 24 hours or something like that. But anyway, the original thing was the DuckDNS. Also, right now streaming series on shell scripting and it is geared towards well that the commentary is geared towards web developers. I'm going through two books one is called the Linux command line, a complete introduction second edition and the other one is called Mastering Linux Shell Scripting and so I'm just kind of going through these on stream. The last stream was two hours long people ask questions I go through the book and say okay well Well, this is important just generally. This is maybe outdated information or isn't the way that you could script in a way that would work in Docker or other deployment environments or whatever. And so my goal is just kind of to go through the book and do a pass at, try and do

 

Thank you.

 

to

 

Thank you. 

 

kind of understand what the current education material is and where it's on point and where it's lacking. And the differences between interactive shell and a scripting shell because they're two completely different use cases Interactive versus scripting and that is happening on the cool AJ cool AJ 86 channels. I do Plan at some point to take this experience condense it down and then produce videos on the beyond code channels as well But the live streams are happening on the cool AJ six channels

 

Cool. How about you, Dan? What are you working on that people should know about?

 

I don't know if people should know about this, but probably they have no reason to know about it. But what I'm mostly doing right now is trying to prepare my schedule for 2023, both for work and for conferences. So for work, you know, most people perhaps plan their year in advance, but I happen to be touring Australia for all of December. So I'm now currently working with various other teams and project leads. whatnot, at Next Insurance trying to figure out where I'm going to focus on this year. So that's mostly what I'm doing at work. And I'm also submitting to various conferences. I've already got accepted to two. I'm going to be speaking at the IJS conference in London in April. And I'm going to be speaking at JS Nation in Amsterdam and I've submitted to a couple of more, so hopefully I'll be speaking at other conferences as well. So if you're interested in me speaking at your conference, this is the time to reach out. You know, for example, one of the talks that I might give is exactly what we covered in today's session, but again with slides and you know diagrams and whatnot that will make it potentially more understandable. currently mostly involved with.

 

Cool. All right. What I'm working on, I've kind of got a stealth mode project, but I'll go ahead and talk about what it is, and that way people can check it out. I've kind of had this in the works for a little while, and I'm almost ready to launch it. But effectively, it's a resource directory for JavaScript developers. And I'm going to open it up so people can submit their own resources, right? videos, tutorials, podcasts, podcast episodes, blog posts, YouTube videos. I'm also going to, I'm hoping to be able to pull in like an index from NPM or something. But what I want and what I've wanted for a while isn't just, you know, to know what's out there, but I want to give people a chance to come in and like, rank something, rank something five stars and, you know, give, give me a review and let me know, hey, this, this really helped or, hey, you know, I ran into these implementing whatever or, you know, just stuff like that and just seeing if I can, you know, figure out where a lot of this is coming from. The other thing is, is I'm hoping that it also gives us a better read on what's going on in the community and, you know, who's getting attention and stuff like that, what kinds of things people are interested in or looking for, so that we can invite the people who are involved in that onto the show or, you know, and let people know, hey, these are the things that people are talking about, or these are the things we think will help you out. And just kind of provide that overall resource for people so that at the end of the day, you can go in and you can say, hey, these are all the JavaScript things. Now, I'm starting with JavaScript. And sometimes I worry that JavaScript is a little bit overbroad as a space to work something like this in. I am planning on releasing a directory the other shows we have, right? So there'll be a Ruby directory, there'll be a React directory, there'll be an Angular directory, there'll be a View directory. But right now, I'm just trying to get the JavaScript one up and standing. And that's going to be at JavaScriptpix.com. So if you're listening to this show, it should be pretty easy, right? Because it gives you a chance to submit your picks. But yeah, also trying to pull in like links to tools and stuff like that, right? So there's probably gonna be a category for like tools and then editors and IDEs and then, you know, you can rate and review Visual Studio Code, but there'll also be a category for plugins or maybe VS Code plugins. And so then you can go in there and you can say, I'm using these ones and I like them because, right? Because I just, I get rundowns from people on the kind of stack of those they use, out there, how that's going, because sometimes the ones that get rated in the extensions listing in VS Code, for whatever reason, they just don't work for me. And so just being able to kind of go, hey, this is what's out there and then what people are using, allow them to leave commentary and reviews, kind of like an Amazon review, I guess. I think that would really help. And then we can give people a place where they can come for all of their script stuff. I want to learn more about this. I can find all of the podcast episodes, books, conference talks, the whole nine yards about that topic. So anyway, so that's kind of the thing that I've been working on lately and then I do also have a course coming out within the next couple of weeks about basically how to focus on and build your career, make yourself so you're more hireable so that you're building a career that's fulfilling and that helps and you know build the kind of lifestyle that you want. So if it's money, if it's I want more time with my family, if it's you know I want to travel, right? Just help you figure that out and figure out what the steps are to get where you want to go. I want to speak at conferences, another one that I hear a lot. So anyway, so that's what we're doing. Alright, let's do picks. Dan, you want to start us off with picks?

 

I can try. So my first pick is going to be a talk, or a short video actually, given by, I forget his last name, Theo, he calls himself 303GG. He does a lot of streaming and stuff. He gave, he did a short bit. It's only like three and a half minutes. That's basically titled, in a click baity sort of a way, don't learn TypeScript. Where he basically says, you know, you shouldn't learn TypeScript as TypeScript. What you should do instead is learn JavaScript while using TypeScript libraries and TypeScript bindings. So have your development environment be type aware for you while you're just learning JavaScript. It's a great video, I enjoyed it a lot. It kind of, it got me thinking. about, you know, because I've been thinking for a while about what people are coming into our web development, which programming language they should be learning these days, and having watched that short video, I have to say that I very much am in agreement with it. So I would recommend that. If we're talking about YouTube, but also recommend, we mentioned him a couple of times in doing this a weekly stream where he literally streams for something like five hours. Which sounds insane, I don't know how he does it, but his streams are just so interesting. When I did my research about frameworks and how they deal with hydration and stuff like that, one of my main resources was a video that he did called a titled JavaScript frameworks in 2023. Which is five and a half hours. Obviously, I listened to it at high speed, but it's just great content and I highly recommend this stuff but like I said, you know be aware that you're in for a fairly lengthy Dissertations as it were so that would be my my second pick And my Third pick is oh, yeah Have you noticed that chat GPT is not exactly free anymore? You've not got got chat GPT Pro, which is for now at least $42 a month The free one still exists, but given that jet chat GPT Pro gets a preferential treatment I wonder how available the free version will be. Let's put it this way

 

$42 a month to get bad code that doesn't run?

 

Yeah, turns out that, you know, we'll need to get back to writing our bad codes ourselves instead of getting the AI to write it for us.

 

I mean, just, I don't know, maybe it's worth it. I'll have to think about it. Cause it has been nice to be able to find related search terms for things I'm not familiar with, but it's like, I'd rather pay brave premium search, I think.

 

The problem with search is that at the end of the day, you get a page, which can be great, assuming you find a good page on the topic that you're interested in, whereas chat GPT kind of writes a short essay for you explaining the topic or whatever, which I

 

Yeah.

 

guess a lot of people actually prefer, but whether or not they'll be willing to

 

It's

 

pay $42 for it is an interesting question. So, I guess I'll just go ahead and do that.

 

Well, I had somebody, because I use chat GPT on stream, or I have been quite a bit, because it's the thing people are talking about. And it actually is useful. It actually is useful to get me in the ballpark of where I need to be. And there was something that I wasn't personally familiar with, and it was late at night, so I wasn't using my brain. And I was thinking, oh, OK, all right, so that's how it works. That makes sense. And it was something that was so common that I thought there's no way that chat GPT could get it wrong, because it was just one of those. It was just one of those common things that chat GBT is usually pretty good at, not something that's new or novel or creative. And then somebody in the stream said, Hey, that is completely incorrect in every possible

 

Ha

 

way.

 

ha ha ha!

 

It is literally just throwing related words at you. Don't listen. And I thought, Oh, oops.

 

Yeah, the problem with a...

 

Yeah, um...

 

No, go for a check.

 

I was just gonna say, I've talked to a lot of marketers that are using it to generate at least the beginnings of some of their copywriting. I mean, they don't use it just copy and paste, but a lot of times they use it as kind of a brainstorming tool or a way of kind of collecting information into a semi-coherent way of putting things. And then from there, they can spin it something that actually makes sense and will help people. So it's a shortcut for doing all the writing.

 

Well, I can't tell you that I had a team lead who shall remain anonymous, not at next, by the way. Tell me, but maybe he was just pulling my leg. But he stated, he claimed that he needs to write performance reviews for the people on his team. Then he has Chad GPT do it for him. Ha ha.

 

Wow.

 

Yeah, that's kind of amusing. Imagine having your yearly review written by AI. Yeah, nice.

 

It's just as relevant as having it written by a manager.

 

Ha!

 

Oh, did I say that out loud? What I meant was exactly what I said. Anyway,

 

It's an NPC. If you're gonna pay an NPC to write something for you, get the cheaper

 

Yeah, and

 

one.

 

another one, by the way, told me that all his internal work emails are written by ChatGPT.

 

Yeah,

 

All right.

 

that's four NPCs by NPCs.

 

Yeah, I wouldn't be great

 

Anyway

 

if everybody uses chat GPT and it's just chat GPT generating all the emails within the organization and reading all the emails

 

Right,

 

within

 

I

 

the

 

reply

 

organization.

 

to you with chat GPT, yeah.

 

Yeah.

 

So yeah, are those all your picks? Cause

 

Yeah,

 

I do

 

okay.

 

need to keep us moving. All right, AJ, what are your picks?

 

Oh, that's a good question. Um... You know, I had something top of mind and then I think I just forgot it. So. The album that I don't remember the name of by Hot Hot Heat with the song No Not Now. That one gets stuck in my head all the time still after the 20 plus years. Oh no, she's not a secret now. Nobody cares. Oh no. Yeah.

 

Thank you for singing, AJ.

 

Hopefully you

 

With,

 

don't get a

 

I

 

copyright

 

feel better

 

strike.

 

now.

 

yeah, I would have thought that with your kids, you would have been into baby shark or whatever.

 

Uh, you know, let's see. Okay. Let's talk about that then. Um, animal crossing. I'll pick animal crossing because my daughter, she likes what she calls jumping Mario cause there's different Mario's, but it's the, it's the simplistic Mario, the Mario, you deluxe super Mario bros, you deluxe, which is essentially all you do is jump in side scroll. And I thought that that was really good to get her started with because it helps you of the buttons to be able to move left and right, to jump, to have some granular control so that you're not full hard right, full hard left, but that you kind of get some control. And it's very simplistic. But she likes it a little bit too much. And I don't think there's a lot of value in it, that it doesn't have, there's nothing that's particularly artistic about it. There is a little bit of music, but it's just very, very, it's what we might call a hyper casual game, right? And I'm not interested in having my children raised on hypercasual games because then they will have hypercasual minds. I want games that help to expand horizons to be able to problem solve, to be able to be motivated to learn to read. So if she's playing a game and she wants to stop to ask one of us to read to her what a character is saying, that is a good sign for me. Being able to control multiple things at a time to have to switch between things and kind of develop that mental model of multiple things go on in the world at once. So I want games that have that educational quality. And we got her Animal Crossing to play with Auntie, and Animal Crossing seems to have a nice blend of being a little bit more creative. She's learning to, you know, take things and put them together. kind of that, I forget what the mechanic is called, but the kind of apothecary mechanic where you, if you have a stick and you have this and you put them together then you get a ladder, you know, that kind of stuff. And so I'm so far I'm feeling pretty good about Animal Crossing and it also has that social element of she can get online and play with with Auntie and so I think that that's really good and we were enjoying Yoshi's Crafted World. I think Yoshi's in between the two. It's got the jumping and side-scroller aspect, but it also has a little bit more of a reading aspect, and it's got a little bit more of an artistic style that I think is conducive to what I like, because all the elements in the game are origami or paper boxes with glue and glitter. They're all things that could be inspiring for what she might want to do during her craft time and stuff like that. So, there. Picked. Ka-chow.

 

Cool? All right, I'm gonna throw out, I'm gonna be really quick, but I'm gonna pick a board game real quick. It is Harry Potter Death Eaters Rising. It came out like three years ago. It is kind of a hard game to win, I will just say. It has a board game weight of 2.31, so a little complicated, but casual gamers can play it. If you're a Harry Potter fan, it's kind of fun. But yeah, it takes a little bit of a learning curve So I'm just gonna let you know that Basically you put out cards Voldemort attacks people in various locations in the game which are also just Put out by they're on cards and you know, he turns three different directions and You know attacks whoever's there and then You have to take out the death eaters that are out there if you take out the death Yeah take out And then you can attack Voldemort and you can also as you're rolling the dice you roll dice and The dice have different faces on them. And if you get the right combination, then you can You can recruit some of the heroes from the game some of the characters from the game into your hand into your onto your team and then you can Use them right to do the attacks when you're older dice. So it's it's It's fun I with two players than with four players goes two to four players, but yeah, it's it's fun. So my wife got it for Christmas. Her sister had it before that. So anyway, I'm going to pick that one and shout out to that one. I've also gotten into I think we talked about it on Angular, Adventures in Angular. We just did a show about tailwind and our experience with I've been playing with it quite a bit after since then. And I'm really liking it. So I'm just gonna put that out there. I'm enjoying Tailwind. I think it's cool. It's pretty nice. The Rails Tailwind plugin is not working for me at the moment. I just jammed a file in because I bought a template. But, and so it doesn't have all of the Tailwind classes in it, right? Because they just kept the ones that they needed for theirs. But as I'm expanding into using more of Tailwind, I need some of the classes they didn't include. I'm trying to figure out how to get them in. But that said, I like the style of it. It feels nice. I get the complaints that there are really, really, really long lists of classes that you put in there. But anyway, it's been pretty approachable, I'm just going to say. So yeah. So those are my picks and I guess we'll wrap up here. And until next time folks, max out.

 

Bye. Chuck, if...