Hasty Treat WTF × SSR vs JamStack vs Serverless?

Monday. Monday. Monday.

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, the craziest, the tastiest web development treats coming again hot. Here is Wes Barracuda Boss and Scott

CSD.

Welcome to Syntax.

On this Monday, hasty treat. We're gonna be talking about server side rendered, websites. We're gonna be talking about Jamstack. We're gonna be talking about serverless, WTF, SSR, Jamstack serverless SSG, any of that stuff here. We're just gonna be shouting off letters.

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, is Wes.

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,

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, excited to dig into this.

Sick.

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

LogRocket is the perfect place to see all of your errors and exceptions happen in your site in a video replay.

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.

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, 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.

But a lot of the new features where you're you're testing performance, it. You're testing, customer engagement and and, 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.

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.

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 Your API hooks up to Amazon s 3, Firebase, GitHub, Google Sheets, GraphQL, Lambda, MongoDB.

It hooks up to literally any data source, not any, but they've got Tons and tons available that it can hook up, 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 view files that are in your Amazon S3 or take a look at Your GitHub repo.

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 my internal tools because, man, it seems like they have templates for everything. They've got integrations with You name it.

Tons of different databases, tons of different APIs, Basecamp, Firestore, GitHub, Jira.

And then they have lots of templates for common things that you might wanna do, refunds, charts, CRM, a Slack notifier. You name it. You you get the point. Right? You wanna check it out at retool.comforward/syntax, And you can try it for free at that URL. Thank you, Retool, for sponsoring.

Sick.

Okay. Let's get going.

And like we said, we're gonna be talking about server side Jamstack and serverless.

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.

My question is, what exactly is server side rendering versus tech like Jamstack or serverless? 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 Momo eyes? 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.

Alright. So, I I thought, like, let's explain 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 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, what they are. And then, we'll dig into, like, what are the differences. And, like, with everything, 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, I think, 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 Happens at build time, and then the value of that build, whether it most likely it's gonna be Exported HTML or smaller images or generated images, 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 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.

And then anything that is on demand or anything that is dynamic. Like 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 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 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

as in these things are generated at build time. They're kept into HTML files. Those files, 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.

So, well, let's talk about SSR then, also known as server side rendering, 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 is maybe using a a JavaScript framework. Maybe it's using React, Svelte, Vue, whatever.

And it's taking all of the data, the API calls, and doing all of that on the server rather than in the browser, and then spitting out an HTML response that the website then receives as straight up HTML.

So, the cool thing about that Is that if those pages kind of remain unchanged or even if, that content is always going to be that content for the user, you can cache that stuff really easily.

Therefore, it's not going to have to do the work every single time you're hitting that request. It's just caching it.

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 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.

The good thing about this is also with SEO. Right? We we've talked about this sometimes where 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,

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, application out there. And generally, what happens is that somebody hits the URL.

That URL goes through the Apache server. The Apache server then passes that over to the PHP process. The PHP process looks it up, says, okay. I need the last 10 posts. I need, 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, 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.

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? 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, Static site generation is even if that is slow, it can happen beforehand. You can do it, I don't know, Tuesday. And then when somebody comes and visits your website on Wednesday, it's already done right. That that work has already been done rather than having It'd be like instead of being on demand, right? Yeah.

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, 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 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, 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.

But like Scott says, you can.

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 for 1 of your 10,000 users to take a second and a half to wait for it to render. And then the next 99,999

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.

What's the the image one? 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,

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 I'm not. Oh, we should also say, like the other benefit of SSR instead of the client rendered is sometimes Jamstack websites Are not pre rendered at all. Mhmm.

They are simply just serving a div in the HTML.

And then you load your JavaScript and then your JavaScript renders out to that div on the page and then your JavaScript fetches your data and like 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.

So the question is, what's the difference? Why is The swing back. I think the biggest reason is that people were sort of hitting limitations in terms of, okay. I like this pre render thing. I like caching my data. But some of the pages I don't want to 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 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,

anytime there's, like, information on the page that's dynamic to the user, You know, static information there isn't necessarily, 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, 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? I don't know. I'm sorry. Spanish speakers, I'm not very good at Spanish. But, okay.

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 is getting way easier.

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 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.

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, you know, now we have so many tools that make it way easier. I mean, Next. Js, Remix is all server side, really, a SvelteKit.

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 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

pre rendered all the stuff. And then, we also people are like, oh, it was kind this was kind of easier on SSR or or even like 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 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, 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 Much easier to sort of get the best of both worlds, which is is ideal.

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

So, like, where does serverless fit into all of this? Serverless fits into all of all of them. Right? Serverless is not a jamstack thing or a server side rendered thing.

Serverless can pre generate your jamstack website with the benefit of that is You only pay for the build time, 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, for your app or something else, you can you can still hit that. Serverless would host that.

Serverless can be, your SSR generator, it could just be called serverless side rendering because you can you can run a code in a serverless function, and you can render out your HTML in a serverless function.

The the only difference between serverless and server, 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, It's much easier to scale it up. Like for example, my sticker website.

I threw a ton of traffic at it for 3 days. And then for the rest of the year, I am not going to do anything for that. And if if that application. It's a it's a traditionally hosted node application. So I would be paying $25 a month 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 for the that huge Spiking traffic for the 3 days, and then I would probably turn on caching for the rest of the year, and then I would pay pennies just to keep the website alive, until it was necessarily needed again the next time I have a bunch of stickers. So that's a really good instead of paying, what, it. $200

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.

And it's funny because I think he had a really great outlook on this was, it. Like, really, the ideal scenario for building any of these things to be as fast and and flexible as possible is it. For all of your static pages to be statically rendered and and have them be cached as HTML. Right? Your homepages, 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 and exist in a very fast way where then you would have dynamic pages as in the, 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 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.

You have your carousels, your interactivity, your client side routing, those types of things. And so in those kind of cases, the, SSR with hydration is probably the best way to go. So the ideal tool should be able to easily give you prerendered pages, 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, 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,

it will when somebody hits the actually, it goes even Further, where if you hit the website, it will serve you up a cached version. But then in the background, it will regenerate The most recent version for the next guy that comes to the website.

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 and Wednesday to regenerate the website, we basically just say 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.

60 seconds or I guess that's the same thing. Every 30 seconds, the the entire website will regenerate, and then the next person that hits the website will get the, newest version of that. So you're again, best of both worlds there. You're getting a precached version when you hit the website. But then behind the scenes, we are also running the, the regenerate of the home page because there's a possibility that there has been a change to the show notes. There is a new episode or something like that. And then also 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 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, 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, and then you a year down the road, you go, oh, I us. Kinda need a bit of dynamic dynamicism, you know, dynamicism.

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, CS. You get that, shoot kind of feeling in your especially with Gatsby, because Gatsby makes you, Go all in on their GraphQL layer.

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.

But now as I've asked before, you can do either of those, which is kind of cool.

So thank you, Evan, for submitting that question.

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.

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

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