Rendering Methods Explained

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, Yes. The tastiest web development treats coming in hot. Here is Wes, Barracuda,

Boss, and Scott

Tell.

Welcome to Syntax.

On this Monday, hasty treat. We're gonna be rendering up a really great one for you today. I'm talking about rendering methods, Explained all the different types of rendering methods that we found to be listed on the state of JS survey.

I thought this list was really interesting thing and figured it was a nice thing to dive into and spend some time with, maybe define some these different types of rendering methods and give you an indication as to what's different about all of them because this list is kinda shocking. There's a lot of different ones here. My name is Scott Talinski. I'm a developer from Denver, and with me as always is West balls.

Mister rendering himself? They called me in high school. They did. Yeah.

Most likely to render.

Although that I mean, I guess, it could kind of work in the cooking context as well. I remember having to set my computer to render 3 d video scenes and stuff like that and just have it, like, left overnight and pray that it doesn't stop before your exam is due with a 3 d modeling project.

Oh, man. Yeah. Man, I I wonder if how much faster that stuff is these days. Probably a lot given how How much my video rendering has improved over the years, but that's not the kind of rendering we're talking about. We're talking about HTML rendering. You gotta get HTML to the browser somehow, and there's many ways to do that because most of In in a lot of cases, there is some sort of code, PHP, Ruby on Rails, React, Svelte, JavaScript frameworks generating that HTML, and whether that HTML needs to be rendered On the server or in the browser or it needs to be run picked up in the browser and and rehydrated. So we're gonna, guess we're going to go through the big four here and then talk about some of the other other ones that are on this massive list here.

Yeah. Hey.

Before we get into those, let's talk about, well, no matter what you're rendering, you're gonna need a couple of these services. One of which is an An error and exception handling service like Sentry, and the other is a content management service like Sanity.

We've got both our s Sponsors in the house today, Century being the, perfect place to see all of the errors and exceptions that happen in your website, but also to discover Just how your application is performing. In fact, they now have node profiling on here as part of everything. So you can Really get access to figure out what are the slow to execute, functions or anything in your application. Like, what What exactly is going on server side in your application that could make it slow in various use cases? And it's really super easy to set up With the standard Sentry initialize script, you just install a package. You initialize it, and you just drop it into your normal Sentry install. Bingo bango. You got node profiling built in. You also get performance tracking for the UIs as well. So you can see which of your routes So the fastest and which are the slowest, which are the things that make your website usable and unusable to your users, right, the people who are actually using this thing.

Not only that, but you get access to user feedback alerts. You can build your own custom dashboards, and you can see every error and exception happen on your website, market is fixed, assign it to somebody, or see if it's a regression.

So head on over to [email protected].

Use the coupon code to tasty treat,

And you'll get 2 months for free. We're also sponsored by Sanity. Sanity is the content platform.

And one thing that just a couple days ago, by the time you're listening to us, They've rolled out a new version of Sanity Studio. Sanity Studio is their CMS that is real time. It's built in React.

You can do custom workflows inside of it, so you can see who's editing it, who edited what, when they edited it.

All kinds of really cool stuff. And by the time you're listening to us, just a couple days ago, they had this thing called Sanity Product Day, where they launched Sanity their new version of Sanity Studio, and I'm going to encourage you to go ahead and check out the videos or the docs and everything that they have around Launching of the new Sanity Studio because it is awesome, especially if you are React devs. Some pretty cool integration stuff there. Check it out at sanity.

I0forward/ syntax. That'll get you up and running, on double the free usage tier. But you can also go to sanity. Io for probably this URL will still work, forward slash product day. If not, I'll update the, the show notes with, links to the new Sanity studio, which is pretty cool. Thank you, Sanity, for sponsoring.

Sick. Alright. So this is fun because I was taking the state of JavaScript survey as one does every year, and I saw this Application pattern section where it was all the different rendering methods.

And I thought this has never been broken down, so, I don't know. In a in a way that's so organized just listing them straight out, I'm sure it has. But to me, this was like a really nice way that these were organized. And I figured what we could do Is maybe just start at the top and and give a little bit of breakdown and see these different types of rendering options for how how you're rendering your HTML in your page And what they are maybe in specific use cases. So the first one is a SPA or what's called a single page application.

You know, many people also will call this CSR for client side rendering.

Basically, this is for applications that are built in JavaScript that are running entirely in the browser, so to say.

So this is an application that it doesn't require server side JavaScript or server side, HTML to function. And, typically, this works by you load up React at 1 enter. React or any of these front end frameworks at an entry point, usually like a div with an ID on it. And then that populates The HTML, or I should say it populates the DOM, that the browser can then understand because it's not actually populating real HTML from the server or anything like that. And therefore, you when, you look at the view source of these websites, typically, There's not a whole lot in the body. Right? Typically, not a whole lot of HTML or maybe there's a shell, but you end up having everything being done with the client side JavaScript. It's hitting APIs.

It's pulling in data.

It's rendering it. And this is it's interesting that this is, like, This is number 1 on the list here. This is probably what we consider the least SEO friendly version of this, but also very for building applications that don't require any server side component to them. Right? They don't require that HTML in the DOM, and it gives you in my opinion, spas give you a lot of flexibility with less Headache than dealing with server side rendering hydration or anything like that at the downside of potentially speed performance,

Potentially SEO stuff as well. Next one we have here is Amapa, a multi page application. This is an app that runs entirely on a server With minimal client side dynamic behavior. So, this is probably the type of app that It's funny. The first one was extremely big 3 3 years ago or so, and multi paid application was extremely big 4 4 or 5 years ago. And not to say that they aren't big anymore, but those were sort of the the first 2 big versions of it.

And that is something like like a WordPress website. You go from page to page, PHP will render on the server, Kick out a bunch of HTML on onto the client side. It says with minimal client side dynamic behavior. I don't know if that includes things like, Those JavaScript sprinkles frameworks or not, maybe there's something else in in this list here.

But pretty pretty straightforward.

Server rendered HTML out the other end, and you you wanna submit a form. Well, you submit the data to the form. You come back on the client side,

with the new set of HTML. Yeah. And some people might wonder what's the difference between this and, like, a a SSR setup of a React app or something like that. And I think the distinction here is the the whole minimal client side JS. So you're typically thinking of this being something without a hydration process, and the client side JS is probably going to be done via something like jQuery or, you know, like, little one off things here and there. Right? Next step that we have is SSG or Static site generation. And this is typically you're writing your applications in JavaScript to some degree or Maybe templating languages, and you're running it through a process that then spits out static HTML, Essentially turning the app into a degree of a multi page application because you do have an HTML file for each page.

But in the same regard well, I mean, I guess, an MPA doesn't always have a a single file for each page, but You would have a single file for each page. However, there usually is this dynamic, step of both hydrating your your code here. So it's Usually sending HTML straight up, and then it's loading in the interactivity with JavaScript Typically done through a framework. We've seen many of these use React or Vue or whatever.

And what you're doing here is you're shipping your hard HTML, And then you're getting to utilize the the client side rendering aspects that you have with, normal CSR setups, but you're also getting to You get full on access to whatever those client side routers are, that interactivity you get from a React setup or anything like that. Yeah. I I think probably the biggest difference between the static site generation and the the multi page application is that there's generally no server involved,

With the static site generation, it's all done at build time. It's done on a server. The server generates it, but there's no like, Oh, we need to reupdate the number of items on this page when you refresh the page. No. It's just at that point, it's HTML. And if you wanna make a change To any of the pages, then you must either do it client side, and update it once it's been loaded, or you have to regenerate that Specific page of the website and redeploy it. Totally.

Next up here is SSR or server side rendered, and an SSR site can differ because, It's so funny. A lot of these things you do get you get wrapped up in in what they are, but an SSR site compared to a MPA, an An SSR site in in their definition described here is basically a site with a hydration step. You know, typically, you're using a framework on the back end to generate that HTML on each request.

So instead of that HTML being generated ahead of time, Every single time that request comes in, you are then generating that HTML or serving cached HTML. You're generating. You're sending along, and then there, again, is usually a hate hydration step where that hydration step comes in and re, acclimates the framework to that static HTML, therefore making it a client side app From that point forward where you get the client side rendering and things like that as well.

So server side rendered sites are typically they can see performance benefits, And they could certainly see big SEO benefits because just like a static site, when, robots or spiders, anything crawling this website, it's just gonna see Straight up HTML. It can parse it without having to wait for APIs to, you know, finish resolving. And it doesn't have to Try to crawl this with a client side crawlers, which in my my experience have never been super great. So having that that straight up HTML, And it gives you access to caching at a server side level where you can cache different things. And, you know, that's low key one of the the greatest benefits here is that you get access To making it fully dynamic, but you can also cache the life out of it to make it fast. Yeah. I was gonna say that's probably the one of the biggest benefits Is that you can throw a CDN in front of there, or you can set caching head headers and cache it in your your user's browser.

Some big benefits there.

So those are like the, I guess, the big 4. Maybe this this is the next one is also pretty big. It's starting to become much bigger. It's partial hydration, which is only hydrating some of your components on the client. So not every component needs to be Rerendered in React.

Your navigation, even though you templated the thing out in in React, maybe there's no Dynamic dynamicism in there. You don't maybe you don't need to have React running on that. It may be just regular HTML and CSS for that is fine. But You have another component, which is your contact form or, a buy button that does need to be a sort of updated in it. And that's where things like React server components are becoming very popular to do partial hydration in there. You can sort of opt in To, rendering on the server or updating on the client.

Yeah. Next one they have listed here is Progressive hydration, which I have never I don't think I've used anything considered to be progressive hydration. But the idea here is that You are controlling the order of component hydration on the client. Therefore, you are serving up You're serving up HTML.

Right? And these components that you end up having may or may not be, needing to be accessed quickly in terms of, like, a JavaScript context. So, therefore, you would say, this element Needs to hydrate first, then this one, then this one, then this one. Therefore, making the thing that people are most likely wanting to interact with first, interactive first.

I'm not sure I understand that one. So when you have a hydration step in a web app, West? Yeah. Like, it has to hydrate the entire page or the entire data that it's loading in To make it interactive.

So you the the big criticism of hydration or hydration step in general, there's always a bit of latency between hydration when that start step when that step starts and when people can click on something between that time to interactive and that initial load. That's like the downside of the hydration process overall.

So this would be progressively allowing you to hydrate certain aspects of the site Oh, I see. Okay. Based on what needs They have a shortest time to interactive, therefore, decreasing the overall

time to interactive. The next one is island Architecture isolated islands of dynamic behavior with multiple entry points, in otherwise a static Site Astro and 11 d are examples of this. Do you okay. So entry points in a web app

is or a framework app is typically when you have You're attaching React to the DOM. That's an entry point. You know? Oh, I see. Right. I element on this div. Oh, islands of okay.

Islands of React. So exactly. So with Astro, what you end up getting is you have individual points That need to become interactive serving as their own React applications rather than, you know, 1 big one at the the giant div. Yeah. Yeah. That makes sense. Yeah. Totally. Next up is progressive enhancement. So I don't really get how this fits in here, but progressive enhancement is just making sure that your app works without JavaScript.

So you're serving an application that functions without JavaScript.

You could also just consider that a multi page application, right, because you're just loading up a new page. But, again, this stresses that it works without JavaScript.

One of the things I like about new tools coming out is that a lot of them, like Remix or SvelteKit, they have it, an eye for progressive enhancement that I think the previous crop, was the kind of ignoring, so to say, like, oh, yeah. Who doesn't use JavaScript? And I'm of the same mind. Right? Who doesn't use JavaScript? But at the same regard, yeah, it's kinda nice when your website works without JavaScript too. Yeah. Or Or at least just uses

standards.

Like we the web has standards that for things like submitting data, Returning data.

Yeah. Like all of that stuff.

Like, I I'm definitely not of the player. Like, oh, if you turn off JavaScript and your website is broken, then like what the hell? Like, obviously Yeah. You remove a 1 third of the the browser.

Obviously, it's not gonna work.

Yeah. But also, like yeah. Isn't it nice when it does just work because you are using standards and being just posting to a URL with some form data or some JSON.

It does just work. So

I'm very excited to see these frameworks. We've all learned from history here. If you remove one member of Blink 182, it's really not Blink 182 anymore.

And it doesn't work as well. And so if you remove one of the 3 core members of the web, like, I don't know.

People people talk s h I t about JavaScript, but I'm sure they did about Tom DeLong as well, And, we don't know when he was gone.

Next one is ISG, incremental static generation, which is being able to dynamically augment or modify a Static site even after the initial build. And this makes a lot of sense.

Gatsby does this now.

Next. Js does it now, which is basically, the Syntax website does that.

You visit Syntax website, and in the background, We will regenerate that page, for the next person that comes around. And then the next person gets the static version, but then we'll regenerate it again for the next person. And That's really nice because you get the benefits of static without having to do it all at build time. So you sort of do it

incrementally. That's why it's in the name. Yeah, A lot of these are named really well. You know, some of them get a little tricky when you're you're talking about things like islands, architecture, or whatever, because then you gotta, like, understand the concepts and pros and cons and stuff.

Next step is streaming SSR, which this is something that yeah. It's it's interesting. You're basically instead of Sending your HTML down the line. You're you're breaking down the server rendered content into smaller streamed chunks using streaming.

It it sounds like a a viable method of making it more performant, but at the same time, it also sounds scary in terms of, Messing something up in some step of there. I mean, SSR and hydration is already no fun. So, it'll be interesting to see if you see more Streaming SSR setups becoming

the regular over time for SSR. Next one we have here is resumability.

You serialize the framework State on the server so the client can sort of pick it up from there with no duplicate duplicated code execution.

I think what they mean by this is, like, if you have your initial state that's generated on the server, Instagram does this, TikTok does this. If you view source on pretty much any big JavaScript website, You'll see a big object dumped into the HTML, and that object has your initial state. And that's sort of They'll they'll grab all of the stuff that they need without having to do, like, a load and then a fetch because That could be pretty slow. They'll sort of just give a harrion. Well, here's the here's your initial data, your initial state. Throw that in a Redux store or some some other state management, and and sort of pick it up from there on the client side. That's a pretty popular

one right now. I'm not sure. It so when I read this, I was thinking quick.

So quick describes itself as resumable.

Oh, really? Yeah. And so the way they we talked about this a little in the quick episode. I think what you're talking about is something that people do, and and that's how, like, Hello. Does their data resumability, and I do think that is called resumability.

But I think what maybe this is referring to is the fact that You don't need a hydration step to make your application functional JavaScript wise after sending SSR to HTML.

So, this is a kind of a nuanced thing because we talked about this a bit in the quick episode, But what you're doing is you're sending HTML with JavaScript that works instantly rather than needing a hydration step that I need to, like, reconnect everything to the client side framework version of this.

Oh, I remember this. Okay. That's pretty cool as well.

Yeah. It's cool, and it's a great idea, but at the same time, it's kinda hard to to grok when you're you know, I don't know. You're thinking about all this stuff. Maybe you wanna take edge rendering because I don't know anything about edge rendering.

Edge rendering is, I was just showing Scott before the show, Altering rendered HTML at the edge before sending it on to the client.

So This is either intercepting some existing HTML and and rendering it, or more likely is, Like rendering it right at the edge. So Adeno deploy does this.

They will render out the HTML for your request Right at the edge, meaning that it's it's running at the server that's closest to your house.

And and because of that, it will be as fast as possible.

And I was just showing Scott how quick that could possibly be because I was just I was like, watch, I'm going to add it. I'm going to commit it. That was fun. Once it was live, I was like, alright. Refresh. It was immediately there, and it was just I I couldn't believe how how nice and quick that was. Actually, do you wanna tell the the real version of that story, Wes? The 1st time you told me to refresh it didn't didn't work. And I was like, it's not working. And then, like, a minute later, I'm like demo. Oh, I forgot to push. I, like, committed it, and I was like, okay, go.

And then it it didn't work. So what is such a letdown?

I love it. It's like it is the quintessential

web demo. Yeah. One thing they didn't didn't put in this list, and I don't know which where that fills into, is Alpine JS, Stimulus, LiveWire, where you render out HTML in whatever templating language you you want to use, and then you you just add sprinkles to JavaScript where you need it with Alpine Stimulus, LiveWire, Hotwire, those things.

I don't or or even just like like where's the render HTML and put jQuery on top of it or vanilla JavaScript on top of it. That's an app. That's multi page application. Multi page with minimal client side dynamic behavior. I guess that makes sense. This kind of map And maybe islands? Or progressive enhanced.

Yeah. Could be progressive enhanced. I would just call that a map. I would call that a multi page application because I I don't think there's any current link. That's that's How we were building them for 10 years before all this

all these acronyms came along. Right? It used to just be render some HTML, Add some JavaScript on top to add your interactivity, and you you call it a day. Can I just get a regular regular ass website here? Yeah. And then this popular

stuff. Yeah. Can I get a web flavored website, please?

I I think we should have the, Caleb from Alpine JS on. I think that's very interesting.

There's something happening, obviously, right now. The fact that we have an entire episode with Fifteen different ways to render your application.

Something's happening right now, and I think that we're gonna hit on a couple of really good ways, If if we don't already have a couple good ways, but I think a lot of this is changing right now. We've got, Remix is becoming really popular. React server components is starting to Become a popular approach. People are swinging back to the server like crazy.

These JavaScript sprinkles ones are becoming very popular. So there's there's a lot here, I think. It's funny because there I I do feel like there are very specific instances in which a SPA would actually be the most useful one of these.

It but at the same regard, I think everybody went so hard in the SPA land that they were like, Oh, wait a second. This is actually a good technique for a specific type of website, not a good technique For every website.

And I I distinctly remember a moment in the this is funny. In the meteor scene When the recommended Meteor router went from a server side based router to a client side based router, and I personally never understood why That became the the thing. I was just like, oh, wait. We're not thinking about the surfer anymore.

That feels weird to me instead of thinking about, You know, now we're thinking about the client. And and from there on, it was, like, almost like that that was the way to do it. But spa's super valid still. There's you know, it you have to understand, like, what is your goals and outcomes of from the site. Like, who are you trying to reach? You know, what what's your target with the site and then make those decisions accordingly.

But, yeah, it it does feel like 15 different ones is. The SPA one is interesting because we always hear from people saying, oh, yeah. I'm just building a SPA because I don't need SEO or server rendering or or any of the stuff they said. Like, If you were building, like, yeah, internal tool, would you would you think you'd still just go SPA? None of this

server dance? I don't know because to me Getting the data from the the API to the the website still is kind of a pain that way. You're still just doing straight up Fetch calls and stuff where with many of these now integrated frameworks, Remix, Feltkit, any of that stuff, the way it's more integrated, It it's way easier to get that data directly into the component without doing straight up fetch calls.

And, honestly, I wouldn't wanna do just straight up fetch calls In my application today, but, you know, I don't know.

I I do think that is extremely valid. And I I I very well may pick that strategy because there really can't beat the speed of working in a SPA compared to A server side framework where you have all these exceptions and, things you have to figure out and reintegration issues and even just, You know, I had a web components issue where the web component was rendering, in our server side stack, but then I needed to then reinitialize it.

And then on top of that, you know, like, getting access to the same sort of things. I I have found there are instances where a server side web application Could make your life so much more difficult, for those benefits.

But if you need those benefits, you gotta pick something that makes, You know, that possible. Awesome. I think that's it for rendering. Let us know what your thoughts are on where rendering is heading. Tweet us at syntax f m. I'd love to hear your thoughts on this. Absolutely. Cool. We will catch you on Wednesday.

Peace.

Cast player, or drop a review if you like this show.