Returning guest, Drew Baker is the Founder and Technical Director at Funkhaus. He joins Steve on this week's episode to discuss his experiences in using Nuxt. He talks about its useful features and goes into detail about its benefits. Additionally, he talks about how he runs his applications using Nuxt 

Hello everybody, welcome to another exciting episode of Views on View. I am Steve Edwards, the host with the face for radio and the voice for being a mime, but I'm still your host. With me today is one of my special returning guests, the guy that I call, help, I need somebody. And he comes on to the podcast with me. Drew Baker, how you doing Drew? I'm Drew Baker, I'm Drew Baker. I'm Drew Baker, I'm Drew Baker. I'm Drew Baker, I'm Drew Baker.

 

Thanks Steve, always good to be here.

 

Yes, just for a little bit of background, Drew is the Aussie that lives in California, who's been living in Europe. So

 

No more, I'm back.

 

but he's back. He's back in the States after doing some knuckle dragging. I'm sorry, snowboarding. This is what we call the snowboarders in Utah. And then he's back in New York, as you can probably tell by some of the sirens you keep hearing behind him. How are you doing?

 

Yeah, good. Yeah, I've got a little snowboard trip to Utah, which was incredible. They broke the all-time record for snow that we can't know is there.

 

Oh

 

Insane

 

wow.

 

winter in North America right now.

 

Yeah, it's all that global warming. I love it. Yeah, here in Oregon, it's been really great with the snow, too. We've gotten back into skiing the past couple, three years. And because of Buddy of mine and the snow, we've been getting tons of snow. Some days it's like two feet of snow, three feet of snow. Last time I was up was about four days ago and tons of new snow. Took my sign up and going up again tomorrow. So yeah, it's been really good here, too, in terms of the amount of and what it is for the skis. It's always nice to get new snow, and especially with the mountain we've been getting, that's gonna be really great for spring skiing. Here the season generally goes to the end of May. So yeah, it's nice getting all that snow. Every time I look at the temperature, I'm like, what's it doing on the mountain? How much snow are they getting up there? Are they getting new snow? Everybody arounds here is like, it's cold, this sucks. Like, no, it's more snow. More snow. So, we wanted to, we're gonna talk about a couple things today. Drew, if you're a regular listener, you've heard him and when we've had Daniel Rowe from the Next Core team, on here talk quite a bit about Nux as he uses it in his day to day at Funk House. And so, it's been at least two or three weeks since we've talked about Nux, I was just kidding. And so, wanted to talk about it again, had some recent experiences with actually starting to use the next 3 1.0 version and his experiences with it. So, fire away Drew.

 

Yeah, I thought the real good place to start with Nuxed is the different rendering modes, because that's kind of the main point. Well, one of the main points of Nuxed, if you haven't used it before. It's definitely the way I describe Nuxed to people that aren't familiar with it, over View, is that what users view as the templating part of it all. But it's opinionated on the structure of everything. So Nuxed is much more of a website building framework and where view is like a component framework or a templating kind of framework, I suppose. And so what Nux does is like kind of bundle in a bunch of things like page routing and some opinions on how to store state stuff like that. But the rendering mode or the options around the rendering mode is the big thing that you want from Nuxed. And so, you know, let's talk about what those are. So the sort of top level is you have, and I'll go into more details about these and the experiences that I've had doing this and what is the pros and cons in the real world of using some of these things. But you have sort of five main ones. You have SPA, which is single page application mode, and that essentially is view. I'll get into the details of them all, but the other one is server side rendering. You'll see it written as SSR, and there's kind of like some flavors of that that we'll get into as well. Then there's SSG, which is static site generation. And then there's a new one now, oh there's a new two ones with the Nux three, which is ISG, which is incremental static generation. And then there's hybrid. And so those last two are really interesting and very useful and will solve some of the other problems in the previous three. So let's talk about it. And then the reasons why you might want to use one over the other is kind of important. So I think it's really good looking at any technology is what is the thing you're trying to solve and what is the point, not just using it for the sake of using it. And so when we're building a website at Funkhouse, like the thing that we will start asking ourselves in terms of how we're going to host this thing, or this website, is the time to live of the content important. So once a piece of content gets published, either through the CMS, or through the CMS, or if you're using a repo-based content system like Nux content where you can just leave markdown files in your code, how long is too long for that to happen from someone editing content to being live on a website? Because that's the main thing that all of these rendering modes are trying to solve, is that? Combined with, is the time to interactivity important as well? comes to your website, do they need to be able to see everything instantly? Or can you boot up and show a little loading spinner while stuff happens? Even if that loading spinner is really fast, if you're using a certain, some like the SPA approach, for example, there's nothing coming off the server really, and it gets all built client-side. So there is a bit of a delay there. And that sort of feeds into one of the things that's been the most important and the hardest lesson learned for the work that we've done, which is the SEO factor. what you're building need to show up in Google search results. Because if it does, essentially, it doesn't need to be machine readable or crawlable by a bot. If it does, then SBA approach is not going to work. So those are the main ones. And then the last one, which is also something to consider, is the cost of hosting.

 

Thank you.

 

Because some of these are significantly more expensive than the others to host, especially at scale. Or like, you know. when you have a couple of thousand people a day looking at something which is something that you know not everyone has to deal with but certainly like the kind of stuff we do we have to think about that so That's kind of like the criteria of making decision and now I'll talk about the different approaches and how those criteria kind of relate so the the the first one single-page app SPA mode that is Very much just view three you now you can run nukes in this mode as well And we certainly do as well if you want all of the sort of like configuration and opinionated benefits of Nuxed. But mostly if you're just running the straight view 3 app, just vanilla like regular style, not doing anything special with rendering or anything, you're probably using SPA mode. And so what that means is your HTML file, like if you inspect the source of your site or of a view site, and there's only like one div in there that's normally like ID app, and that's kind of it. And maybe you have some stuff in the head HTML, but there's no real like content in the in the source code. That's an SPA app. And so what is happening there is you're visiting the site, the server gives you this like, essentially like an empty HTML file or close to empty. And then client side, you load up all of the JavaScript and build out all of the elements and then load in or hydration, hydrate in all of the data. And so that takes some time. in terms of server resources, because you're only serving a static one HTML file. And if you're doing that, you can post that anywhere. You just put it on an old FTP site or anything, even something static like Vacell or Netlify would be kind of overkill, because there's no build process to any of that really. You're just serving up an empty HTML file, and that's it. You could put it anywhere. But that is not an HTML file. We learned this the hard way at Funkhouse. That is very not SEO friendly. Now Google kind of makes the claim that they will render JavaScript apps and I think they have a certain like time, like if we load it up in a certain amount of seconds, we'll crawl it and use that for search results. In my experience, that is all BS. That we've never seen that happen. We have built huge sites that were running in like SPA mode, on that Google sort of lie and got terrible search result, like just massive drop off in search afterwards, and then convert the same view site into like a Nuxed static site or a server-side rendered site and had the search SEO pick right back up again. So it's, if you are building a site that needs to be like indexable, then SPA mode is just terrible for you.

 

Well, it's by itself it is. I mean, to go to your point about Google, I'd have to find the episode, but on JavaScript, Jabber, we interviewed a Google search dev rel person, developer relations person. And I specifically asked about

 

Oh, nice.

 

indexing of SPAs in JavaScript. And I'd have to go back and find the response. But the gist was, yeah, we've gotten better at that.

 

Yeah, I bet that.

 

Because the whole issue, obviously, is, about ad nauseam everywhere is that when the page perched loads, there's no data because it has to hydrate. The JavaScript has to go get the data and hydrate it. And so in that time, the Google bots, oh, there's nothing here. I'm going to go away. So yeah, but they've said, oh, no, it's better. We can really do that better. I've always taken that with a grain of salt, more like a shaker of salt, not just a grain of salt.

 

Yeah, me too.

 

And there's ways around it. At my place, we have a view. that's backed by Laravel, and we use Rendertron,

 

Yeah.

 

which is basically another library that basically creates indexed content for the bot when it comes around. And so when the bot comes around and sees, hey, here's all this content. Let's index it, even though it's an SPA, but it's a lot of extra work and so on. And I know Netlify has a pre-rendering service, I believe that you can enable for SPAs that does exactly the same thing. You know, it's going to provide pre-rendered content for the bots when they come indexing. So there's ways around it, to your point, strictly as an SPA, Google's not gonna, it doesn't seem that Google's really gonna index it as well as they do a static site

 

Totally

 

or

 

not. No,

 

a pre-rendered

 

yeah,

 

site,

 

and

 

server-side rendered site. And that's it.

 

yeah, there's always a million ways kind of around these things and like that pre-rendering part of Netlify is something that we've experimented with before as well. But the other one that, depending on what you're building, this is something to think about if you're building an SPA site, is if you want that to be like shareable on like Twitter or LinkedIn or something like, or Facebook, and you want the little preview image you know, to show up and be relevant and with the like content because really all the Facebook is doing there is reading your source code, looking for open graph tags, og image, og title, whatever. And if you're an sba thing, theirs don't exist either. And so that that's something to consider when you go sba, which is something that's bit us in the butt before as well. So we don't do a lot of sba stuff for that anymore. The only ones that we've, when we use sba now is for apps that require login. So if we build some task management kind of apps, and those all can run SPA mode. So that's when I would go SPA, they're really cheap to host, and if they're not needing to be searchable, then that's a great option. So that's SPA mode. Now, the next step up is SSR. Now, there's a million different terminologies for all these things, in the Nux world, SSR can kind of mean a few different things. But essentially what it means is there is a node server somewhere that is rendering all of the HTML and then giving that to the client. So when you request a website, there's a node server that builds out all the HTML and sends that as a file to the user. So you're basically getting a HTML file and then view loads up client side. So all the interactive stuff happens. But the HTML file generally, and should be, if it's in Nux, it needs to be. to be unchangeable for the first initial load. So there's some considerations when you're building those things. The real common one that we see, like a Nuxed rookie will do is build something that relies on window size. And if the window is greater than 750 pixels wide, go to two columns or something like this. And if you write that in JavaScript, Nuxed will have a real problem with that, When it builds on the server, there is no window. So it's giving you the static file with some assumptions on window size being nothing, and then it gets to your browser, and you have a window size and things change and it doesn't like that. So those are like the mindset that you have to get into when you start going away from SPA and into like server rendered stuff. So server side rendered, what we will use that for is when a client comes to us with a site that has a requirement for time. time to live of content to be like zero. They want to click publish and it shows up on the website. And that is like really popular in big media websites, you know, big news websites or those are the main ones we've used it for. Or e-commerce is important as well. But so like if you look at any of the stuff that we've done, Flood Magazine or Torment Magazine, Big Snowboard Magazine actually, those are, well Flood is actually service-side rendered because they publish music news really instant and then Torment, they're okay with there being sort of a five to eight minute delay, you know, a bunch of snowboarders, we're not really okay, we can be chill. That can be static, that's a static rendered one. So the main reason that you would want to be SSR is for speed, speed of publishing. But the downside to SSR is it's really, really, really, really, really, really, really, really, Really, of all these hosting options, it's the most expensive one because you have to have a node server somewhere that is handling all the requests and can deal with the traffic. Now you can put all that behind CDNs and different caching strategies and stuff, which we've also done, but it's no way around it. It's way more than the other hosting options we're talking about in terms of the cost. But it's great for SEO. the server is just outputting HTML all the time. So whenever Google or any of Twitter or Facebook or anything crawls the site, they're just seeing like complete site code. So that's been great for that. Yeah, so for in our case, like we host a lot of that stuff on Heroku, but any kind of node server scenario would work for that. Yeah, so that's SSR. Now, iteration of all of that is called SSG, which is static site generation. And that's the one that was popularized by Netlify and Vercel. And that's like very jam-stack evolution.

 

Yeah, that's what I was going to say, the jam stack acronym right there,

 

Yeah.

 

right?

 

So what that means is, and it's a little bit of a mindbender for us JavaScript client-side people. But what that means is in the Nuxed world is Nux has a built-in crawler. Now you could do this without using the crawler eventually, but the crawler sort of was an iteration that made this really user-friendly, which was you code out your website in Nuxed view, deploy your GitHub repo, and you could even just run this locally in Nux that some NPM run generate. And what it does is it will load the first page that it knows about, which generally would be your homepage, like your index.view file. And it will look through the source code from that output and look for all of the Nux links, which is Nux version of like router link in view, and follow that to the next URL and like build out a list of all the URLs can find on the website and then statically generate the HTML for every one of those pages. And then save that in one folder in a distribution folder, just this in the case of Nux, like defaults. And so you'll end up, you can look at it. It's really interesting. You'll end up with like, it depends on how big your site is and how many page routes you have, but thousands of just HTML files. And then that goes on a CDN in the case of Netlify and Vacell. And whenever a user requests a file, to URL, the first thing they're given is just a static HTML file. So that, and it's pre-built in everything. Like if you, as long as you haven't kind of made some mistakes, what the user will get is the first page of the website. And then from then on, you're browsing around the website, clicking on links and stuff. It's all client side. And all of that is happening client side now. And if you've done it kind of the way that Nux wants you to, you'll never even hit the API. Behind the scenes like if you had it connected to a CMS you'll never even hit any of that it all it's like serverless It's just static files and naks does a whole bunch of magic to kind of like Bring down just the JavaScript you need for the page you're looking at so if you're like you know on the home page It doesn't load the contact page JavaScript, so it keeps everything very chunked and minified and all that stuff It's brilliant. It's very smart, but the beauty of this is you get this the insanely fast time-tolerant interactivity because like what the user

 

Crazy fast.

 

is It's

 

It's crazy fast, because it's already right there.

 

it's amazing Yeah

 

Don't have to go get anything. It's already there. 

 

It's amazing. And you get a really, really cheap cost of hosting because you're just serving up static files from a CDN. So there's no hosting really behind the scenes other than this initial build time. Now, depending on what kind of website you're building, that build time can be nothing. Like if all you're doing is updating a site once or twice a year and the content doesn't change very much, you don't need a CMS of any sort. And maybe depending on what you're doing, a lot of people might, it's very common to use something like this for docs, for a plugin, or a script that you've built or something. You're not changing that content very much. And if you are, you're changing it in a repo. So Nux has a whole thing called Nux Content, which is like markdown files that sort of serve as a CMS. It's brilliant. It's really smart the way they've done it. So if you need to change something, you're just changing it in a CMS and then deploying it. So you could just be deploying static files all the time. wanted to host it on just like a CDN style host. But

 

There it goes, that.

 

we use mostly a CMS.

 

Thank you.

 

Steve, I'm back.

 

Oh, there you are.

 

Sorry, my hotel wifi dropped out there.

 

Okay, good.

 

I'm back. Sorry, my hotel wifi dropped out there. 

 

Oh, okay.

 

What happens now?

 

Yeah, you froze, you were, had frozen for a little while. Uh, let's see. Try to pause your upload. See if that works. Okay. See how we were just start, I'm trying to remember where we were when you froze. I'm trying to remember where we were when you froze. I'm trying to remember where we were when you froze. I'm trying to remember where we were when you froze. I'm trying to remember where we were when you froze. I'm trying to remember where we were when you froze. I'm trying to remember where we were when you froze. I'm trying to remember where we were when you froze. I'm trying to remember where we were when you froze. I'm trying to remember where we were when you froze. I'm trying to remember where we were when you froze.

 

I, yeah.

 

We were talking about how crazy fast it was, the static site, fast it was. And I'd.

 

Yeah, that's pretty much what I think I was saying was very fast and then I was about to talk about different CMSs that you might connect to it.

 

Yeah, I think so. One other thing to talk about too is security,

 

Yep.

 

because you're not hitting a back end server. There's

 

Yep.

 

no security issues or something like that. But anyway, see, I'll go ahead and I guess pick up from about there and

 

Should I acknowledge

 

edit

 

that

 

it.

 

we lost the reception for a minute? Okay.

 

No, no, just pick it up and I can edit it.

 

OK, it's recording still.

 

Yeah, I'm still recording.

 

Yeah. Yeah. Yeah, so SSG is really, really fast. And the time during interactivity is crazy, because you're giving out straight HTML to the user. And so there's no load time while you're waiting for an SBA to boot up. That all happens in the background, obviously. But it's booting up what you're already looking at. So it's very, very fast. So then the other thing. thing to think about is how you're getting content into this. So if you're if you're just building a website like a docs website for a view plugin or something, which is quite common, you can store your content in the repo in your like code. And Nux has a whole module for that called Nux content, which is just like markdown files. And so then your CMS is essentially lives in your in your repo. And so then whenever you generate a generate a new version of your site, you're just deploying straight static HTML. So you could do that in just a CDN type environment without any kind of node server or anything because you could just run it locally and then just like upload HTML files basically. But for what we do at Funkhouse, we, you know, 99% of the time we have a CMS connected to it. So we'll have a backend running. And then when you upload your repo to Netlify or to Vercel, is it will boot up a node instance on Netlify and start crawling every page of the site on Netlify and copying down the HTML and leaving it on Netlify and then deploying it. And so you have like a connection between Netlify and your CMS to say whenever my CMS updates, hey, Netlify rebuild. And that has a huge advantage in that you're hiding the back ends. So like a lot of the times the like vulnerability and the security of things People, you know, hacking in, like in our case, we're using like WordPress as a CMS or something. There's a big concern about hacking WordPress or like, you know, breaking into our CMS. That is all very hidden. Like, publicly, it doesn't, it's not even accessible. Or if it is, it's only one endpoint that is accessible and everything else is locked down. So you get a big security boost when you go SSG as well, because again, you're just stealing the static files.

 

Yeah, I've done it both ways. I had one little blog site where I used, it was just little blog stuff, so I used markdown files in my editor and commit those to the repo, the GitHub repo and that would trigger Netlify. Netlify would build it and you're off and running and I have other ones, that's the next two site. That's backed by Prismic, an online CMS and I do my content in there and set it up and it builds and fast as heck secure and does everything I need. And then I just use, you know, there's like a contact form. So I just use the built-in Netlify forms capability for that Netlify handles that for me. So yeah, it's fast, it's quick, and even has a little bit of interactive functionality built in.

 

Yeah, the interesting thing about, you mentioned Prismic there, Prismic is an incredible CMS. That's a static generated headless CMS, which is weird to think about. Whenever you update something in Prismic and you also like click deploy, I think that it's even the word they have or publish, what that is doing is that static generates the API, which is wild to think about. So your publishing content, on Prismic is working very much the same as the static site on NUC. So the whole thing is like just static files, even on the front end and on the API end. It's just so fast to do that.

 

I don't understand that. Explain what you

 

Yeah,

 

mean

 

I know

 

with

 

it's

 

Prismic.

 

it's it's it's mind-bending. So whenever you change something on Prismic, it generates static JSON files of the API.

 

Okay.

 

So, you know, like when we build a website, the static output is a HTML file. Well, you know, could be just a JSON file, right? And that's what it is. So whenever you're like querying stuff on Prismic, really what you're getting given is static JSON files.

 

Oh, interesting.

 

And so that's why the Prismic API is insanely fast.

 

Okay

 

It's it's it's wild. The static site generation thing is like a real, I mean, I don't know how faster than that because it's the theoretical you're just passing around files. So.

 

And then what's even more interesting you can do is, I investigated this for another site I was working on for a small business where you can set up webhooks between Netlify and Prismic so that anytime you make a change in Prismic, that automatically rebuilds your site on Netlify.

 

Yeah.

 

So you don't even have to manually go in and rebuild every time you change content. So for, you know, when you're doing something for, you know, a non-technical user, a business owner, all they gotta do is go in and change the content. Okay, that's good, save. And then you don't, you know, nobody has to go in or you don't have to do it or you don't have to set up fancy scripts you just point your webhooks at each other and It does it for you

 

Yeah, there's a bunch of developer experience stuff too that comes out of Netlify. I mean, it's hard to talk about this without just coming off as this giant ad for Netlify, but it's

 

Right.

 

pretty good to work with. No,

 

Just to clarify, we are not sponsored by Netlify at this time. [???]

 

no, no, yet. In fact, it's the other way around, I spent a ton of money with them.

 

Ha ha ha.

 

But anyway, so the downside to static site generation is time to publish. Now, what that means is if you, like for example, before I was talking about Flood Magazine and then the other one, Torment Magazine. So Flood is server-side rendered, it's hosted on Heroku. When they publish something, it appears instantly. Very expensive to host and has to be able to handle the traffic and all this kind of stuff and we have to have some specific CDN layers in front of things and we're using a GraphQL CDN as well called Stellet to handle all the traffic that they can get. Host on Netlify. Now, they have like, Flood has about 10,000 news articles over years and years and years of publishing content. So when you publish something in static site generation mode, what it's doing is, like I said before, it's crawling the site and collecting all the URLs and building all the pages. Now, even if you have each one of those taking a second or two seconds to build times And you're talking about 10, 20, 30 minutes. So once a new piece of content publishes, you've got to build every route unless you get real granular. And you can control this stuff if you want to and get real granular about when this page changes, only need to generate these kinds of pages. And it gets really complicated. Just out of the box, it's going to build every page for you. And so when you're dealing with pages with lots of page routes, it takes forever. You know, like in our experience, most pages, most sites that are running in SSG mode take between two to 10 minutes from when a new piece of content changes to the site going live. And depending on what the client and what the contents of the website is, that might not be a problem. You know, most people, if their website takes 10 minutes to update, it doesn't really matter. But if it's like timely stuff like news or anything like that, it's a problem. Now in the Torment world, there are a KWIS. with 10, 12 minute build times, it's fine. But that's the big advantage to SSG, which gets us to the next one, which is like, oh man, I wish there was a sort of a combination of both. Which is the new new in Nux 3, and that's called ISG, which is incremental static generation. I'm not actually sure if this is in Nux, like the like released version. release candidate. I certainly couldn't actually find anything on their Nux.com about this yet but I have seen the GitHub commits for it and Daniel Rowe and a bunch of people talking about it. So if it's not in Nux yet now it's coming very soon.

 

Well, just to interrupt here, Daniel just messaged me right before we got

 

Oh,

 

on.

 

nice.

 

I don't know if you saw the message that I put in the chat. But he says it's implemented, so I'm not sure if the docs need to be updated. But basically, it's done with route rules. You set SWR to true

 

Yep.

 

or to a number of seconds.

 

Nice. So there you go, breaking news.

 

Breaking

 

No, it's

 

news

 

definitely

 

on views

 

not in

 

on

 

the

 

view.

 

docs yet. So how to enable it, I'm actually not sure. Like, there should be a, there's a configuration that's also not in the docs called target. And in your Nux config file, if you set target to, it's probably ISG, but I couldn't find the docs on it. And then set up your route rules for it. And SWR, what he's talking about there is called stale while, stale while, refresh I think is what that means. And so what that's saying is there's a couple of different ways to configure ISG but before we get into that what is ISG? So what it means is... When you come to the website, if you're the first person to look at it, it will be building it and giving it to you. So the first time up, you'll basically get a server-side rendered, an SSR version of the site for the first person. So that has all the downsides of SSR, which is like server load, and there's a little bit of time there because the server has to build it and give it to you and all that kind of stuff. The next person will basically get an SSG page. So if you're OK with the first person being slightly slower, and then the rep, when I say slower, we're talking about 100 milliseconds, like we're talking small.

 

Almost not humanly noticeable,

 

Yeah,

 

right?

 

is the idea. Yeah. After that, it's static file all the way. And so you get the benefit of both without having to have the build times. And then you can... handle that's what the SWR setting is for. What happens if that page doesn't exist? Should we rebuild a new one and give it to you? Or should we give you the old one that we used to have? Well, the new one before, you know, so you can handle those scenarios in a way that makes sense for whatever it is you're building. You know, like if you're okay serving up the old version, then there will never be any slowdown, you know, because we're building it as we go. So that is the holy grail at the moment, is these ISG approaches. And then the final, well, so the downside to ISG is going to be the hosting setup. Now, they've gone to a lot of effort to get this working in the Netlify, and Vacell, and everything. So you can have the static hosts work with this using all of the serverless functions that they provide. So the hosting costs won't be, as significant as SSR. They'll be very similar to SSG if you use this, which is very exciting, because the Netlify hosting is so cheap. I mean, I just, you know, for some comparison out there, we host, I think, a couple hundred websites at the moment on Netlify, you know, and it's like a couple hundred bucks a month, you know,

 

Hmm.

 

and that's because we're using all these team functions and stuff because they kind of bill you per seat. But on Heroku, it's so expensive, you know, it's 20, 40, 50, couple hundred bucks per website, depending on how much traffic you get.

 

Oh, geez.

 

It gets real expensive. And then when you're using a Roku out of the box, you don't really get any kind of CDN or caching performance or anything like that. So for us, we have to put that stuff in front of it. So we have like Cloudflare in front of some of this stuff and it's even more money. So like, I'm very excited about ISG. It's like one of the main things that I want out of Nux 3 is ISG. So yeah.

 

Yeah, the first place I remember really seeing that done, because that was sort of the holy grail for a long time from the static sites is the rebuild. You know, if a smaller site, not so big of a deal, but when you get into larger sites, then it's an issue. But the first place I really remember seeing and implemented sort of the first to market for lack of a better term was Gatsby.

 

Hmm.

 

And it wasn't with the self-hosted, you had to host it on Gatsby Cloud. But when you did, then they had the capability to do incremental,

 

rising.

 

incremental builds. And I know it's been coming along in other places since then.

 

Yeah, I know next, I mean like most things like next JS had it for a while and now we get it in Nuxt but that's exciting. So then the fifth mode that's worth talking about that you can do in Nuxt 3.2 is called hybrid. And so hybrid rendering is what if you have a website where you have a bunch of marketing pages and then you have a login page and then after the login page it's all protected. configure certain routes to have this one be static rendered, this one to be SSR, this one to be SPA mode, and pick which parts of the website should be rendered in certain ways. And that's what hybrid rendering is. And you can do that through configuration in Nux 3, which would be useful for anyone building sites that have a login component that also have a big static component to it, which would be most like e-commerce sites and things like that. have that. So that's the overview of all of the different rendering modes in Nux and websites at the moment. It's complicated but it's good to have options.

 

So here's a question. I never really heard this described well and I'm sure the descriptions are out there. What is it about incremental rebuilds that make it so difficult? I think it's a little bit more complicated. I think it's a little bit more complicated. I think it's a little bit more complicated. I think it's a little bit more complicated. I think it's a little bit more complicated. I think it's a little bit more complicated. I think it's a little bit more complicated. I think it's a little bit more complicated. I think it's a little bit more complicated.

 

Yeah, that'd be a good question, I guess, for Daniel and the Nuxt team. But as far as I understand that to be, it's, you can imagine from the server infrastructure, like what is going on there, like when it's static generated, the server is not really exposed to the public, you know, like it's like in Netlify's case, your node server is not publicly accessible other than through serverless functions. And so when you visit a website, you, on Netlify, you're just getting given static else. But if we want, so that's easy to do. And then if you're like, server side rendered, like Netlify isn't doing that, you know, they don't, I imagine like they don't have any infrastructure to handle that. That was all like Heroku. So you kind of have both. Like I've hosted static on Heroku because essentially you can just upload files, you know. And so you can do that on Heroku. But on, starts like Netlify and Vacell, like they were never, accessible beyond serverless functions, which, you know, for other people listening is like lambda functions and stuff, like these one-off, function-y things, not handling like user traffic, you know? And so I think combining those two things is tough, because like we've got to serve up this static file, or let's generate it and basically put that static file in the distribution folder, you know? So there's a lot going on there, and yeah, like all the config that goes with it, like when is this style and stuff. So I think that would probably be my main guess as to why that would be complicated. But yeah, a fascinating question, I'm sure the NUX guys would have a lot to talk about.

 

Cool. So I think we've covered all the modes. We're going to have this

 

They're

 

one.

 

the main five, I think. There's sort of other smaller versions and different subsets. For example, you can run Nuxt in SPA mode with server-side rendering turned on, which does some weird stuff. It depends on what you're trying to do there. But the main five are the ones we covered. That's certainly the ones that we use for most of the work we do.

 

Yeah, I know now some people like to use NUCs in SPA mode, like for say an internal tool where SEO doesn't matter, Hill of Beans, because of some of the built-in features like the routing, right? You're

 

Yeah.

 

based on folders and directories. And some of the other internal tools like that, even though you're not using as a server-side tool because of SEO, but that gives you some features where you don't have to define all your features. your routes, see your routes files and so on. So I've seen that and I've worked on sites like that before that sort of mix things that way just because it takes a load off you in some configuration, in some areas of configuration and setup.

 

Yeah, then we've done that. We built this big task management app called Polaris. It's for like the construction industry. And that's how we did it. It's a NoxTap that's running in SPA mode. And that's how we did it. It's a NoxTap that's running in SPA mode. And that's how we did it. It's a NoxTap that's running in SPA mode. And that's how we did it. It's a NoxTap that's running in SPA mode. And that's how we did it. It's a NoxTap that's running in SPA mode. And that's how we did it. It's a NoxTap that's running in SPA mode. And that's how we did it. And that's how we did it. It's a NoxTap that

 

Cool. So one of the other things I wanted to talk about before we wrap things up is View3. I'm a little late to the game, although I try not to be too much bleeding edge. I bleed enough as it is. I don't need any more cuts from new technologies. And so I've talked about it more in JavaScript Java, but I have a project I've been working on for the past two, three months. For an organization, I belong. to a nonprofit and it's a sort of an internal crud app just for managing membership and payments and that kind of stuff. And so my tool of choice has been inertia.js which is for those of you who haven't heard me talk about it or are not familiar with it is sort of a glue, a gladiator plug-and-play between front and back ends and does it in a way that's super fast because the short description is it's sort of hijacks your post request and communicates between front and the back end either with props and using some headers so that it doesn't do a page reload. So all you're basically doing is updating the content that you want to update on the site without sending a full page reload and page refresh. So it has adapters for the front end for view, for react, for Svelte. And then back-end libraries for Laravel, for Ruby, and I think there's ones for node now. So you could mix and match Ruby with view or Svelte, React. depending on your comfort level. And the docks really aren't that extensive if you look at the inertiajs.com site because there's not a lot to it. It's not like a framework, it's not necessarily a library. I think of it as a glue between the front and the back end that handles a lot of things for you. My combination of toys is Laravel and View. And it's, and then what's nice Laravel, if you remember listening to my interview with Taylor Ottwell, the Laravel creator, back a few months ago, talked about their distributions like Jetstream and Breeze. And so Breeze now is you can install it and it has inertia built in. Then you tell it, okay, I want to use Vue for my front end and Laravel for my back end. Well, it is Laravel, so you're already using Laravel. And then, you know, builds in tailwind. And then what's really nice is that is they went away about six months ago, I think, roughly, they went away from Webpack to use VIT.

 

Mm.

 

So now it's crazy fast on the rebuild. I mean, I'm noticing when I'm working on it, I will make a change in a file. And even before saving the change, my page will be updated with what I just put in. So it's pretty fast. And so everything is geared towards View 3. And I hadn't really used View 3 that much, so I sort of took the plunge and then with Laravel, I think I'm on Laravel 9 right now. Laravel 10 just came out, but I'm still on 9 and then tailwind. And some of the things, definitely takes some getting used to in view three versus view two. How props are defined, how events are defined, the whole setup script. It was initially script and you had a, was it script, I think it was type equal setup or something like that. And now the script section script, you know, script tag and then set up in there. It's not like value equal script or something. It's just an attribute basically. And so that makes things a lot more simple for writing your code. But it's nice that it's more JavaScript like for lack of a better term because you know, you just declare a function, my function is this, you know, a method, you define your, you know, your props. Or you're just your, your data values. you know, before in view two, it's data is a function that returns an object that contains your different data, reactive data values. Now you just define them, you know, const my value equals whatever it is, but then you wrap it in the ref. So there's, you know, the ref wrapper that makes it reactive. There's ref and reactive and there's, you know, minor discrepancies between the two in terms of objects versus scalar values and when to use one or the other. There's whole that. But it's pretty easy and clean to read. You're defining your props. It's just a method, pass in, you're finding what your props are, they become automatically reactive. So yeah, it's pretty cool. And one of the things I noticed was one thing I'd often wrestled with a functionality is how you can define, and this is all documented in the View Through documentation, is how you is how you can bind elements between a parent element and a child component. So the classic example is where I have a table and I wanna have a filtering field that makes a call to the Larva back end to get paginated data based on what I've typed into my search field. Now, the interesting thing about inertia and you have sort of have to understand this in order to work with inertia is that the way that the data is passed from the backend to the front end is via props. It uses the inertia library that you install for Laravel and Vue in your Laravel controller method or wherever you're returning your data from could be in a route definition as well if you want to be really simple. As you say, inertia render this page and you pass in the path in name of the Vue component that you're communicating with. and then you pass define the props that you're passing back to your component. And so this works only for components that are under the pages directory in your JavaScript structure. Well, let's say you have an index component, a user index is a pretty straightforward one, and then you have a table that's a child component of that index. in the table, you know, component. Well... you have to have the data pass from the parent index component, not within the table itself.

 

Mm-hmm

 

And that's above where your search field is. Because inertia, again, is, dude, you're specifically saying, okay, pass up to this component. You can't pass it directly to the table component. So now you've got to have that binding between the search field in your child table component and the actual method in your parent component that's communicating with inertia on the back end. Does that make sense?

 

My question is, what is the output from inertia then? It sounds like it's actual HTML, or is it JSON that's getting passed into the view props. It's replacing

 

Oh yeah,

 

parts of the page by the sound of it.

 

right. It's a standard view component with your template and your script and everything. You just get the data passed in as a prop,

 

Hmm, interesting.

 

and that's reactive, and then you do whatever you need to

 

So Laravel is like outputting HTML in this scenario.

 

do, whether it's text fields.

 

So Laravel is like outputting HTML in this scenario. So Laravel is like outputting HTML in this scenario. So Laravel is like outputting HTML in this scenario. So Laravel is like outputting HTML in this scenario. So Laravel is like outputting HTML in this scenario. So Laravel is like outputting HTML in this scenario.

 

No, just data

 

Yeah, just

 

in

 

Jason,

 

an array

 

yeah.

 

format

 

Yep.

 

and

 

Yep,

 

then it converts it to JSON

 

yep. Yep.

 

that you read within your view component.

 

Yeah.

 

And then all your templating is done in your view component

 

Yeah.

 

or your front end component,

 

And

 

whatever

 

so,

 

it may be.

 

and inertia is just sort of sinking up that data that's coming out of the Larrel and like putting it into the right props in view, basically.

 

Yep, that's exactly what it's

 

Yeah,

 

doing.

 

yeah.

 

And so anyway, one of the cool things I finally got my head around in view three is how you can easily sync between the parent and child component.

 

Yep.

 

And it's documented on the view three documents I can put a link in there. But what's really nice is that once you use omits and props and events and you have to have them named in certain ways, certain names have to match up. So, you know, my parent, I'll have a table component, you know, just call it table, my table, whatever. And I'll have a prop that says, This is my search field. This is the text, right? And then you set a watcher on that search value in your parent component. Then in your child, you use that search as a prop and then you admit event anytime it changes. So then it's synced with search value, data value in your parent. You set a watcher on that. It does its thing with inertia and then passes it back. So everything synced up nice and neat between a parent and a child. It was real easy to do a little, To me, it was easier than it's done in Vue2,

 

Thank you. Thank you.

 

having something like that. I'll have to look up the term in the docs. But yeah, that's one cool thing. Another thing, one thing that inertia has, it's really nice is a form helper that's built in because forms are such a prevalent part of any type of data-bound application like this one. So you basically define, you use the, there's a form helper that's built in that you import in your component and you use it. You say const form equals form, whatever, put all your data values in there. So then you can bind your individual text fields and text areas and selects and that kind of stuff, just with standard view, be bind to your form dot, whatever, my form dot name, my form dot address, my form dot city, whatever, and that makes it dynamic. So it's all contained in this form variable wrapped around the wrap by the form helper. And then in your submit function, all you do is do form dot submit to URL. and it handles everything else for you.

 

Hmm.

 

And passes it to your controller, whatever's getting the post or the getter, the put on the back end. So it wraps it all up for you. You're not having to do a lot of the old manual work of synchronizing forms and setting it. And then there's other parameters that you can pass to the form method that says, okay, don't reload everything, right? Preserve state, preserve scroll, and then there's even, you know, like on success callbacks, there's all kinds of callbacks you can use, you know, if it's taking a while you can show up, you know, a file or some sort of status method, hey, this is still loading. All kinds of little helpers and it just makes form handling and updating of the page much, much easier and very quick. So it's really pretty slick. And then what I thought was interesting, And I know it's a user thing is they have, you know, obviously primarily this is gonna be a SPA type of application on your front end, but they have a server side rendering plugin or capability that says server side rendering pre-renders your JavaScript on the server, allowing your business to see a website prior to the JavaScript fully loading and it uses. So you have to have a node on your backend wherever you're hosting your particular site handle that but it's built into Breeze and Jetstream, the Laravel distributions. I'm not sure about Ruby or React or any of the other distributions or set ups that are out there but it's pretty painless to set up, it looks like, but it gives you that server side rendering capability along with the speed. But the one thing I've noticed, like I said, is in the Using V, just your development speed is so much quicker in terms of page updates, because I wrestle with web pack updates all the time on my day to day work and it's painful. But the way that inertia handles everything, the communication, once you actually make a request is just amazing how quick it is and easy. And easy. And easy. And easy. And easy. And easy. And easy. And easy. And easy.

 

I'm jealous of the form handling stuff you're talking about. That's always

 

Oh.

 

annoying, especially when you, like in my world, we do a lot of stuff in GraphQL. And so dealing with, you know, like a select drop down that is populated from data coming out of GraphQL that's generally in a different shape than the data you need to submit back. It's like

 

Right.

 

very annoying. So that sounds useful. So that's what I'm talking about. I'm just gonna say that I'm not a big fan of GraphQL.

 

Yeah, and the form helper has some helpers built into it for things like if you need to map over the data, maybe what's in your data needs to be tweaked a little bit before it sends to the back end. So there's some features like that, but it makes it nice in that it's only updating what it needs to. It's not generating your whole page, you can do it with a full post request or stuff like that. Anyway, yeah, it's pretty slick little tool.

 

So

 

I love using

 

feeling

 

it

 

good about view three then.

 

I'm getting more comfortable with it.

 

Yeah.

 

You know, I haven't, I haven't, you know, I can remember talking about when Berserie came, you three first started coming out and was a thing. And the big, at least one of the talking points for the composition API as compared to the option is the API is in terms of organization of code

 

Yep.

 

and how you group everything together and you can have separate organizations and now you have what, Composables and things like that. Some of those things I really haven't taken advantage of yet. because I'm you know still getting used to view three and haven't really needed some of that I don't think but yeah I can see how you do it and how some of these things could be useful but I haven't really dived into that extent but yet I'm sure I will down the road for sure.

 

Yeah, my experience with it actually is pretty limited so far because we're so relying on Nux for all the stuff we do and Nux 3 having just sort of come out recently, you know, we started moving, so we have a boilerplate that's open source that we kind of use for the starting point of all the websites we build. And it's on

 

Mm-hmm.

 

the Funkhouse repo if anyone wants to check it out. And I started the sort of process of making the Nux 3 version of that for

 

Yeah.

 

our team. And just quickly ran into it. to some roadblocks of things that we took for granted that aren't really ready for Nux 3 yet, some community modules, like the big one being Storybook. We used that a lot. And as far as I'm aware at the moment, there is no Nux 3 Storybook integration. So kind of like hit a roadblock pretty quickly. Then the other ones being site maps are really important for us, being able to generate a site map. Weird

 

Uh-huh.

 

thing that might not be important for a lot of people, but for us with SEO stuff, it's really important. There's no good site map module yet. So got away for that. And then the other one is we do everything in GraphQL. And there is a few different GraphQL solutions out there, like Apollo being the real popular one. But, ah, man, I

 

Right.

 

hate Apollo. Had such hard time with that thing. So we use one called GraphQL requests, which is actually written well. It's a, the Nux version of it is written by an Australian guy who's done some really good work. GOMA is G-O-M-A-H is his GitHub user. Anyway,

 

Okay.

 

that's not out yet for Nux 3. There is a GraphQL Nux 3 thing out there that's pretty cool. It does some interesting stuff. Basically, like, imports all your GraphQL queries as functions. So

 

Mm-hmm.

 

that's kind of interesting. It's a new approach that I hadn't seen before. It's pretty opinionated. You end up with a bunch of functions in your code that you don't know where they came from, and you just have to know, oh, all the ones starting with GQL mean that they're GraphQL queries, but they look like functions. And

 

Right.

 

so I'm a little scared of that. It just can look, I don't know. Whenever I see a function that I don't know where it came from or where it's declared, and it's just magically injected, it starts to get confusing when you're dealing with big websites like that. scary, but I like the developer experience there. It sounds easy. So I have to sort of look at that one a bit more. And then there's anyone else out there that's dealing with Nox sites, there is a plugin function called enable preview that basically you can use to put a static generated or server side rendered version of Nox into an SPA mode just on one request if based, we use it based on a query string. So if the query string has question Load fresh data from this from the API don't load the static stuff

 

Oh,

 

Which

 

interesting.

 

is really important for like previewing content out of a CMS and

 

Oh, that's

 

I

 

cool.

 

haven't

 

Okay.

 

yeah, that's how you do previews in nux2 and I can't find the nux3 version of that yet So those are the four things out there that I really need working in nux3 for us yet So it's still a bit early and then as um you know you pointed out there with Daniel and the and the ISG stuff. The docs are still early days. I mean, still so much better than most docs, but there's still some important things kind of missing that can be a little bit confusing. So it's still a little early for us, I think, for Nux 3. But end of life for View 3 is like the end of the year. So we're all having to kind of move eventually.

 

and a life review 3.

 

Well, end of support for View 2.

 

You said B3.

 

Yeah, yeah, sorry, sorry, yeah. End of... end of year two is the end of this year I think. So we're gonna

 

into

 

have

 

support

 

to all move.

 

or are they just not developing anymore?

 

No more developer for it anymore, like no more

 

OK.

 

versions, I don't think.

 

Right. Interesting.

 

So, not that I sort of needed new versions of Vue recently, but that's happening.

 

Cool. Alrighty, so we covered quite a bit of ground here. Again, a lot of basic stuff, but hopefully useful to some people out there. I always enjoy talking about inertia and view for sure, just because of how nice it is and how inertia handles quite a bit of things for you. And does it very quickly too. So with that, we'll move on to pics. Pics are the part of the show where we get to talk about things other than view or we can't talk about view in tech if we want. It just depends on the day. I'll go first today. Granted, I'm doing the high point of every podcast before we get to the guest but I think Drew understands that. One is an article that was brought to my attention by Chuck Wood, the guy who owns Top End Devs. It's from the British Psychological Society, And it's about the awesomeness of dad jokes. It's called dad jokes. That's the way I roll. That's E-Y-E roll. And just talks about really some sort of scientific studies about dad jokes and why dads do them. And one of them I thought the most interesting things, conclusions in the article is, do they serve a pedagogic function? I think I said that right. In other words, do they help your kids learn? And so this paragraph says, in light of this, it's worth considering dad jokes as a pedagogical tool that may serve a beneficial function for the very children who roll their eyes at them by continuing telling their children jokes that are so bad that they're embarrassing. Fathers may push their children's limits for how much embarrassment they can handle. They show their child and that embarrassment isn't fatal, which is something I prove on this podcast every week. So anyway. It's sort of funny to see scientific treatise on dad jokes.

 

Uh-oh, so you're now backed by science, Steve.

 

I am backed by science. And my, uh, when I show this to my daughters, like, oh man, my, or my family, like, oh man, that's just going to give him more incentive.

 

Thank you. Bye.

 

You know, so

 

Yep.

 

please dad, stop telling me the dad joke. Hey, I'm backed by science

 

Yeah,

 

now.

 

this is good

 

I can

 

for

 

prove

 

you.

 

it here. Read this. Right. So, and then speaking of the dad jokes, it's time for the, the dad jokes of the week.

 

Oh, you're just gonna skip

 

Um,

 

over my pics? We're going straight into...

 

no, no, no, no, no, no. we'll

 

Oh, we

 

go

 

do

 

to

 

dad

 

you.

 

jokes first, all right. All right.

 

Yeah, yeah, that's why I said it'd be sort of a letdown afterwards,

 

Ah,

 

but

 

yes, nice.

 

don't take it personally. And by the way, I do have to say that last podcast when I had to drop out and you Daniel took over, I'll give you an A for effort.

 

Ha ha

 

And,

 

ha!

 

and we'll just leave it at that.

 

Yeah, thank

 

So,

 

you.

 

you know, listeners will know that I appreciate the cow joke when it comes to dad jokes. So my new one is what do you call a group of cows? It's a bit of a stretch, but just roll with it. What do you call a group of cows playing poker on a mountain top?

 

No.

 

a high stakes game. All right. And then switching to movies, there's supposed to be a new time travel movie coming out next year. It was actually pretty good. Right? And then I got a call from a school the other day. They said, your son has been telling lies. I said, tell him he's bloody good at it because I don't have any kids. Thank you. Those are the dad jokes of the week. So what do you got for us for Pixdrew?

 

Not as good as that. Just a really interesting thing we've been doing this week at Funk House. We've been playing around with variable fonts, which if anyone's not familiar with what those are is, you know, normal font file will have a bunch of variations. You'll have, you know, regular, italic. You might have, you know, even more oblique or even more angled ones. And then you might have like bold and regular and medium and super heavy. in these different weights. Well what variable fonts are is a font that there is no set, you know, variations and there's no set weight. It's a scale. So you can control how thick it is, but all the way up. It's not just like in increments. You can go one, you know, one pixel at a time basically in weight and same with slant. So how, what angle, like you don't have to just be like italic. be zero degrees, one degree, two degree, you know, can go negative and positive. And so you can have fonts go in all kinds of directions. Very useful for just like the size because you only need one font file. You don't need to load all these different variations. But also allows you to do some really cool stuff like change the weight of the font and change the angle and all this sort of stuff based on different effects. And like, so we're building a website for a client. magnetic fields. So it's magnetic. And so we've made the font sort of follow the cursor around like a magnet, you know. And so it moves around and looks really cool. So variable fonts. And there's a website you can see this in action. That's also just a really cool website to look at called GT-Planer.com, P-L-A-N-A-R.com.

 

Mm.

 

And that's the name of the font. And it's a variable font. And they've built this like cool micro site that those are folders and different things you can do with it. It's pretty cool. It's worth checking out. It's pretty cool. It's worth checking out. It's pretty cool. It's worth checking out. It's pretty cool. It's pretty cool. It's worth checking out. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool. It's pretty cool.

 

Oh, well, that's an old school website.

 

Yeah, it looks like a sort of Star Wars-y video game from the 90s, but it's all showing off

 

Oh

 

fun.

 

yeah.

 

It's really cool.

 

Minds me, yeah, that are asteroid. Well, no, not quite. So it's only this particular font that is variable?

 

Well, no, this is the first time we've used one.

 

Is that the gist?

 

But anyone, there's a bunch of different variable fonts now. And I believe, I think the future of web fonts

 

Oh.

 

will be all variable eventually. [?

 

Yeah, that's all ball bearings these days. We'll be cord if anybody knows what that is. You get bonus points. Alrighty, so with that, we will wrap up this episode on Vue. Thank you for coming at us from the wilds of New York. And good to have you again. And we will talk to y'all next time on Vue's on Vue.

 

Thanks.