Hasty Treat WTF × SSR vs JamStack vs Serverless?

renders out to that div on the page and then your JavaScript fetches your data and like via an API on the client side. So once the website loads, then you go and Hit some API. Get back. Okay. There's 11 shoes left, and then put that on the page. You may often hear many of what, like, Wes is just describing as something statically generated then you might not necessarily need to. I think the frustration comes from people saying, I'm gonna go all in on this static site generator, dynamicism.

I don't want to for the rest of the year, like you don't have to make an API for literally everything. Like, Sometimes you just want to read a file off the file system

So, like, where does serverless fit into all of this? GitHub, Jira.

These things make it so easy to do server side rendering that you hardly have to think about it just besides, like, knowing which APIs will work in the browser and which will work in the server, that type of deal. Either way, the tools have evolved with us and are now made it almost almost

okay.

is getting way easier.

it. It's really good for speed and performance. With client side rendering, it's really good for dynamic content. And then with server side rendering, you kinda get the best of both worlds in many different ways, which is kind of why it's swinging back. But I think the That that meme of the girl, why not both? Yeah. Why not both?

and then use that to render something out to to the server. Right? Like, you don't necessarily if you want it to hit the browser,

anytime there's, like, information on the page that's dynamic to the user, You know, static information there isn't necessarily, HTML files. Those files,

It's getting way easier to ship code it to the users in a server side rendered manner than it was, I don't know, even, like, 2, 3 years ago. I've personally ran a site with a custom

limitations in terms of,

Server side rendering setup where I had to do the whole render HTML to stream and all that stuff and and serve up a server side rendered sites myself. And guess what? It sucked. It was really hard.

have rendered beforehand. I need them to be rendered as soon as somebody lands on that page. So So if that was the case, then you have to, like, kinda Like we never left server side rendering, but it's becoming more and more popular to render on the server and render on demand. So Let's dig into what these things are so you sort of understand,

like, if you have a statically generated page, you can't have statically generated pages for users. It. Especially if you have many users, that's going to kind of be impossible to manage, not to mention a giant security risk if you have a public HTML file for each it. Users page. Right? That doesn't that doesn't necessarily crack or make sense. Right? Yeah. You're right. Yeah. So, you know, you you end up having these issues where, you know, with the static site rendering,

let let's go into the next one. I think we're already kinda hitting that. It's like, what's the difference? Like like, why would you use 1 or the other, or why are Are we starting to see and this is not everybody. Absolutely. There's huge websites on both of these, but we're starting to see a bit of a trend of people going back to SSR and

we also people are like, oh, it was kind this was kind of easier on SSR or or even like 10,000 users to take a second and a half to wait for it to render. And then the next 99,999 some of the pages

Much easier to sort of get the best of both worlds, which is is ideal.

you know, now we have so many tools that make it way easier. I mean, Next. Js,

No reason to not do server side rendering if you have the option to because it just doesn't take that much effort. So I think that's that's a really good example of, like, we sort of started with Jamstack and

They are simply just serving a div And then you load your JavaScript and then your JavaScript

the client rendered is sometimes of SSR instead of to host that thing When really I only needed it for 3 days. If that if I were, like, ported that over to serverless, I would just pay I'm not. Oh, we should also say, like the other benefit

I don't know. I'm sorry. Spanish speakers, I'm not very good at Spanish. But, easily give you dynamic SSR, and easily give you SSR with hydration, all at your choice. And I hate to be that guy, but it's felt good. Does all of that very well. So, Therefore, it's not going to have to do the work every single time you're hitting that request. It's just caching it.

pre rendered all the stuff. And then,

We'll go into that in just a second, but let's just talk about serverless.

You name it.

and then you can go ahead and just start clicking together and building these inter internal tools. So Whether you need to get some stats on your sales or process refunds or And you can try it for free at that URL. Thank you, Retool, for sponsoring.

am ready to talk about this just after we get to talk about 2 amazing sponsors here. Those sponsors are LogRocket and Retool.

Welcome to Syntax.

man, it seems like they have templates for everything. They've got integrations

LogRocket is the perfect place to see all of your errors and exceptions happen in your site in a video Remix is all server side, really, a SvelteKit.

at retool.comforward/syntax,

a Slack notifier. You name it. You you get the point. Right? You wanna check it out beforehand. You can do it,

Monday. Monday. Monday.

But a lot of the new features where you're you're testing performance, Sign up today and get 14 days for free. This is such a awesome offer and an awesome service. So thank you LogRocket for sponsoring.

the tastiest web development treats coming again hot. Here is Wes Barracuda

It allows you to see these errors, like, literally see what the user did when they click the thing and broke the thing, and then you can even, like, check out the console.

Okay. Let's get going.

with

Tons of different databases, tons of different APIs, Basecamp,

websites. We're gonna be talking about Jamstack. We're gonna be talking about serverless, WTF, SSR, What exactly are the advantages, and why is everything swinging it back to the server side rendering now. I keep saying the server side rendering. So, just just remove the the in your brain there. Just server side rendering. And this person also says, p s, every time you say the word

The Wes West, something boss. I was gonna come up with some sort of nickname on the fly, but West, the boss, boss always works for me. How's going, West? Server boss. Yeah. It's Going pretty good. Pretty good. We got this question in from, SSR with hydration is probably the best way to go. So the ideal tool should be able to easily give you prerendered pages,

Cool. Well, I,

it. You're testing, response that the website then receives as straight up HTML.

new features in LogRocket recently that all Come around the idea of user experience just like with the errors. Right? That's all about user experience.

Jamstack serverless SSG, any of that stuff here. We're just gonna be shouting off letters.

view files that are in your Amazon S3 or okay. I like this pre render thing. I like caching my data. But And that can be very, very fast, But it can also be very, very slow. And this is not WordPress specific. This is just any database. Anytime you're doing a bunch of stuff. And that's that was the huge benefit to, But that can also be very, very fast, right? You can be very smart about things. And like Scott says, like Like, I on my my sticker website, I was updating the number of stickers,

customer engagement and and,

On this Monday, hasty treat. We're gonna be talking about server side rendered, It it broke all the time. There was a lot of errors, especially with re React saying that the the server side HTML does not match the client side HTML, and therefore, hydration is broken. Right? So it was never very easy is really what it came down to. So people would just do client side rendering because that was the the easiest way to get up and running, really, And the easiest way to do it and you might have said, okay. I can sacrifice some SEO stuff here or whatever. But, Momo eyes? And don't forget to subscribe in your podcast player or drop a review if you like this show.

It. You can get more information. You can check out the network requests. I mean, isn't it wouldn't that be amazing to see the network requests of it. An error happening on your website. But not only that, there's a a ton of new,

the craziest,

I'll start by reading out the question first. It says, my question is about a recent trend it. Towards the server side rendering for many things in web dev. I started learning web development more recently when the jamstack and serverless was all of the rage. So that's why I natural so that's what I naturally went to. However, that has seemed to have changed recently, and everything is now swinging towards the server side rendering.

Sick.

Boss and Scott

Sick.

CSD.

Open wide dev fans, get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest,

excited to dig into this.

You can build internal tools with the data that you need. This is really, really cool. I kind of wish that I had this when I was building

is Wes.

the user generated stuff, the stuff with user accounts, all of that stuff would be SSR. Right? Because that that is going to be fast. It's going to be

shoot kind of feeling in your especially with Gatsby, because Gatsby makes you,

Serverless can be, Static site generation is even if that is slow, or smaller images or generated images, for 1 of your

for the that huge Spiking traffic for the 3 days, and then I would probably turn on caching it will when somebody hits the actually, it goes even Further, where if you hit the website, it will serve you up a cached

a month

And as soon as you needed to update in the browser before Gatsby 4, then you had to Step outside of the GraphQL later. And that's a huge benefit to Gatsby is that it has a whole GraphQL API. All your data is in this nice thing.

and exist in a very fast way where then you would have dynamic pages

So thank you, Evan, for submitting that question.

necessarily needed again the next time I have a bunch of stickers. So that's a really good instead of paying, what, it. $200 let me go ahead and start to template this thing out. Let me loop over the post. Let me render out the navigation. Let me put a list of tags in the sidebar. Let me slap the footer on.

until it was

or something like that. And then also

Your blog posts, your your about page, any, like, text content that's not dynamic or or whatever. Those things could be just straight up HTML

dynamicism, in the HTML.

for your app or something else, you can you can still hit that. Serverless would host that.

You have your carousels, your interactivity, your client side routing, those types of things. And so in those kind of cases, the, replay.

Serverless can pre generate your jamstack website with the benefit of that is You only pay for the build time,

SEO friendly. It's gonna be happier, essentially, as being a server side rendered thing if you have that that user or that dynamic content. But then you also have dynamic content in terms of, like, JavaScript based content.

and then you pay for super cheap, just straight up CDN hosting. That's that's really nice to be able to do that. Serverless could just host your API. Like, if you have, like, a static site, but then you still want to be able to have a couple of things that are dynamic, you might have an API for, Happens at build time,

The most recent version for the next guy that comes to the website.

It's much easier to scale it up. Like for example, my sticker website.

Go all in on their GraphQL layer.

Serverless fits into all of all of them. Right? Serverless is not a jamstack thing or a server side rendered thing.

And the reason we do that is because we don't want To have to set up a cron job to run at 9 o'clock every Monday because you can you can run a code in a serverless function, and you can render out your HTML in a serverless function.

and then the next person that hits the website will get the, you know,

a month to host host the thing. Right? Mhmm. Probably doesn't need to necessarily be on a $25 droplet, but You get the point. So, yeah, I wanted to talk about, like, what the ideal kind of scenario would be. It's funny because I kinda talked just it. Very briefly on Twitter with Rich Harris about this the other day.

that there has been a change to the show notes. There is a new episode your website on Wednesday, it's already done right. That that work has already been done rather than having It'd be like instead

when you hit the website. But then behind the scenes, we are also running the, I don't know, Tuesday. And then when somebody comes and visits Your GitHub repo.

node application. So I would be paying $25 and Wednesday to regenerate the website, we basically just say

version. But then in the background, it will regenerate That URL goes through the Apache server. The Apache server then passes that over to the The swing back. I think the biggest reason is that people were sort of hitting your SSR generator, it could just be called serverless

CS. You get that, Regenerate every I forget what it is. I think it's every minute or so, and it's it's dirt cheap to do that.

and then you a year down the road, you go, oh, I us. Kinda need a bit of dynamic So the question is, of being on demand, right? Yeah.

for building any of these things to be as fast and and flexible as possible but yeah. So I I personally think that is The ideal too. Right? Because the stuff that's not changing, it can stay as HTML, can stay very fast, and the stuff that's dynamic can get server side rendering done where it needs to be. And the The syntax website is actually a really good example of this as well is that,

the regenerate of the home page because there's a possibility

Yeah. No. Yeah. I don't know if that's a word, but I I'm here for it. Yeah. It's nice to have the option. And that's that's why Gatsby has rolled it out because people were saying, like, yeah. Like, of course, I need this static site generated most of the time. But as soon as you need it once, We are also sponsored by Retools. This is, one of the coolest sponsors I think we've ever had, and they are a visual builder for internal tools. So what does that mean? Well, it hooks up to Either of those, which is good. Remix does that. And then there also is a handful of static site generators out there that don't do that because There is still benefits like we talked about earlier. If you don't need dynamic,

is it. For all of your static pages to be statically rendered and and have them be cached as HTML. Right? Your homepages,

60 seconds or I guess that's the same thing. Every 30 seconds, the the entire website will regenerate,

And it's funny because I think he had a really great outlook on this was, it. Like, really, the ideal scenario

for the rest of the year, I am not going to do anything for that. And if if that swing to the oh, yeah. Okay. I have to do that part in the client because I can't do that on demand. Right? As I say, this is often that's often with, like, user accounts. Right? User accounts, CRM, Firestore, It hooks up to literally any data source, not any, but they've got Tons and tons available that it can hook up, it. What that is is you render everything at build time. It's still done on a server. It's still done with a node process or, Yeah. Let's talk about node. Like, we're assuming that it's a node process, and it still happens on the server. But generally, the Jamstack website side rendering and then I would pay pennies just to keep the website alive,

I threw a ton of traffic at it for application out there. And generally, what happens is that somebody hits the URL.

3 days. And then

The the only difference between serverless and server,

as in the,

the thing is, like, okay, like, if you want to show how many items are left, That needs to be updated constantly. Right? So then that would have to happen And then they have lots of templates for common things that you might wanna do, refunds, charts,

is maybe using

Cloudinary. Yeah. Oh, Cloudinary. Yeah. Okay. So for some reason, I said Cloudinary, it, like, just did not seem right in my brain. That's cloud, man. Like Cloudinary or Mux do too. So mux for video, Cloudinary for photos or video where, like, the initial user that is loading it, that's when the transcoding or the the a compression or the image format change actually takes place, then that result is cached. Then every single person who hits that afterwards is gonna get a much faster load time. So,

which is where the rendering is done on the request generally. So what that means is the user, they they type in your web address, they hit enter, And then that request heads to your server. Your server

it? It's loading a ton of assets, a ton of JavaScript, a ton of images, whatever, and then it's having to make API calls on demand, hit those get that data it back and then redisplay the data. You're waiting on some stuff. But if if this is a a request that's been cached and this is Always going to return the same thing from the server. That can be exceedingly fast.

PHP process. The PHP process looks it up, says, okay. I need the last 10 posts. I need, Jamstack websites Are not pre rendered at all. Mhmm.

as in these things are generated at build time. They're kept into

like, why it. Might be slow. Is that like it has to let's give WordPress for an example. WordPress is probably the most popular server side rendered, You don't necessarily always have to make an API for us. Another benefit to Chassis are in. Like Scott says, they are these frameworks are getting a listener, and I thought this is sometimes these questions are like they're too good, And you can't just answer it on a potluck. You gotta devote an entire episode to it. So,

and then spitting out an HTML

the cool thing about that Is that if those pages kind of remain unchanged or even if,

it can happen

So,

smaller JavaScript bundles. All those values are cached. So it's done When you deploy the website, it's done sort of ahead of time, and then the the sort of there's all kinds of benefits to that, but the the huge benefit of that is that it's it's very fast. It's very secure because you don't have anything that could

Sometimes it's fine. I think the reason why People are moving back to SSR is that it can be very fast, and sometimes it's not a big deal it. Like a traditional server is that you can with serverless, you can scale up much easier. There's a couple, obviously, a couple more differences here and there, but,

So, well, let's talk about SSR then, also known as server side rendering, heat maps and travel paths and stuff like that, it. All of that stuff and more on LogRocket. So check it out at logrocket.comforward/syntax.

You know, because the way browser the browser works, if those HTML files are unchanged, the browser can cache them really quickly. I mean, these sites Have the possibility of being very, very, very fast.

And then when that's all done, then it runs it through any and plug ins that it might have. And then finally, it kicks it out the other side of the door. Right? my internal tools because,

change. It's just HTML being served up. At the end of the day, it's very easy. It's very cheap to host that.

What's the the image one?

But like Scott says, you can.

This is really good because what The browser browsers are really good at reading HTML very quickly. Right? Yeah. Typically, when you hit sites that are slow, it's because

Exported HTML

web crawlers, they can occasionally do it. Client side rendering versions of your site and understanding of the SEO. But in my personal experience, it's never been nearly as solid as a server side render or a static site. I would not it. That my business on them crawling client side JavaScript. Totally. Our our SEO scores all took a major dive When we moved to fully server side rendering for a little bit before we did SvelteKit. We should explain a little bit more about, people Get it really fast because it's it's being cached. Right? And that's the same philosophy that, like, applications like cloudinary or not cloudinary.

that are were left every single render. So I was not Cashing a single thing. And I was getting, I don't know, thousands of people

And it's taking all of the data, the API calls, and doing all of that on the server rather than in the browser,

The good thing about this is also with SEO. Right? This ain't Wordle. This is syntax here. My name is Scott Talinski. I'm a developer from Denver, Colorado. And with me, as always,

that content is always going to be that content for the user, you can cache that stuff really easily.

a list of pages. I need the navigation. So queries all those things that it has, Then it gets the data back, and then it goes into templating mode. It says, alright. Now that I have my data,

a a JavaScript framework. Maybe it's using React, Svelte, Vue, whatever.

an example, I get this question a lot. People on Instagram always say, like, would You use Jamstack for, like, e commerce and things like that. And

We we've talked about this sometimes where

And then anything that is on demand or anything that is dynamic. Like take a look at as it needs it. And that can be a little bit that can be very like the initial load could be a little bit slower. But then after that, everything is really fast because you're just Kind of clicking around and all the assets have been loaded as well.

My question is, what exactly is server side rendering versus tech like Jamstack or serverless?

Alright. So,

I I thought, like, let's explain what's the difference? Why is what these things are. So he's asking, okay, well, like, I started with Jamstack and Serverless, and now you're now we're saying that things are becoming hitting the website at once. And every time they hit the website, then it would just rerender. And that was very because there wasn't a whole lot. It just hits a database, gets account,

Memo eyes, I think you spelled it wrong. Yep. On the podcast, I have a good chuckle because it sounds like a little little kid trying to say the word memorize. Memo wise. To memoize it. Yeah. And so that's what my daughter would say. Definitely.

Like, these things are never set in stone. Everybody's approach to building apps and websites can be a little bit different. There's not a cut and dry. But generally, with Jamstack, newest version of that. So you're again, best of both worlds there. You're getting a precached version But now as I've asked before, you can do either of those, which is kind of cool.

I think,

and then the value of that build, whether it most likely it's gonna be application. It's a it's a traditionally hosted then we pick it up in the client. We pick up the entire website in the browser, and then it becomes a browser How's your application? Because you want to be able to read the show notes and play the, play the actual episode and click through from page to page without interrupting the the The m p three that's currently playing. So, again, another really good example. Let's go through them real quick. You said SvelteKit obviously does that. Next CS does that. That's what the Syntax website is doing on it. Gatsby, as of Gatsby 4, does that. Or you can opt into we'll dig into, like, what are the differences. And, like, with everything, then then renders out the the template and spits out the HTML on the page. Right. But then that can also be that can be slow as well.

what they are. And then, Your API hooks up to Amazon s 3, Firebase, GitHub, Google Sheets, GraphQL, Lambda, MongoDB.

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

Head on over to syntax.fm I think the big one of the big reasons is that it's swinging back is that server side rendering for these Clients and frameworks that we all love and use

for a full archive of all of our shows, And like we said, we're gonna be talking about server side Jamstack and serverless.

That was such a good question. We turned it into a whole show. Anything else to add in here, Scott? Nothing for me. Yeah. No. I think we really, covered all the bases really well. Beautiful.