Wrapping Up

[00:00:00]
>> I know I've covered a lot of patterns here. However, if you wanna read more, then make sure to check out patterns.dev. Cuz we have a lot more patterns here, stuff that I wasn't able to cover today, like mixin pattern, mediator/middleware. What else didn't I cover? Flyweight, I guess.

[00:00:20]
And yeah, it goes all the way down. And then there's also Addy's original book, Learning JavaScript Design Patterns, and I believe he updated it to the ES15 syntax. So this is also covering a lot of the original patterns, are based on the original book with the updated syntax, in case you wanna learn more about JavaScript patterns.

[00:00:45]
>> Someone wants to know how you created all those awesome animations.
>> Keynote. [LAUGH]
>> Just Keynote?
>> Yeah.
>> The rendering patterns, [LAUGH] it was helpful, but it was also fast and a lot of new information for me. Do you have any other resources you would recommend?

[00:01:00]
>> So I actually have a blog on this, what it's called, Talks Rendering Patterns. Now this one doesn't cover client side rendering. Don't watch this talk, it was really bad, by the way, [LAUGH] it was so bad. But on this blog I also have everything about static rendering, and then also server rendering.

[00:01:21]
And I also included, let me just go down a bit, the edge rendering side that I wasn't able to cover here. So serverless and then we have edge server side rendering. And I have to say, because this was also tough for Vercel, a lot of this is kind of focused on what Vercel uses out of the box.

[00:01:40]
But by all means, I see a lot of frameworks move to this edge SSR right now, just because it comes with so many benefits. So it will definitely be the future of rendering. I feel like talking about rendering patterns will be outdated in three years from now. Everyone will just use one optimized pattern, and be, why did we even have to think about this?

[00:02:00]
I may be wrong, but yeah, especially with React server components and the new Edge runtime, stuff like that, it's exciting, I like it. It will only get better, well, it gets so much better.
>> It also mentioned in the intermediate React course, Reinhold kind of covers some of these topics, shows you how to do server side rendering and that kinda thing.

[00:02:20]
>> Yeah.
>> Could you clarify again the distinctions between static rendering and server side rendering?
>> Yeah, so-
>> I know you kinda talked about that, but-
>> For sure, so the biggest difference is that with static rendering the HTML gets generated at build time. So if I deploy my website right now, it would get built.

[00:02:42]
So it generates the HTML on my computer, and then I can deploy it to any server. And what I deploy is already that complete HTML. But with server side rendering, that HTML that normally I would have built on my computer, it will get generated on the server when a user requests it, if that makes sense.

[00:02:59]
So instead of already having that HTML file ready for the user as they request it, it still needs to be generated on demand, which is the biggest difference. But they both kind of return the same result, they both return the static HTML. But when it's generated is the biggest difference here, if that clears things up.

[00:03:17]
[LAUGH]
>> Another good course to check out would be Scott Moss's Next.js course.
>> Yeah, he had a Next.js course, right?
>> Thought to say what you're talking about. We won't have obviously the streaming SSR stuff here.
>> It's probably good it's still in beta [LAUGH] so the API changes, I guess, probably.

[00:03:44]
>> Is there a way to measure the current performance rendering with the browsers?
>> You mean like Lighthouse? Are you aware of Lighthouse?
>> Yes, something like that.
>> Yeah, so you can use, for example, this one. Okay, I'm probably gonna get a really bad performance, and not right as I talk to you, I gotta get good performance.

[00:04:03]
So we can, for example, here generate a report, I'm just going to do it on desktop. Generate a report, Now it's auditing me, or my website. Let's see. It comes up with fun tips. Average user device costs less than US $200. They just show this to be like, look, you really need to optimize your website.

[00:04:29]
Cuz a lot of people have pretty bad phones, so it takes a long time to load that website. I don't know why this is taking me so long, by the way, normally this doesn't take this long. I know there's also something like a real web curve test or something.

[00:04:48]
I think maybe it's this one.
>> webpagetest.org is great, and then web.dev allows you to kinda do this Lighthouse.
>> Yeah, so I can start a test here. So, yeah, it just showed you it runs on a really bad phone right now. So this is gonna be,
>> But yeah, you can also go to web.dev and that's basically Lighthouse.

[00:05:17]
>> Yeah, I don't know what this is, this never takes this long, [LAUGH] okay.
>> Under measure.
>> Yeah, I always forget everything that thing that-
>> That's basically a hosted version of Lighthouse.
>> Because it returns the same results. Okay, I'm just going to close that one, maybe that'll speed things up a bit.

[00:05:40]
Do I have Wi-Fi? Yeah, I do. [LAUGH] Okay, well, here you see that it measured the first concentful paint. It measured the time to interactive, total blocking time, cumulative layout shift, all that stuff. Now, it also shows some nice opportunities, stuff that I haven't covered yet, like serve images in next-gen formats.

[00:05:57]
For example, here I'm using PNG, and maybe I wanted to use webp, I don't know, other type of better formats that make it. It actually also shows you how Next.js is doing it, which is pretty nice. Cuz yeah, if you're using Next, it actually comes with image optimization by default, which is pretty nice.

[00:06:15]
So yeah, it shows you all these things. Also other stuff that I haven't talked about, not about performance, but about accessibility. For example, some of my buttons don't have an accessible name. So this can be difficult, like these screen readers, stuff like that. But yeah, if you ever wonder how well your website's performing, make sure to use a tool like this.

[00:06:36]
Let's see if I can also run it on a desktop. No, I guess I can't change it here. Yeah, there are many ways to measure your performance. And you can actually see if the changes that you made have had any impact on your app's performance.
>> Can you explain a little more about static rendering, where you fetch dynamic data on the client side, versus server side rendering?

[00:07:00]
>> Yeah.
>> Are they fairly similar, or?
>> No, so what I was trying to, and I can, I guess, show you the thing here. I think this was the dynamic one, let me just check real quick. So I have the components, I have the listings. So I'm actually using, let's see, yeah, so since I'm using Next.js, it's called automatic static optimization.

[00:07:27]
So any page that we build is static by default. So I am showing these listings, but then these listings themselves use that useListings hook. So what happens is, let me see if, I feel like the network might be so fast that you cannot really see the difference. I feel like I ended up in an infinite loop there.

[00:07:49]
That's always a fun thing with hooks, isn't it? Let's see. Because I didn't, okay. So let's see what the initial HTML contains, if we can see that. Now this has a lot of extra data just because StackBlitz, actually, let's see. Since using, again, StackBlitz makes this hard because it adds so many other things.

[00:08:20]
So there's a big difference between this and server side rendering. So what I wanted to show here is that the entire page still gets statically generated. So if I wanted to maybe show a title here, h1, welcome, whatever, this would still all be generated at build time. The only difference here is that within listings, which will also get generated at build time.

[00:08:50]
But initially, it will just only render this p loading component. Because this listings is false at build time, it's not going to fetch from a React hook at build time, it doesn't run the hooks. So the initial HTML that get returned to the client just has this p loading.

[00:09:05]
So it's not that it doesn't have anything. And then on demand, when it actually does have listings. So in the example I showed here just quick, the p loading would have been like a skeleton component. So maybe instead of loading here, it would have been skeleton UI, I don't know.

[00:09:23]
So that skeleton UI component would be generated or turned to HTML, and that would get built at build time and then deployed. And then only once the useListings hook has fetched data will it actually return those other grids, or the listings grid, sorry
>> Which on server side it's making the API call on the server instead of client?

[00:09:45]
>> Well, it's fetching the data for the listings on the server, but it's not generating HTML on the server, its generating the HTML on the clients.
>> All right.
>> Yeah, it's rendering those listings on the clients. So with server side rendering, the entire HTML gets generated on the client from the HTML body, head, head, head, everything is generated on the client.

[00:10:06]
Whereas here with static rendering and a client side fetch, we still have a lot of components that have been pre-built. Is really just in this case, any dynamic components that need that data, that will be generated on the client dynamically. Thank you all so much for coming to this workshop, I appreciated it.

[00:10:23]
I appreciated your presence here, I hope it was useful in a bit. Yeah, of course, make sure to check out javascriptpatterns.vercel.app, or just pattern.dev, where we have so many more patterns to show you. Thanks so much. [LAUGH]
>> [APPLAUSE]