Hasty Treat - Turbolinks + Server Generated HTML + JS Sprinkles

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 in hot. Here is Wes Barracuda Bos and Scott El Toro Loco

Welcome to syntax.

And this Monday, hasty treat. We're gonna be talking all about Turbolinks. It's turbo dime. Oh, that was terrible, Arnold. I usually feel like I'm pretty good at that. It's turbo time. We're gonna be talking about Turbolinks and server generated HTML, plus some j s sprinkles in there. I love that you wrote j s sprinkles in this episode title Wes. My name is Scott Tolinski. I'm a full stack developer from Denver, Colorado. And with me as always JS Deno Wes, boss. Hey, everybody.

Hey, Wes.

Yeah. So this episode, we're gonna be talking all about Turbolinks.

At the time we recorded this episode, the Hey.com has sort of just launched, and it made a big splash with their usage of primarily server rendered HTML and usages of things like Turbolinks to really make sure that the experience feels fast and modern. So we're gonna be talking all about Turbolinks, what they are, who uses them, what just a little bit about the ins and outs there. This episode is sponsored by Prismic, which is a really, really cool content management system that we talked about in our CMS roundup episode

JS well as they have sponsored quite a bit of Syntax. So, Wes, with a little bit more about Prismic, do you wanna dive in? Yeah. So if you want a super quick up and running back end that allows you to create all of your different kinds of inputs that you want, Prismic is for you. So the way it works, you create a project, then you go ahead and create your data types. And then for each data type, maybe, like, a person, maybe a store, maybe a pizza.

For each of those pieces of data, you can say what what fields you like for each, and there's all kinds of different fields. They have a really nice WYSIWYG field, number input fields, plain text input fields, image upload fields, all of the all of the good ones, and you can sort of click together an entire back end. Then once you have all of your data, you can bring that in via their Wes API or their GraphQL API. It hooks up to Gatsby effortlessly. Like, I bet you could get a Gatsby site up and running with Prismic in under half an hour. Or if you just clone their demo, it will much less than that. But from scratch, I bet you could do it under half an hour. So if you have a project, check it out, prismic.i0forward/syntax.

They also have a really funny landing page, so you wanna check that out. Thanks so much to Prismic for sponsoring. Alright. Let's talk about turbo links. So, like, what is it? So, essentially, if you think about, like, how popular apps are made right now, a lot of them are built where you go to the page. That page will request a bunch of data via an API, whether it's a Wes API, whether that's a GraphQL API, and then you'll use something like React or any other framework to render out all of that in the ESLint, or you you render it on the server and then you pick it up on the front end. You render everything in your JavaScript library. So the idea with Turbolinks is that all of the HTML is generated on the server.

And then when you need an entire page or a part of a page to be rerendered, you you still ping an API with JavaScript.

But instead of it returning you JSON, which you then go ahead and template out, what it does is it just returns to you HTML from that API directly. And then you take the HTML and you dump it into the page. So a really good example of this is GitHub JS primarily built in Turbolinks.

So if you want to go from 1 page to another on GitHub, you'll often see you get that little bar over the top that sort of animates its way across as you're you're going from 1 page to another. And what is generally happening there is that it says, okay. Someone wants to go to this page.

Let me first request the HTML. It comes back, and then we replace the entire page's HTML. So rather than doing a full page reload, it just swaps out the HTML of the page sort of behind the scenes, which is kind of cool. You can also use it just for parts of the website. So if you wanted to rerender a comment on GitHub or something like that, you could ping the API, and it'll bring back a list of that comment or all of the comments. And it won't return you an array of comments. It will return you the actual HTML, which you can just then stick directly into into the DOM with your JavaScript. So it's pretty cool. And there's sort of, like, 2 pieces of JavaScript that are needed for it to to work, and then we'll talk about, like, what about if you need to still need some JavaScript? Like, this is not this is not just websites that have no interaction in them in their full page reloads, but sometimes you still Node, like, a widget or a gooey or something like that to pop up. So how do you do that? So the way that it works is that you you run this Turbolinks JavaScript on your website, and then you have just regular anchor links from page to page. And then when instead of it actually reloading the page every time you click on a regular anchor link, it will prevent default. And then it behind the scenes, it will go ahead and fetch the HTML from that page, come back, and swap it out right in place for you. And that gives you it gives you that same, like, fast refresh feel that you get with a React application, but the benefit of it being rendered entirely on the server.

It's funny. When I hear some of this, I think about PJAX. Do you remember PJAX? Did you for use the Exact same thing. Yeah. So Pjax, I don't remember the technical ways of doing this, but I used it even inside of Drupal, even though Pjex, I think, was a, Ruby thing first in Bos, wasn't it? So was this. I think so. Yeah. I believe Pjex came out of Rails. I'm not positive about that. But, it it basically allowed you to get the client side style routing where a section of your site was reloading without the, let's say, navigation of the site. So, like, a part of your site would stay where it JS, and the other parts would be swapped out via JavaScript.

But it was very easy to do and very much so that you just, like, basically included some links and had some specific nav be the Pjax links, and it just worked. That's all I remember, specifically. It was jQuery Bos? I think it was jQuery based. I'm not positive about that. So it's it's so funny. I'm, like, working off of memory here because this was 2011

that I was using Pjak. So it was quite a bit a while ago. Yeah. It it's kinda interesting. Like, if you go to like, Basecamp was the Scott of the people that made this popular, and they are the developers behind Turbolinks, the JavaScript library. And then you obviously have to still have a, like, a server side portion of that as well. It's it's there's adapters for Node and for for most likely for Rails because that's what, Basecamp uses.

But if you just go in the dev tools and click a page, you'll see that request. And then and you can look in the response tab of that request.

And instead of seeing raw JSON, you just see HTML, which is kinda cool.

So the question is, like, okay. First of all, maybe, like, like, what's the benefit to that? I guess the the benefit to that is that you don't ship as much JavaScript to the client.

And also there's no rendering delay where you fetch the data and then render it out on the thing. And that's not really been an issue of mine in the past, but certainly has been for a lot of people because there's a reason this is a thing, right? Yeah. You and I are working with much different

amounts and types of data than quite a bit of other people who are working with either large amounts of data or large amounts of people utilizing that data. That that could yeah. That's a little bit different. Yeah.

Like, I'm just looking at hey.com. And if you want to if you wanna archive an an email or, reply later or pin something, all of that still happens in the browser. Like, each of these actions is not an entire different page. So, like, that's JavaScript. Right? And if that's the case, then you have a couple options there because I don't think you can use

that's a good question, actually. I don't know if you can use, like, a React for something like this Wes you just want parts of it to be dynamic. Yeah. You can. Absolutely. Yeah. Yeah. It's funny because when Vue teaches Vue, they say, like, oh, here, just use Vue for this little tiny bit. But when React teaches React, they're like, you gotta use create React app. And I know that's not, like, how they're intending it to be, like, taught, but, like, definitely, you can you just basically, you just pick a a dev, and you say, hey. Render my React components into this dev. And you have multiple

React roots on a single page. Yeah. You can have as many as you want. Oh, yeah. Okay. That's all. It makes sense. But more popular for this is there's sort of 2 big ones in the space. There's Stimulus and another big one that's called Alpine JS, where they refer to them as JavaScript sprinkles, where you can just add some very light JavaScript added very much like we did with jQuery.

You would just render the the whole thing in WordPress or whatever, and then you'd add a little bit of JavaScript on top when that page is loaded. And I refer to those as JavaScript sprinkles, and a lot of other people do as well.

Yeah. So Stimulus was sort of the first one. Alpine JS is gaining a lot of popularity. It seems pretty cool and have very much a Vue Angular Node approach, where you just write your HTML in a certain way and the JavaScript library will just pick it up from there and and allow you to do things like looping and handling clicks and showing and hiding and those sort of basic stuff that you might wanna do in the browser. But it's it's all done in your HTML templating language, which is pretty nifty.

Yeah. Very nifty.

Man, I I love the term sprinkles here. I'm thinking about how I can bake some sprinkles into my cake and get a funfetti cake of web dev. Yeah. This is not something I've I've used myself, but I thought we just do, like, a little show

because you're gonna hear it thrown all around quite a bit. I've seen back when React suspense was supposed to come out sorry. Not when it's supposed to come out. When they first demoed it, showing a demo where React was not running on the client. It was just running on the server, And then there was just a thin layer of JavaScript running on the client, and it would fetch back to the server the different pieces that needed to be rerendered.

And I'm wondering because React is not I have no inside information, but I wonder if React is looking at this as as an option because they haven't released suspense. They're looking at making React Vercel like a first class citizen Vercel side render.

And I wonder if they're looking at, like, can we build something like this Wes instead of doing all of the rendering and hard stuff on the client, can we just fetch HTML diffs and then dump them into their corresponding Mhmm. Pieces on the website or the entire page? That's why I wanted to do this because I I think that it's something that might become more popular in the next couple Yarn. Totally. I I wonder about this too. I mean, I'm I've been doing server side rendering with React for a very long time now.

That initial experience isn't really isn't really I don't wanna say it's not terrible because it's not terrible. I don't but that that sounds like bad to say. I don't think it is terrible. Yeah. It creates the HTML. It creates it with all of my data, and it just spits it out on the page. And that initial page JS, in fact, like, fully Vercel side rendered. Hey. That's possible. The next step becomes, like, how can we bridge the gap between then the next client side bit Wes you click a link or you do something? What's that next bit look like in terms of how does react react to those changes? It's all very fascinating to me. It's a a fascinating world to explore. I'm gonna check out some of the stuff. And and it's Sanity. We didn't mention in this episode that Turbolinks is not new. It's been around for Nope. Since 2015.

That said, I I Node it's probably gone through several additions, and it actually they made it really easy to add to a rails project because I I used to do Rails work myself, and I I remember when Turbolinks were, like, just coming out as, like, a thing. So it's a fascinating world, and I think we're to see a big shakeup. This this next generation of frameworks, whether or not React changes significantly or doesn't change at all or or goes in some of these directions, I think it's going to be a very, very interesting time for us as developers.

And I I'm sure there will be you know, I I don't think front end framework people are just going to sit around and watch the the web go to, you know, primarily server rendered web and do nothing. We're gonna see evolutions. We're gonna see growth. We're gonna see advancement. I mean, heck, I just think about Svelte and, all of the cool things that Svelte does in some of these regards. And, wow, I I'm excited for the future of web dev. So, man, that's that's my attitude about this. No. It's another kinda cool thing about this, and and Next JS is kind of doing this already.

And I wonder if they're they're looking towards this as well where they have, like, these, like, statically generated on demand pages. So it's all it's generated on the Vercel, and and and then it's static, and then it will serve it up the next time as static. Yeah. But what's cool about that is you could, like, put raw SQL queries in a in a React hook and then just ship HTML to the thing. And I I I realized we're kind of reinventing the wheel because that's what Webex has been for all these years. But Right. Then you might not even need to worry about, like, having a publicly facing GraphQL API because Yeah. You don't need to query it from the client. It's just done on the same server. And we only query from our API

on the client on page change. I mean, on that initial page render, that data's come in a 100% user data, whatever. That's all come in server side rendered. So the only time we're making those changes in in that client side update. So yeah.

There's something here. Now that we don't totally know what it is, but I thought we would do the show just to sort of keep you on it knowing that this is maybe something that will become popular in the next little bit or already is popular.

That's about it. Yeah. Cool. Well, I I had a great time pontificating some of this stuff with you. I'm really interested to hear and and maybe check out more and, again, see where all this goes. And and I know it seems like the React team is on it or at least there's something brewing there. So who who knows? Excited for the future here. 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.