Coding Blocks - JAMstack with J.A.M.

Episode Date: February 4, 2019

We learn all about JAMstack in real-time as Michael lowers the bar with new jokes, Allen submits a pull request, and Joe still owes us a tattoo.

You're listening to Coding Blocks, episode 99. Subscribe to us and leave us a review on iTunes to hear more using your favorite podcast app. And visit us at CodingBlocks.net where you can find show notes, examples, discussion, and a lot more. Send your feedback, questions, and rants to comments at CodingBlocks.net. Follow us on Twitter at CodingBlocks or head to www.CodingBlocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood. Oh, I'm Joe Zach and I'm a millennial. What? And I'm Michael Outlaw. What?

This episode is sponsored by Datadog, a monitoring platform for cloud scale infrastructure and applications. Datadog provides dashboarding, alerting, application performance monitoring, and log management in one tightly integrated platform so you can get end-to-end visibility quickly. Visualize key metrics, set alerts to identify anomalies, and collaborate with your team to troubleshoot and fix issues fast. Try it yourself today by starting a free 14-day trial and also receive a free Datadog t-shirt. Head to www.datadog.com slash codingblocks

to see how Datadog can provide real-time visibility into your application. Again, visit www.datadog.com slash coding blocks to sign up today. All right. So today we're going to be talking about a subject that Joe has been excited to talk to us about for a while, and that's all things Jamstack. But first, let's take a moment to say thanks. Yes, let's do.

So as always, for those that took the time to leave us reviews and several of them actually mentioned that, you know, after months of being asked, I finally did this. Thank you for doing this. So in iTunes, we have Scooby Bee Jesus, Mike McDev, and Krausling. Yeah, on over and can't say Stitcher, but you can probably say the say the names. Yeah. So, yes, Stitcher. can't say stitcher but you can probably say the say the names yeah so yes it's a stitcher you've got uh machiavelli askarov and brick gw man that's machiavello man come on yeah and macco yeah i'm sorry all right and then one that uh i found that had slipped through somehow i wanted to say a special thank you from an email review that we got from Travis T. Yes.

Not Travis T. No, yeah. He didn't say whether or not to specify his full name, so I'm doing him the favor of assuming that he doesn't want his full name mentioned. But Travis knows who he is, and we thank you, Travis. Yep. And this Jamstack, is that people that like to eat pancakes with jelly on them or is this? Yes.

Did anybody else think that? Chocolate chip pancakes. I hope that you're listening, that you are ready for a night full of jokes just like that. Classy. They're always classy. Wait, are you trying to say that they're not going to get any better? Hold on.

I mean, it's only going to go down from here. I do have some jokes for you. Hey, are you trying to say that they're not going to get any better? Hold on. I mean, it's only going to go down from here. I do have some jokes for you. Hey, do you? I do. Let's get one. Oh, you want one right now? It's been a while, man. Okay.

So this will be, I'm going to give some credit where credit's due on these jokes as we go through these. So from Nathan, these are old too. Like we received these a while back, long time ago. So Nathan wrote to us and said, a guy walks into a bar and asks for 1.4 root beers.

The bartender says, I'll have to charge you extra. That's a root beer float. The guy says, in that case, make it a double. I like it. That's good.

Very nice. I'm setting the bar for where the jokes are going to be for the evening. That's a perfect one. Prepare yourself. All right. All right. I don't know if I can. Okay.

Let me say this. You've been warned. All right. And speaking of warnings, I just want to let you know ahead of time, this episode does heavily reference front-end coding. So if that's something that offends you or triggers you, then you might want to skip this episode. That's ridiculous. Oh, you know what we didn't put in the news that we should?

Because this is going to be leading up to it, I think all three of us are going to be in Orlando March 30th. Is that right? March 30th? One of the marches. It's either 29th or 30th. Don't quote me yet. But at Orlando Code Camp, we're going to be down there. So anybody that wants to come out and say hi to us, we're actually doing a booth at Orlando Code Camp.

I think Joe and I might be speaking and Outlaw might get roped into a talk. So, yeah. I mean, if you're down that way, definitely come say hi to us. Kick Joe in the shins. I'll watch and laugh. And, yeah, I mean, if you're down that way, definitely come say hi to us. You know, kick Joe in the shins. I'll watch and laugh. And, yeah, that's it. Hopefully that'll give some time for people to know to be there. Yep, and looking forward to that.

And so that's going to be fun. I'm going to be hopefully talking about search stuff. I was tempted to talk about Jamstack, actually, but I was afraid that with people in the actual audience that I might get called out on my jam stackiness. So I don't know about that. I don't know what I'm talking about. I submitted the topic and I honestly forgot what it is.

So I might talk about something. What would be hilarious is if you forget what the topic is and can't go back and find it. And you come up with another talk on something else. And then everybody shows up and they're like, wait but it would be like hilarious in like a really bad way so i say that that's like really disturbing that i would find it funny but there would be some humor to it i think that might actually in like a very dark way i think it might happen dude because these forms that you submit online to these places they go off into the ether and unless you copied and pasted that stuff somewhere it's gone like i

have no idea what it is all you know it would just all you got to do is just ask i'm sure they'll tell you like what you signed up for or better yet it's probably listed on the site hey don't talk sense to me yeah whoa hey this this is not some backbard this is orlando you can log in and see exactly what you submitted and you can even edit it right now. See? I don't believe that. See? Yeah, man, totally. And Santosh, if you're listening, Alan is totally kidding about not knowing what he's talking about. You just got to be resourceful. That's all it is, man.

Whatever. And the website for the conference is actually all open source. So if you want to add some features in there, you can actually do that online. Excellent. Or some crypto mining. Yeah. So sorry for the derailing. Definitely sneak in some crypto mining. Yeah. So sorry for the derailing. Definitely sneak in some crypto mining.

All right. So speaking of crypto mining, and actually this has nothing to do with crypto mining, we're going to be talking about Jamstack tonight. And if you're not familiar with the term, then you're in good company because a lot of people haven't heard of the term. It's kind of a newer kind of way of dealing with creating websites and web apps that's gaining popularity. And I'm really excited about it for various reasons which we're going to get into but i also could see why it's kind of controversial and so i thought

it would be a fun topic for the show cool and actually i think uh glanks i think we owe glanks g flanks for uh this idea actually so it wasn't so much my idea but he got me into it so So thank you. And first of all, what Jamstack stands for, right? So there's the jam in there. And we've got JavaScript, APIs, and markup. And these are three words that you probably know, even if you're not familiar with Jamstack,

because it's really common. These are things that we know how to deal with as programmers, right? Doesn't that sound like just all the normal stuff that we already do? Yeah, I was going to say that's kind of what it is. Yeah, absolutely. And so there's really nothing groundbreaking or crazy about this approach. It's just kind of taking away a few things that are outside of that that are typically involved in web applications, getting rid of those things, treating them like third parties, and then using some kind of modern tooling and some services that are out now and popular

in order to really make these things kind of gel and excel. Sorry, you guys aren't laughing. I thought it was pretty good. Gel and excel. All right, sorry. I'm trying. Hey, man, I set the bar for where the humor was supposed to be for the evening.

What are you doing? Yeah. Starting off 2019 with a wah-wah. All right. So the definition of JAMstack as given by the JAMstack people over at Netlify who actually coined the term is modern web development architecture based on client-side javascript reusable apis and pre-built markup same thing kind of said earlier but um i think it's really important there to highlight that this was done by netlify this is coined by netlify and really promoted by them heavily and they're a company that we've talked about before that does

basically static site hosting and they they have a couple services that they use to make money. Like you can do forms or they'll actually make your life a little bit easier for some serverless functions type things. And they can do auth for you for a little bit of upcharge. But for the most part, they're kind of a CDN company, right? Maybe I'm getting ahead. And if it is, then you can definitely delay the answer to this question. But how is this different than like a React app? And if it is, then you can definitely delay the answer to this question.

But how is this different than like a React app, for example? React would be a great way of building a JAMstack site. Right. So I think – So we're just giving a name to something that already exists is what we're saying? Sort of. What wouldn't be a JAMstack would be mvc standard dot net application right like that's probably an example of of one where your where your server side's kind of bundled to your front end code right yeah so like in 1998 if you

would ask me you know joe you're building a website. What are you doing? And I would have told you, you know, HTML and maybe, maybe if it was late 1980, 1998, 1999, I might've said DHTML, right. Or, uh, you know, 4.0 transitional or something, right. XHTML. But, uh, pretty much from like 2000, you know, 2001 on, if you would have asked me what I'm building my site in, I would have said Cold Fusion, PHP, ASP, Ruby on Rails. But hold on. Let's back up, too, though. What you said about React is true, except for this little thing there at the end that I think we should have an asterisk on, which is the pre-built markup. I think that's where this sort of diverges a little bit, and I think you're probably

going to jump into this here in a minute, right? Well, I read that as that would be like your JSX, right? No, no. Yeah. Yeah. I did a little bit of reading on this.

I was curious. So yeah. See, I wanted to come into this completely dumb. So I'm doing this on purpose. This is nice. Yeah. Yeah.

Cynical dev style. Love you, James. Yeah, so the deal with the markup is that's just a structured way of kind of storing your content. And then you then kind of go and mash in with your layout and generate those pages. And really the contrast there is just that you're not doing it in HTML. You're trying to keep it separated from the look and feel of your website. And you're also not tied to some sort of backend service

like a Ruby on Rails or a WordPress or something. I mean, even when we did the coding block site, I don't even think we really considered kind of hand rolling HTML, right? It was kind of a foregone conclusion that we'd either be building it on our own

and like ASP, or we'd be using something like WordPress, which is what we ended up doing. Yeah, basically, so we can focus on the content and not worry about the development because we all know how that goes. But hey, backing up real quick, and we've probably said this in previous shows, you threw out CDN out there. For those that aren't aware of what a CDN is, it's a cloud delivery network.

It's AWS has their own. It's called CloudFront. I'm sure Azure has their own. CloudFlare has their own, it's called CloudFront. I'm sure Azure has their own, CloudFlare has their own, but it's basically companies hosting your files that are, you know, so that you're not serving them up yourself from your own servers. They're, they're hosted from other places and they're typically faster and closer to where people are. So if you're not familiar with CDN, that's what it is. I do want to make one correction. Did I say it wrong?

I'm sure that somebody out there probably just like they're twinging and like they forgot their medicine, their medication, and they're tweaking. It's like seven-minute apps. Did I miss one piece of it? Well, it's content delivery network, not cloud. Content delivery. I mean, it is the cloud. It is, yeah. But it's technically content delivery network.

So yeah, it's just files being hosted all over the place, just not being served up directly from you. I just helped somebody stop twitching. So thank you. Yeah. Yeah. We say all over the place. We mean typically in like edge locations. So your same copies of the files might be on a server in Singapore and New York and Australia and different places around the world that are like physically located closer to people browsing the website. So like we're literally cutting the, you know, the light speed that's required to get stuff to people. Yeah. Yeah. It's all about speed and it's also about bandwidth too, right? Like you don't want to have to serve up files from California over to China. If you can have those same files located

in China somewhere, it makes sense for network congestion and everything else to be serving them up from as close to you as possible. So yeah, it's just one of those things, like when we throw out acronyms, it's easy for us because we're always in them, you know, I didn't want anybody to be lost on that. It's definitely, and there's definitely been more players in recent years too. I mean, like I can remember when, like, like you know when you talked about cdns it felt like you only ever talked about akamai or level three and that those were those were your big ones and now like you said there's cloud flare aws is in there like well pretty much any of the cloud providers are in there now yep or have something similar you know yeah yeah and i

just think it's a particularly interested to talk about jam stack today because you know just like talked about five years ago six years years ago, that's debatable. Anyway, when we started CodingBox, it was kind of a foregone conclusion that we would do WordPress or something like that. And I think for many years, that has been the question is like, what framework am I going to use? And I feel like that question has changed a few times. Like in the early 90s and 2000s, the question started to become, can this be a website first? And that started to become the main product aside from the way we used to do things with desktop applications. And then even further, after that, it started to become, should this be mobile first?

And so that was really the focus because that came to be the primary devices for most people in the world. I feel like somewhere in between there, though, there was like, well, can it be a Java applet? Yeah, that was definitely in there. And so now I'm starting to think like maybe the question we should ask before asking if it should be mobile first or if it needs to be a website is maybe, maybe it should be, we should default to static sites.

Yeah. That's one thing I was going to ask about this. Is it, is it, is the idea here of like flattening the site to where everything is already static? It's pre-genned. Yeah. Yeah, and that's what that asterisk at the end, the pre-built markup is. And he'll get into some of that in a little bit, but that's the whole idea is you don't deploy something like a live breathing site attached to a database or anything. It's not that.

You're just deploying the files that are going to be served up how they exist. Yeah, I mean, you might hear me say to that, refer to that as flattening on because like, I don't know if that's's used elsewhere but i know definitely way back in like the 90s uh you know you'd pre-gen things yeah we called it we had everything like you know yeah you had things being served off of a database and everything in the queries and whatnot but you know it was too slow to do that so to get the page views that we wanted you know to get the performance that we wanted out of the web server, we had a Perl process that would go and walk the site, and it would save off what was generated, and those flat files were the ones that were actually getting served to a user.

They didn't know behind the scenes what was really happening. We're regressing. So I'm just saying, if you hear me refer to it as flattening again, that might happen. That is what it is. That's what I'm referring to. Yeah, if I, if you hear me refer to it as flattening again, that might happen. That is what, that's what I'm referring to. Yeah. Yeah. And I definitely think we've kind of come around full circle and then that kind of begs

the question is like, well, why were we using WordPress? Why were we using Ruby on rails or cold fusion? Like what were we getting out of that? I would guess that, Oh, was that a rhetorical question? No, no, no. The real question. I was going to say, like, I guess, I think that we, we, we are cyclic, right? Like, uh, things were slow.

And so we did the flattening, like I described, but then as things got faster, we're like, you know what? We can actually take the hit of trying to serve this in real time and without having to bother with the flattening process. And then we start cramming so much into it that, you know, we start squeezing everything out of it. It's like, oh man, we've gotten slow again. So we have to like flatten again.

And so we start to lean more towards static again. So like, it's just like, I mean, you remember like back in the day, for example, like you tried to prefer HTTP over https every opportunity you could like you literally only used https for just the authentication part and then you like page you got back out of it as quickly as possible because you just didn't have the processing power to keep up with it but now we're like well let'sPS everything. And if you don't, then you get downgraded. Yeah, but the point being is like the processors and everything have gotten fast enough to where that extra cryptographic step is no longer a thing. And now we're like actually trying to, you know, like remember the speedy protocol from a few years back where like we're trying to prefer it.

And actually it's now being you know improvements are being made to make it faster right um i don't know if we're going to come back to the cyclic point where we you know god i would hope that we don't go back to non-htps but well i think with that question you asked i i think it's even worth maybe talking about wordpress and what it is and and, because I think it'll help sort of paint the picture a little bit, right? Like we chose WordPress for the very reason that anytime you create, if you create a static website, it's typically a lot of work, right? A lot of people don't realize it, but you know, you've got your headers, you've got your secondary

nav. If you've got that, you need consistent footers, you need all that kind of stuff. And really the only thing that you're changing most of the time is the body in the middle and then styling all that, making sure it's all pretty. Right. And, and WordPress sort of takes that away in that you can just go download a theme for WordPress and that'll make your site pretty. And it can standardize your navigation on your left and on your top and all that. And then you can get, you know, the various different pieces you want to fill in stuff. And then all you have to worry about is putting together your content, right? And so if we write an article on how to make SQL Server faster,

then all we have to worry about is what we want to write and what we want to show up on the page. Now, behind the scenes, WordPress is calling some PHP things that are basically saying, okay, he called the page that we just called, you know, how to make SQL Server faster. So it's going to go load up the headers, and it's going to place those, and it's going to load up the navigation bars, and it's going to load up the content, and it's going to put that in place. And it's going to replace all the date tags,

and it's going to replace who the author was. And it's pulling all this stuff from the database and putting all this stuff together and putting it in content on the page. Right? So the reason we have those applications is we don't want to, we don't want to mess with that. Right? Like, I don't want to have to worry with what am I going to name my page? What am I going to name my file? Did I link that properly for my index page to this one? Right? Like my homepage is index.html. And did I name that how to make SQL faster.html or did I make it how dash to dash make it? You know what I'm saying?

Like there's all these little bits and pieces that require a ton of work when you're creating a static webpage. And that's why people use things like WordPress. You don't have to worry about it. You log into the thing and you type in your content and you hit save. And then every time somebody hits a page is running some PHP. Nobody cares about it. As long as it loads, then you don't care. But to outlaws point and what Joe's probably getting ready to say is now this stuff is being served up on devices that we didn't anticipate a few years ago, right?

Now it's mobile phones loading things. Now you're loading something across the U.S. Now you're loading something across the world. And so now speed matters again, right? You can't just load up 100 different things and hope it's all good enough. And so I think hopefully that draws the picture of why we're using those things. And now I think we'll get into why maybe, why maybe there's another way to go about this.

Do you want to hear some interesting WordPress stats? I would. All right. Uh, I'll include some links to these, but 27% of the internet is powered by WordPress. Oh my goodness. So it's estimated that there are over 172 million active websites with 75 million of those being on WordPress and 30 half of those 337 and a half million of those being hosted on WordPress.com itself.

Wow. Right? And this one is dated from, this is a stat from 2014, 22% of new US registered domains run on WordPress. It's not surprising. Now, here's another one that's dated, this will be the last one I'll give for dated to 2014. WordPress.com gets more unique visitors than Amazon in the US. Wow. As of 2014, WordPress.com was getting 126 million uniques per month.

Amazon was getting 96 million. So it was a considerable difference. That's impressive. And, oh, I'm sorry. That was also with only 229 people employed by WordPress. Wow. I mean, when you think about it, again, we actually

made the conscious decision when we started coding blocks. We're all developers. If we start writing something, we're never going to finish it because it's never going to be good enough. And we're going to code it and code it and code it and code it. And we're going to spend all our time coding. We wouldn't be making content. We knew that.

So that was kind of the reason we went that route. And it's just sort of interesting to know. That's also why a quarter of the world's websites run on it, because you can get a site up and running in 30 minutes and have all your plugins and everything you need, and you got something. Do that. Make a website in 30 minutes and see if that's real. Yeah, it's very user-friendly. It looks great with the theme. It's much better than I probably could have done by myself.

It was also a great user experience for me to be able to go log in and just write a post and focus on the things that I care about. I don't have to be messing with footers. Can you imagine we've got 99 episodes now if we had to go change the footer on 99 HTML files for every blog post. That's the kind of stuff that we used to do. I used to get paid back in 1998 to do crap like that. Right. Right. But aside from WordPress, why did we used to reach for the ASPs and ColdFusion? What did we get from those technologies that we didn't get with HTML files? A framework.

A framework is part of it. So some sort of consistent way of solving common problems. But two big things for me that kind of spring to mind were server-side includes. So I could have that footer and include it on one spot and only change it in one spot and then kind of have that, you know, like Alan said, kind of poke a hole in there for the content that I cared about, like the author or the body or whatever. That and also easy database access. So I could have dynamic content, throw it in a table, and then I wouldn't need to have all these different pages, right? I would have kind of one page template and it would get filled in automatically and the URLs would route to it automatically. Yep. Yeah. And that was, that was huge. That was really good. So, you know,

what have we done that's come full circle? You know, we kind of said that there's not really been any like super new developments. There's not like a new feature of JavaScript that suddenly enabled this and made it important. Right. So why are we talking about this now? And, uh, I think a big part of it is actually the static sites have gotten a lot more powerful there's more stuff that you can do in javascript a lot easier so it's not like there was one easy new javascript feature but things like um progressive web apps and um bower not bower um babble definitely bower kind of newer features bower uh yeah react stuff like that um has kind of made things more powerful and made us be able to do more stuff with JavaScript, but also things like serverless functions.

So those are really cheap and easy functions where we can kind of forget about the operating system, focus on the little tests that we need to do. Microservices is another good example of something where we've got these kind of easily consumable APIs that I can call from JavaScript very easily. And now I've got things like in JavaScript, like Fetch or whatever, that make that a lot less painful than it used to be. And also, I really want to point out, this is kind of the big one for me,

is that there are more and more software-as-a-service and cloud components that are kind of commoditizing things that I used to do. It used to be a foregone conclusion that every time I would work on an e-commerce site, that I would spend a lot of time on the billing aspects. I would find that billing API, and hopefully it was one I'd worked with before, but there would still just be kind of custom things I would have to hook in to make it work for Braintree or PayPal or Authorize.net, whatever. And nowadays, if I was starting an e-commerce, I would just use Stripe or PayPal. Right.

Right? I am curious, though, as we're going through some of these things, like I know we mentioned you got React, Vue, that kind of stuff. And this is where things were fuzzy when I was reading through some of the jam stack things is I know the notion is the static files get generated at deploy time, right? Like that,

that's kind of what you do. Like when you're ready to push a site out, these things will run through some sort of processor. It'll take all that, create HTML files and throw them out there. Right? Like in a nutshell, is that right? That's what static site generators do, but HTML files and throw them out there. Right. Like in a nutshell, is that right?

That's what static site generators do, but that's not a requirement. Okay. So I guess that's where I'm sort of curious is like, this sounds great. Fine and Danny for just content based sites. Right. So like coding blocks would be a perfect example. We don't, you know, ours is mostly just content that's out there. However, what about an application? So like you're talking about, you just talked about Stripe. Stripe is going to be something that you're going to put on, you know, you've got content to sell or something like that, how does Jamstack fit into that world? Yeah, and that's a really good question. I think that it basically suffers from the same problems that any spa-type app would have, where if you've got some sort of spa application that's dealing with a lot of stuff from endpoints and kind of filling in the content like that's not great for all use cases like i used to work with a b a lot of b2b e-commerce sites and you would log in before you could see the products because the

pricing would change because each individual company would kind of negotiate the prices and so we don't want customer a to necessarily see the prices for customer b and so we may not even want to show you the products that are available because it may be different based on our contract. And so that kind of thing is not so easy to do in a spa because it just means slinging a lot of stuff. And so I think that there are still applications that are just better off being kind of traditional back-end-y Django Ruby on Rails type sites. And I think that's totally fine. And the kind of things that I came up with were basically things that require fine-grained permissions. Also, things with a lot of real-time persistence

or database stuff going back and forth or things with a lot of admin-y, kind of control panel-y type things. I wouldn't want to build a Jamstack site for the WordPress back-end where you can log in, see posts, approve posts. There's permission and stuff going on. There's widgets.

There's plugins. There's all sorts of stuff like that that interacts at all different levels of the application from the JavaScript all the that down to to what i'm thinking in my head is as long as basically every user would have a similar view or the same view then maybe it's a jam stack viable option if you've got something where you're switching based off a user's role or various permissions or where you're toggling things all over the place because of that, then it's probably not a good thing, right? Well, am I wrong? You're not going to have any dynamic content.

So you can interact with APIs. So that's the A in the JAM stack is those third-party APIs. So if you want to have that Stripe or if you want to write your own custom third-party APIs and that's also doable. No, no, no. wait, wait, wait, I don't mean, I don't like you talk about that and you're talking about like authorizing a payment

or, uh, authenticating, right. When you talk about like Stripe or OAuth kind of things, I'm talking about like something dynamic to where like take an amazon.com where if you go look at a particular product and they're like only nine left in stock right and the next person that loads that page it might be only seven left in stock right that's the kind of thing that i'm talking about like something dynamic on the page that's going to change every time the page is loaded you're not going to have that in a jam stack application you could you could because of what he's saying so and this is where things would get really tough and i don't know the lines blur on how far you'd want to push it now and how much effort you'd actually have to go through.

So your page itself, the HTML is rendered, right? But you can make an API call on that product and that, that product information and come back to you and say, Hey, there's only seven left. Right.

And that would just plop on your page somewhere, right? How would that be differentop on your page somewhere, right? How would that be different than any other page then? At that point, because now you can say, okay, I could do the same thing for the description of the product. But you're going to have a particular product page, right? So the difference is, I think, and correct me if I'm wrong here, Joe, you'd probably have something like, I don't know, the new MacBook Pro.

There's going to be a MacBookPro.html. And when you load that page, it's going to make a call to go get the latest information for that product and then bring it back to fill in that page. You're not going to have a generic product page that says, okay, go pull all the information and then build all the HTML on this page. I think this is the difference, right? I mean, regardless of what the name of the page is, that can – oh, thank you, Google. You can create – you can solve that problem by having like a page that might not – there might not be a physical file on disk that matches that name of that. But at runtime, you're like, oh, well, that's the product. So like, you know, your MacBook pro dot HTML, you're like, okay, you know, that is the product name. I'm going to go query that. And it could be like just the one generic thing. Cause we've done that. The three of the

three of us I know have done that. So, you know, like that's just creating like a canonical URL that's SEO friendly at that point. Right. I'm trying to figure out like where do you draw the line of like the dynamic content that can appear? I don't know. But yeah, pages can make calls to APIs to get that data, though. Yeah, absolutely. So the question is like what is the difference between like Jamstack and any other app that we've done over the last 20 years? And I think what you said is totally right.

Like it's just a matter of kind of where you turn that dial. But I do think in the kind of traditional ASP or, you know, PHP kind of setup, like you would have like one kind of page template that would pull that information from a database or from a cache and put it in there. The difference here, though, is that we're emphasizing this static generation so that we can throw these files on the CDN. So what's the difference between having like product.aspx that goes to the database or having 10,000 static HTML files? The difference is the CDN. And you can get clever with CDNs. You can kind of cache stuff or whatnot. It's just kind of the notion here that we're kind of taking that approach up front and starting with things and going at it from that

angle. So tell me this then, if we're talking about statically generated files, like what he just said with a canonical URL, if you've got something like IS or Apache or whatever, you can have these rewrite rules is basically what they're called, right? To where it says, hey, look for a pattern in the URL. And if it's this, then serve up this file. Is that part of this whole Jamstack notion to where you're dealing with that, or is it literally you go to this page, and it's going to go find that on a CDN somewhere? So that's what we're getting rid of. We're saying static first, no Apache.

And when you think about it, even talking about things like Apaches or the web servers, it's kind of coming at it from uh like a very like web app centric single project kind of way of thinking about things like the like back in the day i would create new project i would select asp and now i would think of this whole thing as my website but now i'm saying it's like you know what microservices are a thing i've got all these cloudy and software as a service products going on. Like I can't really put my finger on exactly what my web app is. It's kind of like this interconnected kind of mesh of services. So why not have one thing?

My web app is this set of static files and it pulls the data from however many APIs I want. And that way, if I want microservices and my, my, my app is three or four different services or however many, and that's fine. It's all just about where I'm coming from.

So rather than me be going into Visual Studio and saying new project, I would go into VS Code and say new directory, and maybe I would open up Visual Studio on the side and create a web API or whatever I need to for third-party services. It's just a matter of kind of thinking about things differently and coming at it from a static first angle. Okay. So that's really interesting. So what you just said forced me to go to jamstack.org and click on the best practices at the top. And what you said at the very beginning of that is exactly what it is. So outlaw, I think it answers our question here,

the entire project on a CDN. So, so basically there is no server side. There's no canonical URLs that doesn't exist. You can't do it. You're serving up whatever page you go to has to exist. So it's not like you've got some sort of Apache or Nginx or anything like that behind the scenes that's doing any interpreting and routing. Um, everything lives on get or in get. So basically source control. I don't think they're really trying to say that that has to be it. But, but basically all your codes there and it's going to get generated using a build tool and then spit it out into a CDN is basically what it sounds like.

Right. Go ahead. Well, I was just going to say like, I'll, I'll keep listening. Cause I'm still trying to understand like, where do I draw the line?

Like, and to me, that example of, like, the Amazon one where it's like only six left in stock, you know, that's the one where I'm, like, having trouble because you can't pre-gen that. No, no, but you can pre-gen the page. You can pre-gen the page that has the images and all the text about it, the description, all that. But on that page, there could also be an API call to say, hey, go get the latest inventory for this product and plop that into the page. Like fill in this space over here that says inventory on hand. Here it is.

But then at that point, it's not pre-generated markup. It is. Joe? Yeah, I mean, if we're just talking about, or rather I should say we're not talking about 100% static sites because then we'd just be talking about HTML. We've got this A in there, the APIs, that's really focused on getting that sort of live content. So if we need to have a sale or the product runs out or we need to take it offline or something, then we have an API that we can do set up for that in the background. And the webpage can load and it can go pull that stuff and can change its content as needed. The difference is rather than having kind of one page template that pulls that stuff from the database or from cache real time, we've got thousands and thousands or however many products we have.

Same copies of the code that all know how to do this one thing and know how to go look up their extra information, which seems ludicrous if you're maintaining this by hand to have all these duplicate files, but it works out really great for CDNs. I want to keep listening to how the thing's constructed. We can move along.

We'll keep talking about it. I definitely think the important thing to think about with Jamstack, or the so we can go move along and we'll keep talking about like i definitely think it's kind of the important thing to think about with jam stacker the the reason that we're even talking about is basically this controversy this questioning this this wondering whether we've been doing things right for years and whether we should continue to do them the way they are and i don't know what the answer is but i think that jam stack asks some interesting questions well because for example you know one of the questions that is kind of on my mind that, you know, I'm going to throw it out there now so that you can answer it eventually. It doesn't have to be right now, but, um, you know, like I was

thinking like, okay, well, how is that going to look right? Because if we're not talking about it being like a react and GSX kind of thing, right. Are we talking about like, I'm going back to jQuery and jQuery is going to like make that api call and it's going to like manipulate the dom on the fly for that single page like and every time i reload the page i'm reloading another copy of j or every time i go to a new page i'm reloading whatever my app was be it you know a jquery library or whatever i don't think that's it right like you're building your app in react or you're building your app in all those things. The step for deploying is what's going to take those and turn those into the static files.

So you're not jQuerying it. You still got React in there. I still need some JavaScript, though. Yeah. So that when it runs on the client for that API call, that's the part that I'm asking for. But that'd still be written in React, right? That doesn't necessarily have to get rewritten, I wouldn't

think. So I've got an application, a Jamstack application, devpodcast.app. And it uses the QIT search engine to pull podcast data for programming podcasts, right? And I do those searches up front when I do my build, and I generate this stuff. So I don't have to hit

the search engine over and over and over again. As you browse the pages, I have that pre-generated. However, you can also do live queries from the site, which go out and they do Ajax calls via jQuery to the search engine. And so it can kind of populate with up to the date, up to the minute information or custom information. If the person doesn't have the information that I haven't pre-genned, whatever they're looking for. Man, I'm going to ask a dumb question. What was that URL again? Devpodcasts.app.

That's what it was. I knew I was typing something wrong. Yeah, and so I'm kind of cheating a little bit. If you go to the top and if you hit the hamburger and you hit the search bar, it actually redirects you to QIT. But that's a feature that i want to get into the site so it all kind of keeps you there and i i don't think that's cheating for jamstack at all it's using a third party api and actually if you go to jamstack.org and look at their examples a lot of sites are actually built with static site generators and search engines because it's a really nice pairing

where we can have all this content that you don't need to render and do all this work for with the server side, but we've also got a search engine that lets you find that content or redirects you to some other spot. So it sounds like, and I might be wrong, you wouldn't use this for an e-commerce type application. It would be overly complicated to generate

that many pages. If you had something simple or more simplistic, like maybe even the podcast app, like what you're talking about, the QIT, right? That could sort of be it because you only have a few sets of things that you're trying to do dynamically, right? Like pulling in the latest dev podcasts or whatever. I don't know that there's a limit though. And actually, um, the e-commerce sites are one of the applications that they give as an example of good transitions to eat, to a jam stack, because you can generate for all those products. And who cares if you're dealing with tens of thousands of HTML files, we're still talking about like, I don't know, megabytes to do for the whole site.

I've deployed sites that are much bigger than that with just the binaries. It's not crazy to think about you uploading 500 megabytes of binaries in an install for a large.NET website. So how many text files does it take to get up to that level? And I think it would be a whole heck of a lot. So that's interesting. I mean, I just, just for kicks, I Googled jam stack, uh, e-commerce and there's one Netlify has one on their GitHub called go commerce and all the codes there.

So if we're kind of curious or if anybody's curious at some point, where do you draw the line between the static versus the scripted API loaded stuff, then... Yeah, if you look at just kind of some of the Hacker Noon sites or Medium.com sites on Jamstack, you'll see a couple other examples of applications and tools

that are kind of aiming for specifically for e-commerce situations. Now, they're not talking about the Amazons of the world, which have millions of pages or whatever, so it's probably not appropriate for there. And certainly the tools like Gatsby or Hugo would probably not be appropriate for that because a lot of those tools are built around

regenerating the whole site at once, which is not something you would ever do for Amazon every time you add a new product. You can't imagine generating the whole thing. That would just be crazy. So they would need some sort would ever do for Amazon. Every time you add a new product, you can't imagine generating the whole thing. That would just be crazy. So they would need some sort of custom thing for that. But for a lot of smaller purposes, or if you've got a boutique e-commerce site with 500 products, why not?

So this is interesting. I'm looking at the code on this one, this GoCommerce thing, and what they've got is they'll have a page and it says, this is what your static site must support. Each product you want to sell from your static site must have unique URL where GoCommerce can find metadata needed for calculating pricing and taxes in order to verify that the order is legitimate, right? Before sending it over to Stripe.

So this is interesting. The way they set it up here is you'll have a page that has content on it, but the metadata about this thing is in a script tag. So it's got script and then class equal go, go commerce dash product, which means that means there's something that's going to be looking up that particular, you know, Dom element on the page, which in this case is a script block. And then it's got a skew, a title, and then the prices, which means that it's going to know to take that metadata and then go look up some additional information to fill in the page. So, so it's definitely mixing the static data with stuff that it plans to go get more information about from a server

call, bring it back in and then enrich that already static template. We'll call it basically. I mean, I guess that's how you're treating these pages is more as like templates where data can just kind of be plugged in. Right. Yeah.

And I think there's different ways to kind of approach that problem. Um, but I did want to mention that there's a site called content full2, which is a content management kind of storage site. What it'll do is you kind of like in your HTML or whatever, you kind of tag it with IDs and it'll go out to that service and fetch the content and populate it into the site. So it's kind of like this weird kind of, you know, it fills a certain kind of niche for sites like this that need to be able to pull their content dynamically. And maybe you do your localization or whatever there,

and they just kind of specialize at taking your content and popping it into your HTML pages. Content content full, not, I thought it was full, like F O O L it's content. I thought you said full as well. Yeah.

Content full. All right. So where does, and you know, again, stop me if you're going to get to this eventually, where does WebAssembly fit in with this? Or do the two coexist? Or do they solve different problems and you wouldn't try to do both at the same? That's a good question. I definitely think of it as solving different problems just because you know the WebAssembly I think is of being able to reuse code that I've written

in other languages and be able to run stuff fast and this stuff is really focused on on client side JS which is what we're talking about with WebAssembly too so I think that there's you know possibly some some stuff that can happen, but I haven't seen any sort of connection between those, like made any blogs or anything. That would seem kind of odd though, right? Because the whole thing with web assemblies, you're downloading the DLLs,

the C compiled things. So I don't, it's compiled. It's like, it's compiled down JavaScript, right? Or like it's, it's the safe parts that get compiled down so you could write it in

c yeah yeah i don't know so i guess you could still put that dll out on a cdn cdn yeah i mean technically i don't think there's any reason you couldn't but it seems like that's more app specific i don't i don't know yeah i don't think that's much different than like bringing in a third party kind of library like a j jQuery or something like that. It's just a different language and a very good, efficient way of doing certain things. Yeah. Oh, I did want to point out, too, just really quickly, as far as kind of tools, we talked about Stripe and OAuth as being solutions for things that have kind of come along in the last 10 years or so that have made working with static sites easier. But I also wanted to point out that a lot of sites like Cloudflare and Netlify specifically come to mind, interact with Let's Encrypt.

So normally, if I wanted to have a static site that was HTTPS, I would have to go and, you know, say 10 years ago or five years ago before Let's Encrypt existed, I would have to go buy a cert for like 99 bucks a year or whatever. I would have to go set it up on my server. I would have to have a server in order to do that. And it would be some sort of pain in the butt. But with services like Let's Encrypt and with the integration points that they have with Netlify or Cloudflare, it's a checkbox for me to say, I want HTTPS. And they own that. And that's totally out of the scope of my application so now I can have HTTPS devpodcast.app

or QGIT.cloud without having anything to do with the server which is something that you know you couldn't really have and that makes it so my cost for hosting both of those applications stays at zero okay

yeah so I think that's pretty much the both of those applications stays at zero. Okay. Yeah. So I think that's pretty much the gist of what the Jamstack is. We've got a couple more things to talk about, but I just want to kind of blow through those letters real quick. JavaScript, when I say that, we're talking about client-side JavaScript, although most of the tools that we've kind of mentioned, like Gatsby and some other ones,

still are, and even React have like a node lineage. So a lot of the build tools and CLI tools that you deal with that will still be server side. It's just the output of your build is going to be client side JavaScript. So it's not cheating to use tools.

I just wanted to draw that distinction. And actually Netlify is really good about running its node on the server to do your build. So Netlify builds QIT.app and Netlify builds devpodcast.app. It runs Gatsby for me and puts those files up somewhere. I think the key point that you're hitting at, though, is it doesn't matter what the build tools are built with. It doesn't have to be javascript it's just the output of your javascript is going to turn into static files through the build tools regardless whether they're c or ruby or whatever it doesn't matter yeah and just because we have

those tools it's not required like you could just do this via vanilla js and in fact you could do this with just static j sorry static html and c, but then you're not going to have that access to those APIs. So you need the JavaScript for that. And you need that JavaScript for transforming any markup into content. So no server-side rendering. And by that, I mean there's no back-end kind of middleware server that's running. Everything that I'm doing for the podcast app is actually rendered out to HTML file. So it's not like I'm just sending you kind of a blank div and then JavaScript is responsible for going out and populating that stuff.

I think that would probably still be valid. But you're just missing a lot of the benefits of running on a CDN there if you're going out and dynamically fetching all your stuff via API. So basically what you're saying is, though bought uh dev podcast app and now you're pointing it at netlify netlify's server yeah they're named servers okay so their name servers are what are them resolving your request to their cdn hosted, basically. Yep. Okay. Yeah, they're a CDN that's got some nice tools for looking at GitHub webhooks or whatever to notice when there's a change. They've got the node side built in,

so they'll go ahead and do my build, and they'll throw stuff up on the CDN for me. And so I can't FTP. I can't do any of that stuff. That's all managed by them. All I do is basically configure my build, click the checkbox for Let's Encrypt. I've got some optional stuff there for forms or auth if I want it. And then at the end of the procedure, I get a domain, you know, I get a website. So I see that your next bullet

point, and I'm going to jump the gun on this one because I'm sort of curious how it works. It says auth is handled outside the app, like through an API. Does that mean whatever your build tools are? So you have an app that says, Hey, you can only come to this page if you're, if you're authorized, right? You've authenticated and you're authorized to hit this page. Does that mean the build tools themselves are going to spit out the stuff that, that, that is going to somehow not allow you to land on a static page that you're not allowed to hit.

Like how I think that any privileged information that you're going to have is going to be stuff that you do not want statically up there. Okay. Whatsoever. Cause there's going to be ways for people to access to that. So if you've got privileged information, that stuff needs to come in to your application over HTTPS from an API. Okay.

So what you're saying though, is like, if you have an admin page, you're not going to statically generate that thing. It's not going to exist anywhere because, because it's on a CD. And if you figure out what that file location is, you can just go straight to it.

Yep. So not unless you're doing it badly. Okay. Okay. So, so you might have your jam stack as your front end type stuff, but as soon as you need to go do anything that requires any kind of role or permissions or anything like that, that's going to take you to a live, standard, old app that we're used to.

Well, you can still do a Jamstack. You're just going to be doing a lot of stuff like fetching the data that you need and kind of populating it into the data, but you're not going to be doing that stuff on the CDN. Well, I guess that's my question. How do you know that you're authorized? Is it setting some sort of cookie in the app? Or are you going to have to know how to code that the Jamstack way versus the old time server side type thing where you just say, hey, I know that I'm authenticated. These people can come in. I don't have to do anything special. This is really nothing too different other than who owns that

code for generating those tokens and whatnot. So if you're using something like JWT or whatever, or OAuth, then you're basically getting some sort of token that you're going to pass to your third parties, and the third parties are responsible for authorizing that token and saying, okay, here's the information that you can see. So that's out of the hands of your static files,

and it's all on the third party APIs to be responsible for returning the right stuff. Okay. Which is no different than it is today. It's just kind of a, you know, just kind of a mindset shift there. And could you imagine if you were like building the next amazon.com or something like going into visual studio and kind of doing new project and like having that be the website, like we probably wouldn't start things that way or at least we would probably end up with something that had multiple different projects and APIs and different services. It's just kind of

a way of saying, you know what? This website should be completely separate from all my other services. It shouldn't be coupled to one project in particular. That makes sense. On the API, so all service high processes or persistence are

abstracted into APIs. So that's really not anything new there other than just where that stuff is running. Now you're going to be hosting that stuff on a separate process. And so when you think about deploying the website and deploying your API, those are two separate steps. That's not something that's going to be bundled together like it would be in a traditional

ASP kind of site. Everything should be done over HTTPS, all the APIs. I think pretty much everything should just be HTTPS from now on. Yeah, I think that's about right. Yeah, and Jamstack doesn't mean that you don't have a backend. It's just a matter of kind of how you think about things so you can still build your own services you're just going to kind of treat them like third parties and you're going to go and request the data you need and handle the authorization all that stuff just like normal it's just not going to be bundled

together with your website deployment well we say just not like normal. I think going back to Outlaw's thing earlier is if you've been doing SPAs, single page apps, then most of this is sort of familiar in terms of how you go get data from a server, right? You're making some sort of API call from your JavaScript, your HTML page. The difference is this whole statically generated thing where these files exist out there and they're not being created when you request the page. And that's, that seems to be the big, I think there's connect.

I think there's a couple of different extremes here, right? So, so with the spa, you take the one time hit of loading the application and everything after that is an API, an API call to get data for whatever the screen is that you're trying to paint. Right. But you're not re-downloading your JavaScript

over and over and over again. Like all of those assets are already loaded. Uh, and that includes whatever HTML, whatever markup is baked into it. It's all of that is already preloaded. So typically it's like heavily minified so that you can do that. Right. So that's on the one extreme. Then there's the, the old extreme where you had your, your, and let's talk, let's not talk about like when I say old extreme, I'm not referring to static sites. So, so the old extreme was you, every time you would go to a different page, you were reloading the markup, reloading the HTML, as well as redownloading all the JavaScript. And then any API calls that that JavaScript need to make would also get made. So that was on the one extreme. So, so we're, we're somewhere

in between there. Right. And I think what we're saying now is that Jamstack sits somewhere in the middle now where we're offloading the responsibility of the HTML off of like a web server that we might own. And we're saying like, Hey, that, that's just going to sit on, on some CDN, right? So if I'm understanding this so far, so the HTML and the JavaScript that's out on some CDN and that HTML, uh, when you go to a particular page, it'll load every, you know, every, every new page you go to, it's going to reload that markup along with whatever JavaScript resources it needs, right? Because this isn't a spa and then you'll make those API calls calls so it is it is closer to that older version except instead of having a single server load do it we're spreading that load across the across the cdn

am i am i getting this that's that sounds right to me yep there's caching involved so theoretically you're not re-downloading the css files and all that stuff over and over and over again. Well, sure. Okay, so there's caching within at the CDN levels, but also within the browser itself. How the browser works, right. So, okay, fair enough. I'm not sure, but I'm guessing the whole point of this is time, speed to load, right. And the fact that there's no CPU involved really is what it is. It's just IO. Right. Well, yeah, that, and it's kind of like the ultimate scalability,

right. Cause we're talking about static files that are hosted on CDN. It's redundant, right. It's spread out all across the world and the chances of your you know static file hosting going down are pretty low and so we're talking about really great scalability essentially for free or for very cheap compared to every other technology well there's a big one here too though that has been said and that's that it's someone else's computer and therefore someone else's problem to maintain yep and security like you know you're not going to get into my database from my static files, right? You may be able to get in some other way, but there's a couple other advantages we've

got in a section coming up here. But everything we're saying is absolutely good. Like there's a lot of advantages to static files. Ah, your next, go ahead with your next stuff, because I think this is where it kind of gets into things that'll make a little bit more sense. Cool. Yeah, sure. So first I want to just hit on markup.

So that's the M. And that's actually the one I have the most problem with because, you know, for me, like markup, like why don't I just stick it in a database and just gen it in my, you know, my static site generator and why not just have it hit the database? It seems like a more convenient storage mechanism for me. It's just, you know, I guess the idea with markup is it's easy to check in with your project. And so anyone can modify it. You don't have to worry about setting up a Postgres or a shared server or anything like that. And so it's just a convenient mechanism to store content that's rich content, but not HTML, because theoretically, you know, we could have different things accessing this stuff and not necessarily HTML websites.

All right. I need an example here. I'm not following what you mean by this. Which part? You mean like why we would ever use markup rather than stuffing stuff in the database? Wait, when you say templated markup, are we talking about like markdown? Oh, yeah. Or J templates or something like that?

Yeah. Markup. When I say markup, it could be yaml so uh the jamstack.org site actually has a yaml file for like their example sections where they basically have some kind of content defined in different spots and the html parts are done in uh are done in in markdown but the other parts are just kind of structured with YAML. And so you can have like a image file or URL or these different things that you can kind of populate. But all of that data is associated with the GitHub repository. So anyone can go check it out

and they don't have to worry about getting data in. Like think about like if Jamstack.org had a traditional database backing it and I wanted to get the podcast app listed i would look for some sort of form on the website or maybe an email address to email and say hey can you please add my site but because this is all in markdown or markup in the yaml and it's all checked into github i was able to do that via a pull request and actually if you guys if you're listening jamstack.org i would love for you to merge that pull request. That'd be great.

So, yeah, what you're saying here then, I think I know why Allah was confused, is because we're not talking about templated markup, HTML markup now. You're just talking about some abstracted language that says the title is this, the header is this. And if it's HTML, we get rendered out to HTML. If it's something else, it'll get rendered to something else. Yeah, just the idea of keeping your content separated from the design. That's really kind of the point there. So going with your commerce example then, are you saying that like every product would already be in this format?

So what I mean is like in the e-commerce example, and like say your GitHub repository, I wouldn't have a thousand files for each of my thousand products. I would probably have maybe one file that's got all my product descriptions there, things like that. And then I would use my static site generator to read that markup file. So whether it's GML or XML or whatever, and use that to generate those 1,000 pages.

Okay. Okay. And if I was building, say, like a blog, a Jamstack blog, I might have a directory where each file in there is a markdown file that is a blog post. And so the generator would then loop through that directory on the server side on the build machine and generate an HTML file for each of those. So this goes back to what you were talking about back in the old days where you'd flatten something, you go get all that information from a database and then you gen it anyways. Yeah. I think one part that I might've missed here then is it sounds like this by template markup, you mean this is only used by the generator, the site generator, or the flattener, as I was talking about earlier. This markup isn't something that is sitting on the CDN that the client in any way retrieves.

This would be in Git, is basically what this would be. This would be code that would be executed by your generator. Yeah. If you did like a NPM build, like it's going to use that markup and then generate a file. So your Mac book pro dot HTML example from earlier, right? In,

in your products dot YAML file, you might have data about a Mac book pro and then npm build would take that data create a file a static file called macbook pro.html with that data in it yep yep okay and so that that was the kind of the hardest one for me to kind of wrap my head around because just because i wanted to store stuff in another mechanism, like, well, why not an Excel document? Why not a CSV? Why not a database somewhere that I could hit? And the best I can tell is just they kind of encourage markup.

And really, I think they wanted to make the acronym. So, like, this is just a way that you can store your static content with your checked in code. And it's convenient. Static content. convenient static content so in real life example in real life if we were to back up here if you had a if you if you were going to do something as wacky as try and create this jam stack for your 10 000 product thing you'd probably generate that markup from your database and then run the build tool right yeah that's kind of sounds kind of weak though man like i i like what joe said when he's like they only did this to like finish out the jam acronym.

Cause it really feels weak. You would never hard code 10,000 products into a file for that thing to happen. If you're going to do it, you Jen that thing. And then, and then you, then you use the build tool to create your static files, right? Yeah. Cause it doesn't make sense otherwise.

Well, I don't know though. It does specifically say though, going back to your point where you're talking about the best practices no databases to clone no complex installs so i guess then you wouldn't be able to just do your npm install yeah i don't know yeah and this is like one of those examples it's like yeah the, the best practice is you've got to kind of weigh which is worse, like a quick one-step checkout build and everything is with that build or managing 10,000 projects in a JSON file. What's the greater evil there? Right. Well, I mean, at that point, too, it sounds like you're... Okay, I really like our Amazon e-commerce example here. If we were to recreate Amazon here in 2019, instead of doing File, New, and Visual Studio, we do a Jamstack app.

So it sounds like at that point, if you were to try to shove all of the products that Amazon has into some kind of file, or let's be honest, at that scale, you're talking about some kind of file, or let's be honest, at that scale, you're talking about some kind of file system, then you're just recreating databases. Like, what's the point? Well, no, back to what he said. You wouldn't do that.

No, but back to what he said. The point is now, you don't worry about scale because it's just hosted files everywhere. No, no, no, but we're talking about the markup, though. Oh, the markup. The markup wouldn't be as... So that's what I'm saying. You wouldn't... At that point, you would have gotten to ludicrous

level of just trying to like recreate a database so what would be the point in having those products in this templated markup it it doesn't seem like it would make sense yeah i don't know unless maybe it's a prescribed way of yeah just a recommended kind of best practices like but yeah absolutely if you've got an extreme use case like an amazon or thousands of products then i think that the m doesn't hold water but i still think the jam stack is a good option for you but maybe not those products right or not not doing it the prescribed way maybe just the jet yeah the jet just the jet jaw yeah J. Just the J. Ja. Ja. Okay, so it's the Sweden take. Swedish take.

Yeah, and I do think some technologies and stuff like Docker has made things a lot easier. So it used to be back in the day like, okay, I'm going to make a ColdFusion website. You guys are coming on board, working on the team. Here's the download for ColdFusion. You're going to need SQL Server 2018, whatever.

And here's the NIST script that you can run to get your own database. But here's a shared database in case you're working with somebody in QBA. And there's all those little asterisks and questions and little things that you need to kind of tell someone when they're coming on board compared to a perfect kind of textbook jam stacker website

where you basically just clone it and build. And hey, here's one. This might bring back some memories, guys. Like, oh yeah, and here's the payment gateway processor that you need to install, but be sure to install the dev tool version, not the production version. Otherwise, you might actually be charging someone.

Never happened. Yeah. Not twice. Not twice. Not twice. All right. Yeah. So I mentioned what about CMSs?

You know, we mentioned with WordPress like one nice thing is that we can go download those themes and we've got consistent tools and plugins that are nice. There's also

just that kind of our ability as people to kind of log in. So if if I'm a developer writing Markdown or editing YAML files isn't a big deal, right?

And running Gatsby Build isn't a big deal. But if you're someone in like marketing or something like that, I don't relish the thought of teaching someone in marketing how to use Git and how to edit Markdown files and how to preview the changes before they push it live.

Type in VI space. Yeah. And then they'll never be able to exit. Exactly. How do I get out of this? Oh, we're not going to be here all day. Yeah. So I think that's kind of like the most – like the biggest kind of reason you wouldn't want to use Jamstack side or something is

if you've got people outside of your kind of developer application that need to do stuff, then I think that Jamstack is currently not a good idea for that. Yeah, I mean, you can do stuff actually, headless CMSs are becoming more and more a thing where you kind of like edit your content offline

or in some other service, and you've got your application which kind of pulls from an API, which is totally separate from that. And then it's going to gen those files for you, I guess. Yeah, depending on the CMS. I guess it depends though because I'm thinking of it like, well, at what point

in terms of scale? If your use case has gotten to the scale to where you have employees who like your marketing guy, I think was the example you gave, that needed to access that, then at that point, maybe let's revisit this templated markup conversation. Maybe at that point, you're not using that. So you would have some other system where users can access a database to do those kind of things.

And then your Jamstack build process queries that database to get the content that it needs. Well, that's what we talked about earlier. That's what you probably do in a realistic term. But if you're following the Jam prescribed method, that's not what it is. You're going to have a file with that markup in it. But yeah, a real-world scenario, if you were doing a real-life CMS that people needed access to, you'd probably do something like that. Yeah, because the deal there is like in a non-Jamstack scenario, if I'm building a small CMS website to be used by marketing, then I'm going to build a small Ruby application or Flask application or Django,

and it's going to be one website. If I'm going the Jamstack route, now I'm building two applications. I've got my Jamstack website, and I've got to build the backend too, and it's going to be separate. Right. So I think that would not be a great choice for Jamstack. And that was kind of the prime thing that I came back to is the reason why I wouldn't do a Jamstack site for something. Yeah, at this point i think i've

gotten to where i think static first and if there's a compelling reason for me to not make a static website or a static focus website then you know fine i can do that but we still said though that you could have components of this page that are still dynamic yeah that's where i'm still struggling with like where do you draw that line yeah i don't know like well i think my whole argument with the jam stack is like maybe the line is closer to static than we thought five years ago that's the real lesson of jam stack is like maybe things can be more static than they used to be i think for anything that doesn't require permissions based type things that might be true or authentication based type things, because that's where it starts to fall apart. My mind is,

you know, like even an e-commerce thing like that still bothers me. Like, okay, so you want to order this page or order the product off this page? Well, the next page you go to is going to be asking for billing information. I don't want to type that stuff in every time if I'm a customer of the site. You know what I mean? I've been to the site before. I don't want to fill in my billing information again. It's the reason why I buy everything from Amazon.

I just click buy. Send it to me. I don't want to have to go through this whole thing of fill this out. All right, send it up to an API. All right, now take me to this other page. So I don't know. It feels to me as if the content can be static. Codingblocks.net, perfect example. Most of the content is static. Something like that could exist, right? An ordering site

or something where you interact with a bunch of things doesn't seem like it makes sense. And I may be completely wrong, but that's where my head is. I mean, we talked about making a static version of Coding Box a while back. And at the time, part of the reason that we opted not to was the search. That's the only reason. Yeah, that was the thing that was like, well, we could create a flattener that we could go and walk the site as is, but how do you deal with the search? I think what we came up with is you'd have to know the URL, and then that would always have to go back to your server, and it would search your database and then serve that stuff up, but everything else would be served statically, right? Which it's not Jamstack because the whole,

the end result is similar to Jamstack, right? Which is static files being served. But the whole point of the Jamstack is approaching this from the, Hey, think about your APIs being completely separate from your development process or your front end, right? That's, I think in the,

in what jam stack is trying to achieve is saying, Hey, how can you build these things completely separate to where you never have any kind of back and forth with the server? Like you don't know about the server back in, right? I think it's fair to say that the static site would still be jammy jam stacky.

And there's just the search feature wouldn't be a third-party api and if the search feature goes down so what the site still works no but it would be jamstacky because the only thing you truly have there is nothing i mean so jamstack is javascript apis and markup right you literally have none of that you're not going to be writing your content pages for job for coding blocks in, in JavaScript. We're not doing that. Like we're not going to react our app or anything. Uh, the APIs it's tightly bound to the backend, right? Like when you go to a WordPress site, it's actually calling the PHP to generate the content that goes back down and the markup, you know, again, the whole reason you use WordPress is you save the content, it goes into a database and that stuff gets gen.

So I think the output similar to what you get in a jam stack app, which is static files, which I think, uh, heck, I think Carl and those guys actually from MS dev show, they do something. It might even be Gatsby, right? I don't, I don't remember exactly what it is. Um, but you can take a WordPress site and have it generate the static files. The output similar to the jam stack thing, but it's not jam stack because you're taking, you're taking something that's truly just a website and flattening it. I think jam stacks, the approach, right? It's not the output. It's the approach right it's not the output it's the approach unless i'm i think it would still count as kind of like using a static site generator tool like there's headless cms uh headless wordpress where you can kind of generate your static files and

then it would uh use the api for whatever like you know or search or. Well, we'll check it out. When is your site not built with the jam stack? So with the jam stack means that methodology and it says a site built with a server side CMS, like WordPress, Drupal, Joomla, Squarespace. So, so yeah, they're basically calling it out. Yeah. But I think if you used WordPress and like the output, the files that you put up all lived on CDN and raw HTML, I think you could make the argument that it's jam-stacky.

I don't think so. I don't think so. Because you're not doing the NPM. You're flattening it, but you're not doing the NPM install kind of process. You don't have everything in the templated markup. And you're not writing your UI files with React react or view or vanilla js or anything it's you're really doing nothing except saying hey take what wordpress has and spit it out into some static files right like you didn't do any of the development stuff which i think is what jamstack

is right it's developer focused ui split from the other stuff, unless I'm completely wrong. Well, not to mention like, yeah, I mean, cause there's a total difference here between a flattened site. If everything that I'm understanding, there's a total, there's a complete difference from a flattened site, which is what you're describing with you were going to go and flatten a WordPress versus what I'm, I'm understanding Jamstack to be where you could still have elements of the page that are dynamic based on some API call. Yeah. Yeah.

We use discuss to fetch the comments, for example. Right. So you wouldn't have that in a, you wouldn't have that in a flattened site, but in a Jamstack world, you would. Right? And the Disqus one might not be the best example. I kind

of like that example of the inventory count on Amazon, only because that's staying within, that's your API. Right. Whereas the Disqus example is someone else's API. That goes back to your OAuth kind of scenario, right? Yeah. I still think if your OAuth kind of scenario, right? Yeah. I still think

if your output of your build process, whatever it is, is a bunch of JavaScript, HTML, static files, and you've got maybe a couple APIs that go back and fetch whatever you need, and it's still hosted on a CDN, I wouldn't argue it's jam-stacky.

You should let us know in the comments. I think they're going gonna argue with us yeah yeah i mean if i'm under if from what i'm gathering from you about jam stack is that it wouldn't classify and part of the reason why it wouldn't classify as jam stack is that there's a different mindset about thinking about a Jamstack application that is more than just saying, Hey, I'm going to use my old tools of like, you know, some kind of database with some kind of server side stuff. And then I'm going to write up or write or use a flattener that'll go and walk my site and, you know, save out the, uh,

the generate, you know, whatever HTML was generated at runtime. Right. If, if I'm understanding correctly. Yeah. I mean,

I think that would be a pretty jammy, pretty jammy output. Uh, yeah. We'll agree to disagree. All right. So you're the one supposed to be telling me about this thing. Okay.

This episode is sponsored by Clubhouse. Clubhouse is the first project management platform for software development that brings everyone together so that teams can focus on what matters, creating products their customers love. While designed to be developer first, the UI is simple and intuitive enough for all teams to enjoy using. And just like Outlaw said, the favorite part for me is that it's been designed for developer first. So it's got cool things like Git tips that are built in to the UI because it's really focused for us, although it's intuitive enough, like you said, just for anybody else to use, but developers first. Yep. And you can log in and immediately see your work queue, your active tasks, upcoming due dates, your activity feeds. You can go to story views. There's all kinds of different ways to be able to look at your particular work queues.

It's easy for people on any team to focus in on their work on a specific task or project while also being able to zoom out to see how that work contributes to the bigger picture using the fast interface. And with a simple API and robust set of integrations, remember developer first, Clubhouse also seamlessly integrates with the tools you already use every day like Slack and GitHub, for example, getting out of your way so you can focus on delivering quality software on time. Yep. And you can sign up for a free two months of Clubhouse by visiting clubhouse.io slash coding blocks. Again, visit clubhouse.io slash coding blocks to get your two free months and see why companies like elastic full story and launch darkly light clubhouse. All right. So it's that time of the show where we always ask if you haven't and, and you like us or, you know, whatever, please do go leave us a review. We've got it. We've made it pretty easy to go to www.ctingblocks.net slash review. And again, it truly does make our

day. We appreciate it. And we love seeing what you guys have to say and anything, any suggestions or anything you like about the show, throw it in there and we pay attention to them all. So, I mean, we've, we've molded the show over time. We're almost a hundred episodes, so we definitely read the reviews and, and we greatly appreciate them. So thank you. And I've said it before, I'll say it again. If you haven't already, share us with a friend. We would appreciate that as well, too.

Yeah. All right. Well, it's time for my favorite portion of the show. Survey says. All right. So, uh, a few episodes back during at episode 96, we asked,

how do you plan to spend your holiday, your time off this holiday season? So now that everybody's back from the holidays, let's see how they lived up to their expectations. So the plan was your choices were spending time with the family because the holidays are all about the memories or I'm not avoiding the family. I'm building my next great project or escaping the family and the keyboard or lastly what time off all right so you know what i'm not going to go with captain carmudgeon first so so we'll hit

because i want an optimistic start to this one so we'll go with alan all right so i'm going to give you my optimism i'm hoping people said spending time with the family because holidays are all about the memories. Now I'm going to go with 39%. Okay. Now it would have been hilarious if I said Joe first, right? Should have done that. I know what he's going to say here. Yeah.

I mean, I think that everyone everyone's gonna say the family thing but you know wait hold on it's anonymous so i'm gonna say escaping the family and the keyboard okay what percentage uh 34 percent four 34 so alan is spending time with the family because it's all about the memories with 30%. 39%. Oh, 39%. I'm sorry. And Joe is escaping the family and the keyboard with 34%.

Do I have this right? Yes. Yep. All right. Well, by Price is Right rules or our mixture of Family Feud, Price is Right rules, whatever it is. All right. Well, by Price is Right rules, or our mixture of Family Feud, Price is Right rules, whatever it is, Alan wins. Sweet. It was even higher. That's awesome.

Yeah. What did it ring in at? About 52%. Nice. Nice. Wow. Yeah. Curmudgeon over there.

No dedication. I was actually kind of surprised about that one. I assumed that people were going to say they were going to be spending more time with the code. So I expected it to be more like building my next great project kind of thing. I thought that was going to be the winner, but it wasn't. What was the second highest? What time off? Yeah. Really?

Surprisingly. At what? It was like 27%. Okay 27 okay so yeah we're over 60 yeah we're close to 70 on those first two i like it i guess i was the only person hold up with smash bros no you do that with the family man you do that you beat up the other people in the family with Smash Bros. My family's not that cool. But that would require multiple switches, too. It would. So there's that. We're developers.

We can afford those extravagances from time to time. Oh. Well, okay. I guess maybe I was mistaken. All right. Well, then, today's survey will be, what do you think of Jamstack? Your choices are, it's like the future, yo. Or, eh, I'll let this front-end fad pass and maybe grab onto the next one. Or lastly, you can pry the back end from my cold dead hands.

Yeah, I know where I'm going. Yeah, it'd be interesting to see. All right. All right. So we've already hit a lot of the points that I've kind of gotten notes for here, so we'll kind of move quickly

through those parts. And then I've got some interesting questions I think at the end that I hope you will also think is interesting. So what is Notch Amstack when your view is not fully client side, meaning it's got a tightly coupled backend? By the way, that debunks

the WordPress thing. Well, well no because it's not tightly coupled if it's totally separated dude that's it's generated to not tightly coupled wordpress is not jammy well the third bullet point here that i actually typed up was uh things like wordpress are not jammy yeah it even says so on their front page. Just saying. Building views at runtime, things like ASP, Razor, Ruby Node, stuff like that.

Definitely not jam-stacky because it's just totally coupled to this middle tier. I don't know what hosting costs are nowadays. I think Linode, I've got a Ruby app posted for like five bucks a month. So I think you can get stuff pretty cheap. I don't know what hosting costs are like nowadays. I think Linode, I've got a Ruby app hosted for like $5 a month, so I think you can get stuff pretty cheap. I don't know about Windows hosting, but.NET Core fixes that,

but you're still looking at some sort of cost there, even for the most basic of apps. And if your app actually does well, then crash-a-roni. I am curious, though. You said Netlify was free for CDN-hosted files. Yep. That doesn't make any sense. Because even Cloudflare used to pay for, right?

Cloudflare has a free tier. They did have a free tier. That's right. That's right. I do love Netlify. I actually would totally use their upgraded services. I would pay for it off. You give me, I don't know how much it is,

but say $6 a month and you add off to my site and i don't have to worry about kind of the tokens or the passwords or any of that stuff and you just give me a token that i can use to uniquely identify like that sounds like a great deal to me yeah that's awesome i'm looking up to see like how cloudflare even makes their money because i remember it used to be like if you wanted ssl that was something but i think they might have added that now. Yeah. And they also, at one point, you'd have enterprise type stuff too where it would also try and make sure that malware and stuff didn't make its way into it. So I know they had those offerings. Okay. I see.

Okay. So for Cloudflare, it's like if you have a personal website or a blog or whatever, then I guess honor system here, it's free. Right. But if it's a professional website or blog or portfolio or a small e-commerce site, like that's where the costs start coming in. So I guess it's like, I guess technically like a coding box wouldn't count as a personal website.

So we wouldn't be on the free tier. Right. Oh, by the way, we totally missed this in the news. You guys saw that GitHub now has unlimited private repos? Yeah. Yep. Yeah, man. Crazy talk.

Anyways, all right. So back to our regularly scheduled program. All right. And so why would you consider something like Jamstack, even though it's kind of weird? You can't beat the web performance. So if you want to get out to a billion users, this is a great strategy for doing that.

And especially if you're doing a side project or something, then there's a good chance that you don't necessarily need a backend if you're doing some sort of thing. Like I did a color website a couple of years ago, ASP.net, I paid 20 bucks a month for years and the whole thing could have been done totally client side. But tell me this.

So we say that you can't beat the performance via static files and CDN for jam stack. But I want to go back to what outlaw said with the two extremes, because I feel like you almost could, because if you have a spa and it's one page, right, you have an index dot HTML, and then there's some JavaScript that comes down.

That's going to be cached by the browser and the CDNs. Like that's a one-time hit. Whereas with the static files, as you bounce from page to page, you're getting multiple hits. Now, granted, they might be cache hits in the browser, but if they're new pages. Well, not for the markup. The JavaScript might be a cache hit, and the CSS might be a cache hit.

The HTML could be, too. If it's a static file, it can cache that in your browser. Well, you're not going to have the same page over and over. Even the name of it would be different. Right. If you went to the homepage and then went to another page and went back to the homepage. Yeah, if you go back to the same page. Yeah. Okay. Fair enough. But that's what I'm saying. If you're in a spa, you take that hit the one time that you download it and then the rest of it's golden, right? Now you're going to take the hit on any kind of client side rendering on processing. So I just wanted to point out here being devil's advocate.

Okay. I think, I think I can, I'm going to try to answer this and Joe can slap me around and tell me where I'm wrong. I think you're going to get two, two areas of performance here though, is that one, these static files are going to be much smaller in size than what a downloading and a whole spa would be. Maybe. So there's that. And then you don't have that same processing on the client side.

So the memory footprint of the application in the client itself, I imagine, would be nil or next to it because it's just a DOM. I completely agree with that. Your memory footprint will likely be much smaller and your CPU utilization will probably be... So responsiveness of the client is amazing. But it's not necessarily faster. Just saying. Well, so what we're saying is like Jamstack

may not necessarily be faster than SPA. But what I'm saying is static hosting is going to beat just about anything except for like local file access right so whether it's spars or or jam stack either way like this this is the just about the best hosting that you can get maybe the best hosting uh yeah and uh for me as a developer there's sites like netlify out there and in cloudflare that i can run and do my start projects for free and that's actually a really big deal, I think, because over the years, I've created tons of websites and I've taken them all down eventually because over time, you just kind of have these sites that build up and build up and build up and you just get tired of paying for them.

But now we're living in a world where suddenly 2018 or realistically 2016 and on, you could put out your projects for free And all you're doing is just keeping those domain names up, which we accidentally do all the time. So tell me this though, when you say that you get scaling for free, do you actually get that for free with Netlify? Like they're not edge hosting that stuff all around, are they? Yeah. Really? So you get it in regions around the world?

Yeah. For free? For free. You just. I know. Like, how am I supposed to start a company if, like, there's all these companies doing amazing things for free? Oh, man, my battery on my mouse died. And I also feel like, you know, come on, Netlify.

So if people see your service and they realize that you're doing all this stuff for free and it's amazingly usable, like, how are they going to pay 99 cents for my fart app or whatever it is and they're like well shoot netlify is free how dare you charge 99 cents for anything yeah that's that's crazy um yeah all right anyways so that's uh i'm color me impressed yeah so it's perfect for side projects uh it's a really good developer experience the tools have gotten really good and it's not necessarily the best developer experience. Something like WordPress or depending on the type of application you're doing, it can be better. But I will argue that tools like, there's a bunch of them. I got a list here coming up of static site generators that are actually pretty nice to use and don't necessarily require a huge learning curve for a programmer.

Loose coupling is nice. So you've got a totally separated, you know, Bob, Uncle Bob would be pretty happy, I would think, with Jamstacky type things because it's a separate thing and it's got an API that it can talk to as long as you've got a nice API layer in JavaScript. Hey, I wanted to add on something here

just to like to Alan's question a minute ago. On the site here, I was looking at the pricing, and the headline of it is, Deploy your site to a global infrastructure in seconds. And they say a simple Git push will publish it to their global content delivery network spanning seven cloud providers. Yeah, I'm actually reading more information about it. Not because I didn't believe you, Joe, but because it was so shocking that it hurt my head. They call it an application delivery network. So not a CDN and ADN. So the multi cloud thing that he just said, they they offer full on atomic deploys. So if you have 1000 files that need to be deployed, it'll actually do it after they're all done as opposed to,

you know, slowly leaking them out. Um, yeah, it's crazy. And it's amazing. And it's even way better. You might think like,

uh, so QIT is using Netlify and I've got, uh, different branches hooked up so I can like the master goes out to QIT. Cloud, but I can also make branch deploy. So you can go to like backend or alpha. Uh, uh out to QIT.cloud, but I can also make branch deploys. So you can go to backend or alpha.qit.cloud and I can hook up subdomains.

But also it does previews on every build. So whenever someone does a pull request to QIT, it actually does a deployment preview and will tell you if the build passes or fails in Netlify for free every pull request. That's crazy. Another thing that's on here that's pretty nifty, and we're talking about Netlify.

I don't know about any other of these ADN type things, but cache invalidation. Like we've worked in CDNs before, and cache invalidation can be a bit of a pain, right? Like you got to check and see if the hash is the same and various different things. The cache invalidation on the ADN is instant. No risk of stale content. of pain, right? You've got to check and see if the hash is the same and various different things. The cache and validation on the ADN is instant. No risk

of stale content. I don't know what they're doing there, but that's really cool. Do you know what else I do with Netlify that's ridiculous? I have custom environment variables set up for my build. So if things like if I had a database or if I have a search key or whatever, I could pop that stuff

in there rather than checking that in. So I can keep my keys in one place, and that stuff will be used during the build and not deployed. That's pretty nifty, man. Yeah, it's crazy. And it's all free. Yeah. There's something else I really like, too, that I forgot. Oh, it's got snippets.

So if you want to do Google Analytics and you don't want to check that into your public code, you can do the snippets right there. And it'll just depend on the end of every file. file man they're not even sponsors of the show we need to reach out to them you're like look dude we just gave you like 30 minutes of love 30 minutes it's like the whole episode like they are kind of they're the company behind jam stack like they're they're pushing this it's pretty cool all right absolutely mentioned a couple examples there i like that a simpler um less stuff to learn to maintain. So, you know, if you talk about like doing a Django site or something, then you're just kind of bringing on like a whole big framework that's got its own quirks and stuff that you've got to learn to work around. And so it's kind of refreshing to just be able to focus on front end technologies and whatever build tool you're using so that, you know, there's no getting around that unless you're just you know yeah tough and doing this all in pearl or something and uh security so uh i wanted to touch on security

because if you think about like how you know a lot of websites are built including wordpress lamp is a really popular option what does your security footprint look like for your LAMP, which stands for Linux Apache MySQL MySQL and PHP. There you go. That's big. That's huge. There's all sorts of vulnerabilities built in there. I can't believe I forgot that.

App to get this upgrade. You're done. You don't need to worry about it. Oh, man. Yeah. You think about the things you have to worry about there oh man yeah but it's just you think about like you know the things you have to worry about there is compared to you know this static which you can't even access the directory directly and on lvi so it's just off in the cloud somewhere yeah and you got no sql injection because it doesn't exist unless the api but that's not your problem right that's some third party agnostic api that you don't care about. Yep.

So, yeah, I think those are pretty good reasons for using Jamstacks for certain things. Best practices, we mentioned things should be hosted on a CDN. The more edges, the better. Using modern build tools. So they recommend actually using things like Gatsby you know, Gatsby or hex or whatever. Um, just, you know, why not?

Uh, I thought it was kind of even a weird thing to mention. It's like, you should use modern tools. Like, you know, God tell me twice. Uh,

in fairness, there are an ungodly amount of tools for JavaScript. It is, it's a little overwhelming and very frustrating. Yeah, for sure. Uh, one mentioned to,

they recommend having everything in a single get repository. And that's kind of like we talked about having those markup files in there too. It's pretty nice. And, uh, remember FTP, that's a kind of a thing in past.

Like we've got web hooks, which are even like kind of not that popular. I think a lot of things will just log in with your GitHub credentials or you do the OAuth thing and it'll just kind of watch your repositories. I don't know if there's some sort of watcher API or if there's dynamically webhooks going on,

but it's kind of nice to not have to log into my repo and paste a URL there for it to update. It just kind of takes care of it with the click of a button. Just watchers are really common, so I just. It just kind of takes care of it with the click of a button. So just watches are really common, so I just thought that was kind of a cool side note. Focus on automated builds. I think that's kind of a given using the tools.

They recommend doing atomic deploys, which is interesting and kind of, we talked about the Amazon example. That's an example of something where if you were doing that in Jamstack app, which is controversial at best, then that is probably a case where you might want to consider doing file-by-file replacements. But for the most part, most smaller sites, Atomic Deploy just kind of makes sense. Like why not deploy to another directory and swap rather than kind of having this period of downtime?

Why have any downtime at all, right? Yeah, and it also keeps your site in a consistent state, right? Like you don't want to be hitting new stuff, mixing with your old stuff. They may not jive well. Yeah, and it's kind of file by file too. So like, you know, I might click on the homepage and get the old version, and I click the next page, I'll get a new version. But assuming I haven't broken links or something, so what?

No, that's kind of nice. You don't have to worry about like, yeah, I guess you always worry about versioning APIs and stuff. You don't have to worry about your HTML and stuff like that. So that's nice. Yeah, I just want to mention too that stack sites don't mean you don't have any sort of tests. Like Gatsby has a big focus on testing. A lot of these tools have a really big focus on kind of UI testing. And so that's not something that you're giving up.

So I just wanted to mention that. A couple of downsides. We mentioned it being great for users and scaling really well to consumers of your website. But large sites, you know, we talked about the Amazons, or if you've got 100 developers working on a static site, you know, probably not going to work out too well. I'm curious. Did you play around with some of the examples that they have on the,

uh, notify site? Nope. Like one of them that they had on here was the Marvel search. And I'm trying to figure out like, okay, what makes this thing Jamstack? Because like,

if you, if you open up the dev tools, Chrome dev tools, Chrome dev tools, and you watch, you know, your queries be happy, you're like, okay, well, I see my traditional kind of queries, right? Like page loads up, bunch of images populate, you know, some content loads up.

And then if you start typing in a letter, you know, letters, it's doing like a type of head search kind of thing. So you're seeing like multiple API calls getting, you know, sent along API calls getting, uh, you know, sent along the way, you know,

depending on how fast you type and, you know, images that are coming back to match some of those responses. But I'm like, yeah. So like your point there, I think is that they're not necessarily generating all these thousands of pages for every comic or whatever.

They're still making a big use of API. So it seems like they're not really getting a whole lot of bang out of that CDN, right? If there's just kind of a traditional spa, what's the difference? Yeah. I mean like,

yeah, that's where I'm like, I'm, I'm lost again because it's like, okay, yeah, you made the front, the front page could definitely be static.

What was, where did you find that? Uh, if you go back to jam stackack.org and click on examples right there's a there's a whole bunch of different things in there and one of them if you scroll down it's called marvel search and i mean it's it's a nice looking little site here. But then open up Chrome DevTools and watch the network tab as you do things, right? Because what I was expecting, based off of what I was understanding how this thing would work so far, right, is I was really expecting not to see a lot of network traffic.

Or maybe I'm thinking of that wrong. As I went from page to page, right? Because I was thinking like, okay, you've already preloaded this, but I guess now that I say that out loud, I'm thinking no, that would be more spa-like, right? Yeah, I don't think that you have to, I don't think that Jamstack is at odds with spa. It's just

kind of encouraging you to generate the things that make sense and do that stuff up front. It's kind of like a dial from like Django to Jammy it sounds like this this particular API is more you know it's kind of more in the middle or maybe closer to Django even so an interesting thing here is though they have a single page the Marvel search page but every time you click like to go to a next page it's reloading the page. There's no hash up there in the URL.

It's actually going to another page. And I'm assuming there's some JavaScript on the page that, that parses the URL stuff and then sends off the API calls to load this stuff. So it's, it's a templated page is really all it is with a bunch of toggles. Now that makes me wonder though, like the stuff on the left where it

says x-men avengers all that that was probably pre-genned is my guess that'd be my guess i don't know for sure all the toggles yeah yeah so i don't know well kind of like i do with um the podcast app which is another app that's like heavily built on like a search api i do a lot of pre-genning of things like categories and technologies and stuff and so I do a lot of pre-genning of things like categories and technologies and stuff so that I can pre-generate navigation. Those are actually facets. If you click on Teams and you're like,

okay, show me X-Men, all the powers change. This is, I don't know if it's handlebars. It sounds like just a traditional spa, right? It's like a single-page application that kind of fetches all its data via API. Well, clearly it's not a SPA if it's listed as an example on the Jamstack.org page. But why can't a SPA be Jamstack?

It could be. It totally could be. And that's... Just a matter of... Like in this case, they said, you know what? We don't need to do a lot of generation. But maybe they're doing... I don't know why they chose to use this as an example. It

seems like an odd example to me, but maybe they do a lot of their static content and markup files or whatever. Maybe there's, you know, there's a big focus on API. Clearly there's a big focus on front end JavaScript. So the really just all we're saying that the thing that is not so jammy about this is that it's not making a big use of like static files and CDN generation. But I think it still hits the first two letters pretty strongly. Yeah. I mean, it's the UI, the UI is there, but here's the thing. And this is what I'm not exactly, it looks like they're using the handlebars. So basically just whatever comes back from the API call gets filled into the handlebars template.

I mean, that's, again, like that's where I think that you can't draw too many lines. Basically, you can have a templated page that you can fill data in. And in theory, that's the same thing, right? Like you're not generating things server side. You're just plugging in things from an API call into the template. Yeah, I just got a pitch too. CodingBlocks has a couple videos where me and Zach Ratty went and we took this Marvel search

API and we built a little React app. It was all in React. There was no middle tier there. Anyways, where were you on this? The downsides. The steep learning curves. Yeah, so if you're talking about having your stuff in some sort of market files

or checked into Git and that's not something you want to turn over to marketing department. Also heavily dynamic pages if you've got a lot of stuff like adminning and then not so great. But it sounds like there's a steep learning curve for devs. It's been a while getting it yet. Well, I mean, you get it. It just a matter of like where's the distinction we're trying to kind of like clearly define something that's a little bit nebulous right i agree yeah so it's just a philosophy but yeah i think you could argue that the marvel ed by is not a very good jammy example because it doesn't make use of the static generation. I don't know.

I mean, it's statically generated that one file and then the rest of it is a single page that the template just fills in depending on the toggles you do. Like the page isn't changing. The structure of the page is exactly the same and it's just filling those in. So I get it. I mean, it's a very limited jam stack app, but it's. I don't know man i my understanding from before though was like spas were not jams were not jam stack apps or pages right i thought that you were like pre-genning things so that you could push it out to a cdn now we're talking about just pushing out your javascript application to a cdn for your spa that doesn't sound but every click reloaded the page every click loaded the page again

not yeah not in my case look up the url there's no hash up there it's actually it was adding query string parameters i don't think it's illegal but the page wasn't reloading you'll see the flash on the images it It's apps. No, no, no. If you clear your network tab and watch what new network history comes in, all I ever see is a new image

get populated in. But the page itself is not reloading. It's not reloading that page? No. Yeah, but why does that matter? They never really said that a Jamstack app can't be a single page. Right. It's kind of going against one of the best practices and philosophies of statically generating sites. There's no hard and fast rule that says you're not allowed to have a spa.

If anything, it makes me feel better about the JAMstack thing because it doesn't make sense to generate a page for every combination of those toggles on the page right it makes more sense for that to be api driven and just fill in a template and that's what they're doing i mean like i said it's very simplistic but that makes more sense to me well maybe where i got confused is i thought that that's where like the market the templated markup came in right like i thought that's part of where that conversation came in is you were going to flatten all your content out, I thought. Yeah, but this is a case where the API, there's so much data there and so many different combinations that we wouldn't want to generate all those permutations. So that's a case where we're saying, we're not going to pre-generate this because it's too crazy to do that for every search. So we're going to use an API for that.

I was just emphasizing different parts of that jam. So it's, it's heavy on the J it's heavy on the a, not so much the M. Right. Yeah. I mean, cause this specific example looks to be powered by a search engine. Yeah.

Specifically. Yeah. So this looks like every other spa. Well, not every other other spa because think about how many spas like if you're like working in a company you say okay we're going to create a new app it's going to be spa first thing you do is go into file individual students say file new project asp.net or you know web api or whatever where you kind of start from that angle. And in this case, we're saying the application here may only be a single file, but it's going to be up there on CDN.

It's going to be client JS focused. It's going to focus on using APIs for doing whatever it needs to do that can't be genned. You've totally lost me. Now we're back to square zero because now what's the difference between this and amazon.com? Amazon.com is definitely, I guarantee you, absolutely hosted across multiple CDNs, right? And we agreed that they probably don't flatten every product page

out there. So they're making API calls. So you go to amazon.com, you're probably getting like some kind of a template of like what the homepage should look like with the rest of the app. And then everything else is making API calls. No, but the difference is different. So the difference is the amazon.com has URL rewrites, right?

Like I guarantee you, if you go to amazon.com slash and then whatever the bin number is for the item and then, you know, whatever comes after it, that is an Nginx or a Java lookup that's basically saying, all right, now go get the content for this. With the jam thing, there is none of that. You're going straight to a static file, which is why you're describing using a canonical though. That's not necessarily a rewrite. No, no, there is no server though.

There's a big difference. There's no server here at all. This is serving up that static file. So that page, I forget what it was, um, which, uh,

it's Marvel dash search. That's an HTML static file that's being served up. Everything else is being pulled from the API, but this page that loaded came from a static file, right? That's not going to happen. There's no server. Literally you made a request to community.algolia.com slash Marvel dash search. It went resolve that host then said, okay, go to this page. And then it went and pulled up the static file for Marvel dash search. There's no, there's no lookup for that information

it's going to that file so i think that's the big difference is yeah amazon.com is going to have cdn type stuff but if you go to any amazon url i guarantee you it's going through either engine x or some other thing that's doing a url rewrite and saying go load this data. I'd lay money on it. They're not, they're definitely not got static files. There's no way. I guarantee you there's no way they have rewrite rules for every one of those. We're getting way in the weeds. I don't think

it really matters if Amazon has redirect rules or not. I think we can comfortably say, though, if you're developing a Ruby on Rails app that you didn't deploy onto Heroku, that it's not Jamstack. I don't know about Amazon, but we're saying that there's this kind of

there's a set of tools that we're kind of leaving out. So if you're Lampstack, if you're Mean, if you're ASP, Ruby on Rails, Django, you're not Jamstack. So it's not so much about whether it's a spa or not. It's about what are we not doing?

What tools are we kind of leaving out of the equation? If you're starting from a single file or your markup files and you're using just JavaScript, whether or not you're calling APIs or not, it sounds like you're a Jam application, right? Like in a nutshell, that's kind of what it boils down to. Yeah, you're pretty jam application, right? Like in a nutshell, that's kind of what it boils down to. Yeah, you're pretty jammy. You're ignoring any kind of server side stuff at all.

You just assume the API is something you can call and you get stuff back from it. You're not writing any middle tier code that exists with your application. I think that's how it's boiling down in my brain right now. Yeah, if you think about like back in the day, I would start an ASP website. And then when I would go to deploy it, I would RDP into a Windows box. I would set up IAS. I would deploy my web application with like WebDeploy. I would go in and I would set up my bindings and all that stuff.

And if there's a certificate, there's this whole kind of class of stuff. And if there's a certificate, there's this whole kind of class of stuff. And then, you know, ultimately whether, you know, the HTML files live on a kind of a CDN or however that, that ends up being, I still have this kind of coupled application where I've got a backend server that's strictly bound to the front end and the front end is strictly bound to the backend. You can't separate those. Now we're saying like, why do we need to do that? Can't we just do a bunch of the work up front, toss out that middle tier, and focus on the client experience, and then whatever middle tier parts that we need, why not have those as third-party microservices? You're saying they have to be third-party, though?

No, they don't have to be third-party, but you want to treat them kind of like third-parties. You want to treat them as URLs and not be totally bound to the experience so that if certain features are down, if certain services are down, the main user experiences or other experiences that aren't bound to that don't need to be. It's basically a separate project, right? It's not going to be included in your jam a separate project, right? Like it's not going to be included in your jam application basically. Right. Right. So if the shopping cart's down, I could still browse the site or, you know, whatever. It just kind of, it ties in nicely with that, uh, the, like the microservices kind of philosophy of like not everything having to be up all the time and things kind of working progressively. So this is a nice philosophy that works well with that because it's focused on that

JavaScript and APIs and things being client-side and hosted on CDN. And we're kind of cutting out that traditional middle layer that we used to take for granted for so many years that would just be there. That make sense? I think I'm getting it. I mean, I thought I was, but it's great at the Marvel app. Yeah. I wish I'd never seen that Marvel app. Then I was like, I don't, I don't get it.

I don't get how this is a thing. Yeah. So the static generation is a best practice. I mean, it seems like... Not baked in. There's no S in jam. Wait, say that again? Wait. There's no S in jam.

No, but hold on. No, no, no. Before that, what did you say? Static generation is a best practice that ties in nicely with the CDN hosting. Well, I mean, according to one article I found, it's basically like an evolution. So backing up, we had the LAMP stack, then the MEAN stack, and now there's JAM stack.

Yeah, and remember how I kind of mentioned the reasons that I used to use ColdFusion for building websites is because I had those server-side includes and database access. Now, the database access, that's still kind of a problem. But what we're seeing is things that I used to use that middle tier for, like layouts and footers and headers, I can do that now easily with front-end tools like React or Vue. So I'm cutting out the need for a lot of the backend servers for applications

that we used to take for granted because we wanted stuff like that. And we didn't really have good tools for doing stuff like that. Now we're saying we can get around it through static generation or in some cases, spas. Maybe. Yeah. Hmm. All right. maybe yeah all right fill us in on the rest yeah just a couple common tools i wanted to mention uh so you know talked about a lot about netlify let's encrypt github and node making a killer combination

because you can do your builds it's https everything just kind of flows nicely and it's all free there are also a lot of really good static site generators i mentioned gaspy a few times there's also jekyll hugo hexo middleman pelican if you've heard any of these then we're talking about static site generators i want to mention discuss because that was a common way of getting around some sort of problems through an api because that's something that's traditionally been a problem it's like well i want live comments i want people to have interactivity with the site. And we can say, well, why not slice off the parts that need to be interactive

and up-to-date and keep those separate? And so this is like an older service, but it plays in nicely with this kind of philosophy. Well, I mean, going back to our – I hate to keep bringing up the e-commerce example, but there are similar services and APIs for product reviews. To where you could have your product page could be mostly static. It's probably not going to change that often.

You're not going to change the description that often. So maybe you would have that in like a, some kind of a solar index or, you know, elastic index. Uh, but the other pages, the other parts, like the reviews you might have served from this other API. Yep. yep and search engines too are a common use case although we mentioned it's kind of you're dipping into spa land heavily because it doesn't make sense to necessarily generate all the different things that you can get different permutations and filtering that you can do but it's often cited as a kind of a good pairing there so this year i'm all about jam stack and search uh hello cms is that's kind of a a newer term that's being bandied around,

but it's just the idea that your site is the output, and it's not necessarily married to what you use to generate it. So that's kind of tying into this philosophy. There's some overlap there, and you'll be hearing more about things like WordPress headless and things like that, I think, over the next couple of years. Dude, there's actually a headlesscms.org

that is all about this for Jamstack. Interesting. I still think that we're in early days for Jamstack, but I personally think, you know, if I were doing this survey, I think that it's going to be even more popular over the years. And I think that we're going to get around some of these humps like the usability problems and things like that.

And I think the static site generators are going to get better and better because they're so useful. I still think we've got to come up with a clear definition of what makes it Jamstack and what isn't. Yeah. JavaScript, APIs, and markup. There's a definition. You say that. I'm not big on and markup. There's a definition. You say that. I'm not big on the markup. Google Docs, I wanted to mention

because a lot of people are doing things like you'll have a form and it'll end up just kind of dumping you into Google Docs or you could do something like SurveyMonkey or whatever using something else for that interactive content. So that was interesting.

And we mentioned Contentful earlier as being a way to kind of host dynamic content and be able to pull that stuff from a static website without you having to host that or have a database or whatever. And so you can still get that dynamic type stuff and people can go in like a marketing team can go in and edit those content snippets and your website is responsible for like arranging those snippets. And so it's a way of kind of solving that marketing problem that we talked about. So I expect to see more services like that in the future. And I thought that was kind of a good example of attacking that problem. And so what tools are in the outs?

And these are the ones that are losing ground to Jamstack. So if Jamstack is going up, what's losing ground to this? And that's where I think it's like the CMS is like the WordPress ghost, Embraco, Drupal. There's sites that used to be done in those technologies that are going to be done less as people do more stuff with static site generators. I'm sort of shocked about the WordPress thing, seeing as though we just found out that a quarter of the internet runs on it. Yeah, man.

It's not going anywhere. Yeah, I don't think that one's dying. Maybe some of the other ones. I don't even see these other ones going anywhere. Yeah, I don't think that one's dying. Maybe some of the other ones. I don't even see these other ones going anywhere. Drupal's still a... It's a big one. That's a huge one. I don't see that going anywhere. I think it's going to depend... It might

fall out of favor. Developers that want to stay on the bleeding edge of technology, it might fall out of favor with those developers. But in terms of businesses, it might fall out of favor with those, uh, developers. But in terms of businesses, I don't see the businesses are necessarily going to be like, Oh,

well, jam stacks now a thing. So let's get rid of Drupal. I think that was a key differentiator that you just said right there with developers. I think we might be gaining ground and something like jam stack. Cause it makes sense. Right.

But for people that just want to go do things that are not developer savvy, they're not going to be doing it. It's like you said earlier. You're not going to have a marketing crew come in and do Jamstack. They will set up a WordPress site in 30 minutes and be up and rolling, but they're not going to be able to do that. Yeah. I think I know Orlando has a WordPress user group.

I know that. I'm sure Atlanta has one too. And I just think that there's going to be some fraction of those people that are making websites for restaurants or whoever else are making small kind of mom and pop websites. Some portion of those is going to say, you know what, maybe I should just do this, you know, static site. And I don't have to worry about it going down in the middle of the night and not finding out. I don't have to worry about a plug in going out of favor. There's gonna be some percentage of people that start swapping over to technologies like that or like this. And I hope that over time that, you know, that number

increases and, you know, WordPress is, is good. There's a lot of reasons to use it. And certainly that momentum behind it is a reason for it. But I think that there's some percentage of that that doesn't need to be WordPress. And it's good to have options. So we kind of talked a little bit about what those kind of out tools buy us, whether it's usability for the management of the content or there's some features and stuff that we get out of the Drupals of the world, like plugins or whatever, uh, that, that are nice to have. And I, I still think that there's a need for those and you know what, we're going to see the table shifting there. So maybe over years we'll see more services that kind of fill in those blanks and maybe not. And, uh, we talked about, you know, maybe this is the first question you ask when you

start thinking about a website. So like I've been talking about making a conference website that tries to bring together like dev conferences. For me now, the question is, should it be static first? And I may say no to that, but that's the question that is now, you know, absolutely in my list of things to think about when coming up with a new project. And it wasn't that way five years ago. I would never have considered this. And then here's the tough question for me, because I've always been a backend kind of focused person. I want to know if our backend island is shrinking. I don't think so. Only because if anything, it's going to put more importance on it. Because if you're trying to make it to where people can write these UI things completely separated, then you're going to have to put more thought into how your backend is created, how it's exposed, how people use it, all that.

So I think it just adds more importance to making stateless backends that people can use in their applications, right? It might actually make it more difficult, to be honest with you. I think that the reality of our current world is that the favor is that our backend island is actually a bunch of islands. It used to be one big island.

So you had one server, and everything was on that one server. But now that's not the preference anymore, right? Like serverless, for example, right? Just functions that sit on someone else's server, and they get spun up as needed, and they scale as needed. That's just one example, right example of how there's many islands. So I don't know that it's going away or shrinking. I just think it's like we're distributing it. And it's getting more complicated because of that distribution of it.

You definitely have to change your mindset about things. You can't just assume, well, you got here to this server, so you must be authenticated. Right. I do think that backend work has changed a lot over time. It used to be a lot of my time was spent with CMS. He typed things where people wanted to be able to pop content in. I would build a lot of those forms and things.

So like whoever in marketing could do that sort of stuff. And now the, the marketing people got tired of paying my salary and said, yeah, I'm just going to use WordPress or whatever. And so I think tools have eaten that space and that work that I used to do. But all I do is just work on other things. Now I do more work in other areas and things that are unique to my problem domains. And I feel like overall more productive. But I don't know. I'm still not sure. I think that the back end island might be shrinking because of those commoditized services, because of things like Netlify and the clouds and stuff. So I think that every day I'm seeing more and more stuff that I used to do

being kind of transitioned to a third-party service that you can get for $5.99 a month. So I don't know. I think it's getting smaller, but I don't think that's something to be afraid of. It's just evolution. It's like you said. You change from one thing to another, right? You start working on different pieces. So, yeah.

Yeah. I am curious, now that you've done a Jamstack thing, because we've derailed you 900 times throughout this conversation, what did you find was good and what did you find was sort of annoying or challenging when you were doing yours? So for me, for sure, Gatsby has been a big learning curve. And I haven't liked the way that it's worked in certain aspects. And I do a little bit of React, but not a whole lot. So there's some kind of toe stubbings there. But there's just some other stuff like it's really biased towards GraphQL and a couple other things and kind of a plugin economy. And so there was just a lot of having to learn about that specific tool.

And I wouldn't have predicted that. I think, oh, it's a JavaScript site and a static site. I kind of assumed it would just kind of spider through my React app and do everything. But that's not how it worked. It was very much more like me telling it to create this page, create this page, and some other type things and chaining plugins together. And so it was a much more like me telling it to create this page, create this page and some other type things and chaining plugins together. And so it was a lot more work than I expected specifically for the static generation. What I didn't expect though, was to like the output so much, being able to host something for free, to be able to pump out hundreds of pages in no time and just have that stuff work reliably and amazingly has been fantastic. Gatsby almost makes it sound like the M is supposed to be mobile.

If you didn't know anything about it, like if you look at Gatsby, they say the future of the web is mobile, JavaScript, and APIs. That's the jam The Jamstack. Gatsby has really good plugins that will do things like automatically massage your images and make them more what's called – it used to be like save for web in Photoshop. But it'll efficiencyize your images. It'll resize different ones for different response of whatever, and it'll kind of manage a lot of that stuff for you with plugins so you don't really have to think about

you just kind of say i'm using the image plugin here's my directory and it kind of manages that for you which is really nice so that makes sense to me why they would kind of focus on that that mobile there so overall even with the pains that you had, would you do it again? Are you a fan of it? Oh, for sure. Okay. For sure. You didn't know he was already a fan.

He's been like raving about it. He's been dying to do this episode on Jamstack now for a while. But what is it so much? Is it the cost that you're like, oh, that's awesome? Or like what's the one selling thing to you that you're like, this is that's awesome? Or like, what's the one selling thing to you that you're like, this is why I would do it again? I get to focus. It's just a nice developer experience for me.

I get to focus on the front end, look and feel. I don't have to worry about a backend and I don't have to kind of have that cognitive load of dealing with like half JavaScript and half Ruby on Rails. I can just focus on my one thing and then I don't have to worry about hosting. I don't have to worry about a build process. I don't have to worry about Docker.

It's just boom, done. But hold on. In fairness, though, it's what dev podcast app, right? Podcast, plural. So the one thing, though, that I'm curious about is there's nothing interactive on that page. Like the one thing that you said that you've got to hack in for when you're trying to get some data is this actually jumping you out to another site. That's not an ideal experience, right? That's how it is for now.

That's like one of the next things I've got going on is I want you to be able to search and I want to have like a little search. Actually, what I want to have is because this site is really about podcast discovery. So you can kind of browse by tag or also do searches. But I really want to kind of keep you on this site. So I want to not have so many links to QIT, although I want QIT to be heavily kind of in the ecosystem. But this site is almost more about learning. So I want you to be able to search and I want to show the search results. So we can kind of say like, this is how you can find things that you care about. And then I want the link over to QIT. So this particular site is not, it's more about education and discovery than it is about actually searching

and playing. And I still want the focus for searching and playing to be done on QIT, which is like a stripped down app. I don't want to bloat that up with a bunch of content and like kind of lessons learned. So I just want that to remain the app. And I want want to bloat that up with a bunch of content and lessons learned. I just want that to remain the app and I want this to be more about the content side of things. I do want that search experience there. I do want you to be able to search. I want to show the top five results and then I want you to be able to queue it up over in QIT. If you're going to play it, play it in QIT. Okay. You got to use your imagination a little bit.

Well, I found a broken link. I'm trying to figure out how to fix it. I'm going to put in a pull request. Yeah, I didn't write any tests and I really should have. It's like one of the big selling points of kind of like using something like Gatsby or whatever

is they've kind of like thought about that testing experience and have built you in some support and examples for it. And so, yeah, I mean, I think that's about it. It's definitely been a more controversial topic than I expected.

I hope it gives you something to think about. Can I, well, let's talk specifically, maybe your specific jam stack app here might answer some questions if you don't mind yeah it's like if you go to devpodcast.app slash shows right and then you'll see a bunch of content and if you watch your network tab there right uh and you click on something, you'll get a canonical for that show, but you won't see any new network tabs except for the image of the show.

So in that case, I think what might be going on is maybe Chrome is doing some sort of preloading on some of those links because this is absolutely a separate file. Yeah. That's similar to, that's similar to the Marvel thing earlier. I think it's not killing off your, I'm in an incognito window. Well, you know how Chrome will sometimes go look too,

and it'll kind of like navigate past for you and kind of predict that what you're going to click on. So like if I, if I go to the shows page, I clear my network traffic and then click on a show, then I

should get all the content for that show. Interesting. I'm going to put in a pull request. I know how to fix this problem. Yeah, awesome. Yeah. Is it in our coding blocks? Yep.

Yeah, I see what you mean, Al. That is interesting. Maybe that's why I was having such a problem trying to understand where the definition of this thing falls in line with looking at that marvel app yeah so check this out so if you go to that shows page and watch the network app uh clear clear the network tab and then mouse over each of those links but don't click on them

yeah it actually starts loading the content for it that's cool and so yeah it looks like in this case it's not actually uh generating the uh that's funny it's not generating the uh html for this file okay so you're telling me then that i'm just seeing some efficiencies in chrome and that's why i was having trouble with like the marvel looking at both the Dev Podcast app as well as the Marvel Search app, trying to understand the breakdown of where is it jammy and where is it not, right? No, no, no. You're totally spot on here.

So this is a misunderstanding on my part about how the Gatsby part worked for the shows. And not all of the things are like this. The shows is one where I use kind of a template. And I assumed that it was generating all the HTML for these. but what it's actually doing is it's got one page there and it's taking care of like basically if you mouse over if you load something it will just kind of pop in the stuff that's changed and it doesn't do a full reload so it's kind of taking care of spa find this for me which is very strange to me. Oh. Okay. But if you go to the index page, it's a full reload. If you go to the tags page,

it's a full reload. It just... That's interesting. So it's kind of Spotify'd it for me. And what it's doing is the content, so I mentioned those shows and whatnot, that's actually being pulled from the CDN as well. there's no database or anything that it's able to access

so when it does that it's still pulling that dynamic data from the cdn somehow oh okay here we go so like when you mouse over those shows or when you click on the shows and it returns that JSON file, that is actually a file that's on disk. So you can copy that path and open it in a new tab. And so it's just not doing the full HTML. It just got the JSON data specifically hosted on the CDN. That's cool. That makes me like Gatsby more. Well, my job here is done then

because that was my goal all along. Yeah, so that makes me think like maybe with the Marvel API, maybe it's not fetching all that stuff from the API. Maybe that's why it's so jammy is maybe that it's got the the JSON files for the individual

like issues or whatever stored over in JSON files that it's got the JSON files for the individual issues or whatever stored over in JSON files that it's just able to fetch from the CDN rather than pulling all that stuff back and maybe only pulls the minimum information from Algolia. So it is very – so we're saying then that it would be very spa-like to have, you know, a Jamstack app would be very spa-like or could be very spa-like using these two cases as examples. Just the difference is that your content that you might go to another page isn't coming from a database or API call.

It's coming from content that is cached on a CDN and like a JSON file. Yeah, which is different than I thought. So I assumed everything here was generated files, but it's actually there are files that are generated like the index page, some other things, the latest page, but there are things that I did kind of with one of the plugins that it's doing very much spa-like. It's just getting the data from a CDN.

I'm going to go clone this repo. That's pretty cool. Yeah, you should. I found a broken link too. Dang it. I want to find a broken link. Okay, so with that, I think that basically wraps up everything that we've got here and we've got several resources we like here. We've got's time for my favorite part of the show. It's the tip of the week.

And I didn't think that it was all that controversial, just tons of questions from curious minds wanting to know. Yeah, and a dramatic reveal there at the end. It was just more like my ignorance of the subject that, you know. Both of ours. I just had a bunch of questions. Yeah, I think those are all the questions that, you know, both of ours, I just had a bunch of questions. Yeah, I think those are all the questions that anyone who's familiar with JavaScript and doing things is going to ask is like, what's so different about this? That's kind of like the main thing.

It just sounds like JavaScript to me, right? Right. Well, yeah, it makes me feel like the old Commercian developer, like, what is this Jamstack? I don't need that. Get off my lawn. Like Jamstack being j don't need that. Get off my lawn. Jamstack means jQuery. You do that so well. You got to prepare for retirement somehow.

That's right. So tip of the week. So mine is going to be Advent of Code.com. I mentioned giving up on this earlier in December. But what I've kind of decided to do is just try and do all the Advent of Codes for all the past years. And there's been four of them now. And each one has 25 problems. And what I'm thinking is if I do all 25 problems from all four years,

that's 100 problems that deal with things like BFS and DFS and heaps and graph algorithms and all sorts of stuff that I don't typically run across on my day. So it's a nice collection of problems and varying levels of difficulty that kind of, uh, exercise different parts of my brain that don't always get so much exercise. And so that's one of my kind of goals for 2019 is to go through all those past years and do all those problems and hopes that next year I'll be able to really kick butt on the Adventa code. So I just wanted to kind of list that website out as a tip because of those past years being available.

All right, nice. I'm going to be playing on the vibe while you're doing all that. So, so mine is, is sort of silly, sort of not like, and I know that people are going to be like, he's never been on the interwebs before.

So the Facebook marketplace, man. Oh, my God. That place is amazing. Joe, you ever been there? No. See? All right. At least 66% of us find this fascinating.

But Joe, did you know that the marketplace existed? Oh, wait. No, no. I know this. Get off. Yeah. Get off. Yeah, I look at stuff all the time near me Oh, wait. No, I know this. Get off. Yeah. I look at stuff all the time near me. You lie. Alright. Here's the difference. I mean, Alan's not joking when he says he doesn't know the internet. Yeah, I don't get on

this thing. You miss so many pop-cultural kind of references that we'll make or a meme reference. You're like, wait, what? Yeah, and I'm not afraid to ask, right? I don't want to miss it twice. How long has the Facebook marketplace been around? Let's see if we can find out.

Now, in fairness, I've known about this for a while, but I've never actually gone to it because I seldom get on Facebook. But, man, it's amazing. Like, I could totally lose myself in this section because it's like the classifieds except you can't hide behind things right like you can see oh this joe's that guy oh he just created his account yesterday i'm not buying anything from him right so man if you haven't been there so you know with new year's resolutions and all that which i hate completely but i'm getting way too fat so i was like you know what i need to find some exercise equipment and and i was looking at new equipment. I was like, man, I'm not spending that much money on something that I'll probably touch five times, be excited about, and then eventually put it on Facebook Marketplace.

So I went and found some that looked like it had never been touched, and I got it for a song. So now I'm in love with this. Now I just randomly go up there and look at other people's crap, which is really interesting. Yeah, it's all your area. So you can like go drive and i just found a tattoo starter kit for 120 dude go get it go get it it's a sign reminds me oh my god it's really close to me too okay okay okay just tell me what you want to be okay okay sir All right. So that reminds me because we got Joe back and I don't remember where I saw this. Now, if it was in a, uh, was it, was it a comment or a review? Yeah.

But, um, you know, Joe years ago, you made this promise of a Microsoft tattoo if Visual Studio Code were to ever go cross-platform. Not code. He said Visual Studio, which also has been cross-platform. Well, okay, fine. I don't care. You can mince words however you want. All right? Visual Studio, fine.

And, you know, many listeners now have been calling you out on this, like wanting to see this tattoo. And, hey, here's the thing, Joe. As we discussed earlier, Alan and I are going to be in town here in March. Oh, boy. Matching tattoos? Why do you want the matching part i will gladly fund from the coding blocks account said tattoo for mr joe's act oh wow gauntlets thrown what makes you think i don't have the tattoo oh i'm pretty sure we would have heard about it so i'm saying we should get with this

tattoo should happen and we we should make a big production out of it you know we have episode number 100 coming up and we need to do something special oh man all right we'll tell you what i'll show you guys tattoo promise should be part of it If you're watching the video for this episode, you're about to see it. So hang on. I'm probably going to knock the microphone here. So I apologize for all you listeners. Wait, he's going to draw something with a Sharpie real quick.

That's hilarious. Bravo. Are you guys laughing at the tattoo where it was well played sir well played so uh for for our listening audience there uh i will say that joe uh as he was standing up he very stealthily i might add cut off his video feed so that none of us could see what he was actually trying to show well played sir well played oh that's so good i'm just saying go ahead and clear it with the wife because this needs to happen while we're in town oh man just go ahead and buy that kit man one of us will do it for you

i was taking him to a proper a proper place you know to have them do it i'm okay with that uh so amazing so yeah that's mine mine is not developer focused at all but i now i know where i can go find crap that other people want to get rid of for free or cheap okay i need a new tip of the week because my tip of the week is going to be for a well-established tattoo shop in the orlando area we're not well established we'll take newcomers too you know i need a respectable one i you know he's this is my friend i'm looking out for him here hey people trying to trying to eat man they're trying to earn a living hey this one has like almost 500 reviews with 4.6. I think we should take him there. I think Joe's about to drop off.

Break it up. This episode did not go as planned, huh? All right. So I will, I'm sure, according to Joe, gladly skip ahead to my tip of the week, which is to use code snippets in Visual Studio. So you can select some code and say, oh, I want to put this into a for loop. And it'll go ahead and put that code into a for loop structure for you. Or you could not have anything already and say, I want a for loop. And it'll go ahead and create that basic structure of a for loop.

Uh, that tip I want to say came in from our tip hotline. So you can go to coding blocks.net slash tips. And that one comes to us courtesy of, oh man, I even practiced this one earlier. Uh, boy, I'm drawing a blank on it. I give up. Every time I look at it, I'm like, that's just gibberish. It doesn't make sense, except for the Tulu part. But no, you go ahead. Say it, Joe, because you say it every time off the top of your head.

Latris Cthulhu. Latris part. Okay, that was the part that was thrown at me. Okay. Say it all together. Latris Cthulhu. Latrous part. Okay, that was the part that was throwing me. Okay. Say it all together. Latrous Cthulhu. Close enough. I think I still messed it up.

That's like the glass sculptures, right? Cthulhu. Oh, that's awesome. I think that's what you get at Chipotle. Hey, by the way. Or a Metallica album. Everybody that has done Cold Fusion in the past is like, oh, that's sweet. Outlaws tip.

That was in CF Studio back in like 1992. Hey, man. Hey, man. Listen. You watch it or you're next for the tattoo. Hey, I don't ever say anything like that. Oh, man. You'll have a big for loop tattooed across your chest or something.

All right. Joe, you got this? Got what? The last part. Oh, the show summary? Yeah, there you go. Well, now I want to go re-record the whole thing because I've got all these new thoughts about the M being structured markup. Like, it totally changes how I thought about this whole episode.

Oh, because it was actually the JSON that was being generated? Yeah, the templated markup. Like, now it makes a lot more sense to me to think about it being able to pop in that content from static CDN and popping that content into some sort of like templated kind of thing. Like we saw with the Marvel API. So in other words, if you're as confused about Jamstack as we were, then, you know,

you're welcome. Yeah. Yeah. I'm in, you know, just, I feel bad about like the two hours of misleading everybody. Hey,

you know what though? I did forget. Uh, I'm going to throw in a joke real quick. One more, because I meant to do this earlier and I forgot. So I'll throw in one more. And this one will come to us courtesy of Justin. And again, these were sent to us a long time ago.

So if you have more jokes that you would like to send to us, feel free. You can send them to comments at codingblocks.net. And we would love to hear your favorite programming jokes. But Justin writes in and says, I had a problem with C, so I switched to Java. Now I have a problem factory. Oh, yes. All right. So with that, subscribe to us on iTunes, Stitcher, more using your favorite podcast app in case

of a friend happened to like send you a link send you a link or let you borrow their device. And if you haven't already, be sure to leave us a review. You can visit www.codingblocks.net slash review to find some helpful links there. And as I said earlier, we would greatly appreciate it if you shared us with a friend. Yep. And while you're up there, check out all our show notes, examples, discussions, and more. And send your feedback, questions,

and rants to the comments or the Slack, codingbots.slack.com. And make sure to follow us on Twitter where you can yell at me for not understanding what the M meant in Jamstack

even though I've been proselytizing it for months. And you can go and find all our show links, social links at the top of the page. And if you are on Slack already or if you're not, you can join. But definitely beat up on Joe about that tattoo.

Just saying. Peer pressure.