Brian Rinaldi: 0:00

I think it's, it's not just, JAMstack this kind of common in web development nowadays. It's we don't build these things from scratch anymore. Right. Like, um, because you know, why. Why should I, I used to build a bunch of sites and every time I basically rebuild a CMS, it's like, you know, why would I create a CMS? Like I don't ever want to create a CMS. It's not really my expertise. So like, I'd rather get a CMS and rely on a company that knows how to create a CMS and have. You know, experts on that kind of thing. Same thing with the search and.

Fernando Doglio: 0:54

Hey, this is another episode, 20 minute JavaScript, where we cover everyone's favorite programming language with multiple guests from the community. This episode as always is hosted by OpenReplay an open source session replay tool for front end developers. If you're looking for a way to understand how your users interact with your application, check out OpenReplay. I'm Fernando Doglio your host and podcast ninja for at least the next 20 minutes today we have with you not one but two guests. So make sure you pay attention. We're going to be talking about the Jamstack with Brian Rinaldi and Ray Camden authors, among other things of the Jamstack book by Manning. So guys, welcome. And please introduce yourself, ideally, with more words than I did.

Brian Rinaldi: 1:33

Uh, my name's Brian Rinaldi. I am a developer experience engineer at LaunchDarkly. Uh, but I've also been using the Jamstack since, well, well, before we started calling it JAMstack, um, I started early days with Jekyll um, and I've been doing, doing a lot with all these technology since, um, wrote a couple books. One one with Ray prior to this and now the new one. Um, so yeah, that that's me.

Raymond Camden: 2:08

Hi, I'm uh, Raymond Camden. I am a developer evangelist for Adobe. Uh, I've been involved in the Jamstack five, six years or so definitely before the term came out. Uh, before that I was heavily, um, involved in the app server community around ColdFusion. Uh, so pretty much for 10 plus years, everything I did was an app server type type job. And, uh, JAMstack was a revelation for me. Uh, so the switch.

Fernando Doglio: 2:42

All right. Awesome. Thank you. So from what I hear, then it looks like you've been doing it way before. It was cool.

Brian Rinaldi: 2:51

No, no, not at all. It was cool at the time. We just, we were, we were, we were the only cool ones. We were just small group of cool.

Fernando Doglio: 2:57

Oh, right, right. My bad, my bad yeah. Trend setters is that that's the word. All right. Fantastic. So for those who don't know. What we're talking about. Uh, can you quickly tell the audience, what is the Jamstack and kind of, uh, how has it evolved since it was coined the term?

Brian Rinaldi: 3:19

Uh, sure. Well, it started out as just static sites. We used, we called it static sites. I mean, in fact, our first book together was called working with static sites. Um, because you dos it. Static site generator like Jekyll or Hugo. Um, and later on things like Gatsby and stuff to generate static files that would then be uploaded to like a, you know, via a whole CI/CD process to something like Netlify or Vercel. Um, and that the reason we kind of changed the name is because this. Just didn't really describe what we were building. They weren't just purely static sites. They had dynamic elements. We were using APIs and other third party services and things to add, to make very dynamic sites. So that's why we kind of changed the term to JAMstack. It's a bit misleading because. It's not really a stack. Um, it's more of a methodology of how you build sites, cuz there's a thousand different ways, at least that you could build sites. Um, like Ray loves Eleventy. I like Hugo , NextJS and some other stuff. Um, you know, and each of these has different approaches for how you build things. Uh, even though the underlying concepts are all the same, right? Ray?

Raymond Camden: 4:42

Yep. Yeah. I, I think that's fine. Yeah. And you know, I, I, I don't get too hung up on the name. You know, if we can accept serverless, if we can accept cloud, then we can accept Jamstack.

Fernando Doglio: 4:55

that's fair. All right. Um, alright. So you guys mentioned, um, uh, that it all started essentially with static sites. Right. Um, is that but it evolved, right? Yeah. You've been adding dynamic content and, and it was, it's been evolving into, into something else. So, um, is it fair to say that Jamstack or, you know, this way of architecting, essentially applications is not just for simple, uh, sites like static sites or simple blogs, uh, and, and you can actually build complex, uh, applications with it.

Raymond Camden: 5:34

yeah, I, I would say absolutely. Uh, you know, I think at the beginning, uh, when the tools were a bit more rough, you know, it was definitely more tuned for simpler sites. And by the way, I think when we say simple, we shouldn't like say that in a bad way. There's absolutely a lot of value, um, in simple sites and, and they're also very important. Um, , but I definitely, with the amount of tools we have with the variety of tools, especially like Hugo going Eleventy, it couldn't be more different, I think. Uh, but that's great. Cuz that means like full your team. You could find something that's gonna work well, uh, everything has leveled up in the last five or so years, uh, to make it, uh, definitely I think more. Uh, appropriate for more complex websites.

Brian Rinaldi: 6:21

Yeah. And if you look at something like, uh, like a NextJS or, or other similar, Nuxt, in other similar types of, uh, you know, well, still call 'em statics. sites generators, but even. Even those have server side rendering and edge rendering, which like renders on an edge function. Um, which is I, you know, we could spend the whole 20 minutes just explaining what the heck that means. Um, so, you know, the, the point being this has gotten. Well, it's gotten more complex, um, in both good and bad ways. I mean, I'd say the good is there really, isn't a type of site you can't build with these tools, the bad being we've lost sight, a little bit of the simplicity that some of us, um, I'll speak for Ray. Assuming I think we were both drawn in by like, , this was kind of getting back to the basics of how you built sites back in the day. And now, you know, when I gave a talk that was, you know, uh, an hour just talking about different rendering methods. Um, in the Jamstack and in how you pick and choose what, how you render a page, um, which is an important topic, but also like when you're getting that deep, it, you've lost a little bit of the simplicity. Um, it's very powerful, but it's not so simple anymore. Mm-hmm Yeah. And to clarify though, and to Ray's point, some of those tools still allow for that simplicity. Like I think that's why Ray loves levy. You don't have to dig into that complexity. Right?

Fernando Doglio: 7:59

So you have, you have the, the simplicity from the original, uh, from the, from the get go. But if you want to, uh, get into the details and, and customize it and, and, you know, get that power, you also have that option. Is that what you're saying?

Raymond Camden: 8:14

Mm-hmm yeah,

Fernando Doglio: 8:16

so. from what I've been trying to understand on the Jamstack, because I never personally work with it. Um, you distribute the, the, the, the business logic out, right? Uh, you, you, you focus on the UI is that, um, and then you use services to, to get that to orchestrate essentially, or. Sorry, you orchestrate the external business logic, uh, on, on your own, but the core, the core functionality is not developed by you, but it's developed, uh, by third parties. Is that kind of a fair assessment?

Brian Rinaldi: 8:55

um, I'd say yes and no. Um, we use a lot of third party services for some of the external stuff, but that doesn't mean that, that that's all you, you do. Um, you can write your own Lambda functions and use those. Um, you can have a backend that's even a database and use that. Um, and it doesn't have to rely on. On a third party. Um, obviously this is generally speaking, gonna be deployed where the backend is serverless. It's all functions sitting out there, um, deployed, um, separately, but usually that's handled by whatever. deployment tool you use. Um, so, so yes and no. I, I think that the part that I'd quibble with is more the, that you only rely on the third party stuff where it's not just that it's, it's a combination. Okay. I think,

Raymond Camden: 9:53

you know, a good example of that is that I have these sold sites that were using SQL server on the back end. Uh, that wasn't third party. That was part of my stack. I could absolutely still use SQL server, uh, for the jam stack, just that I would use it during the build. Uh, I wouldn't be in production, hitting SQL server for data. That's not changing. My build would hit my, uh, tables, get my information and print that out and just be done with it. So it's not a third party service at all in that case.

Fernando Doglio: 10:23

Understood right interest.

Brian Rinaldi: 10:25

And you could hit SQL server from a, a Lambda if you wanted to, um, you know, at, if you needed live data, when the site, you know, that changes on the site as well. Um, but the goal being you want to pre-build to, you know, to Ray's point, you want to pre-build as much as you can, right. Mm-hmm , uh, You don't want otherwise, I mean, if it's, if everything's just server rendered, then you've kind, I feel like you've kind of lost like a little bit of like, what, what makes JAMstack great. Um, some people quibble with that. Some people disagree, uh, and we like in the JAMstack community to do debate what the heck Jamstack means um, so, you know, there's still, there's still people who. Would disagree with that, but, um, I'd be right and they'd be wrong. So that's,

Fernando Doglio: 11:23

that's right. Okay. Uh, my understanding was, was, uh, not entirely correct then, but while you still can, uh, write and, and, and, and create that, that part of, uh, backend logic, uh, that you're saying, uh, that still may rely on third party services. Are you. Comfortable in relying on these services in the sense that, um, uh, if there's a rich-enough ecosystem let's put it that way, uh, of third party services that allows you to create these kind of, uh, complex applications without you having to write the whole thing, uh, from scratch, uh, like essentially you mentioned SQL server. Uh, so that would mean you actually, you have your own SQL service, uh, but have you found any. Limitation as to, you know, you know, as a type of service, a type of system that you needed and was not available in the way of an API that you had to, uh, to write yourself every time.

Raymond Camden: 12:25

No, I mean, it feels like there . Really is an API for everything out there and in cases where there isn't, there's serverless to do really weird complex stuff. And even then I'll still be using APIs probably.

Brian Rinaldi: 12:40

yeah, I would agree with that. Um, I think I found that usually there's more than one service that can do. Um, and you're just, the hard part is picking which one really best suits your use case. Um, and you know, most of these are, are really designed to be highly available. So this is not like something where, you know, you're. Your site necessarily goes down because because of a service goes down and in fact, the whole architecture is really designed where that would only break the piece that connects to that particular service. Um, so like any, any page that has. Pre rendered content, obviously that, that functions. So, so maybe a piece of the page that has some dynamic aspects isn't isn't is down, but the rest of the site still works. Um, and that's one of the things like having come from, you know, background where like, You know, I'd have database connection errors that took my site down for, for extended periods and things like that. Um, you know, I I'd love the idea that, that this was always available. Um, and, and even you can isolate some of that functionality so that it doesn't necessarily break your site. If some particular service is down, uh, just kind of limits the functionality of the site a little bit. Yeah.

Raymond Camden: 14:11

And one day, you know, I, if I'm relying on Lambda to do something that, that goes down, there are incredibly much more intelligent people than me working that fix it. so I'm, I'm totally fine with, uh, relying on Amazon. Fernando Doglio: Yeah, absolutely. Yeah, yeah, yeah. If you can pretty much, uh, uh, be sure that if that goes down then yeah. There's really a lot of things going down at the same time. Yeah, absolutely. All right. And, uh, so it sounds like there is a lot. Of tools that you can use and you can pick from, so I will be interested in knowing what, what is your let's call it stack within the shop, stack your preferred stack? Uh, what, what do you usually go with? Sure. I'll go first. Um, I use Eleventy for the static site generator. Um, what I have found is that all these generators have their own way of doing things and some are very prescriptive. Like you must do it this way. And they fight you. If you want to kind of break the rules and Eleventy lets you do anything, it lets you break the rules. that lets you bad, bad code. If you want. You know, I want that freedom, uh, to be able to go outside the box when I need to, um, a great example of that is that, uh, they support a lot, a lot of unique languages and I needed to do something kind of weird and liquid wouldn't support that. So JCO, wouldn't be an option. Uh, but because levee allowed me to switch one file over to EJS, which is not a pretty language, uh, but EJS lets to do anything. So Eleventy basically, you know, allowed me to kind of, uh, you know, do that weird custom thing when I needed to, um, I used Netlify for my host. They've been really, really good for a performant. Um, in terms of API services, I kind of use a lot of different ones, uh, for. The one I've been kind of most interested in lately is Fauna for generic DB type access. Oh. And Algolia for searching has been really, really darn nice.

Brian Rinaldi: 16:22

Yep. I would agree with, with those recommendations, I, I don't use Eleventy myself all that much. I like if I'm doing straights static stuff, I use a tool called Hugo, which is built in go. Um, which works great for me if I have a lot of pages because it's really, really fast. Um, and I've been using it for a long time, so I'm comfortable with it. Uh, I also have used NextJS when I need something with more of a front end framework focused, um, tool set. Uh, I've I've recent started getting into SvelteKit, which, which uses Svelte. Um, and I'm, I'm really liking that as well. Totally curious about one called Astro. Uh, but I have not gotten to dig into it much. Uh, that looks really, really cool. It has this Island's architecture that allows you to only kind of enable with JavaScript the pieces of the site that need the JavaScript. Otherwise, it kind of decides like, okay, you don't need JavaScript for this piece. We will not have a. Pushed out JavaScript for that piece. So you can kind of, you can still use react components and things like that, but it doesn't necessarily mean you're shoving react down with every single page. Um, so you can cut down on the bundled size. Uh, I think Ray API recommendations are great. I've, you know, for headless CMS, I mean, I've used both like. Sanity and Contentful they're both great. Um, Algolia as you mentioned is excellent. Fauna is also really great. Um, so yeah, I, I, you know, kind of, I'd say for the APIs and stuff, it really depends on the project. I don't necessarily have like a, I have to pull these things. It's like, what am I building? And which APIs, and then I'll often do dig into doing a little research. But I also deploy it to Netlify, um, and have been using them since the very, very beginning, basically, uh, and, and love them. Awesome.

Fernando Doglio: 18:25

Great recommendations. And are you I'm I'm I'm wondering here because, uh, one thing that I always struggle with is, um, when finding new services, Uh, is that, should I, you know, should I trust this service? Is it, is it reliable enough? Are they doing things right? Are they going to be going to out of business next week? I don't know. Um, how do you deal with that uncertainty when you're, when you're looking for something new that you don't know, uh, how to do,

Brian Rinaldi: 18:53

I mean, It's really just a matter of research. I think, um, you know, I don't, if these are companies and things that, you know, they don't tend to go out a business overnight. Um, most these are well funded startups or are. Well beyond that even, um, you know, like the ones we mentioned, Algolia fauna, Contentful, Sandy. I mean, these have all been around for years. I'm not concerned that they go away overnight. Um, you know, and there are obviously some that are just some developer who puts, something out there. Um, Okay. And there's a bit of risk relying on those, but you know, you can kind of make judge on your project, particularly if, if it's statically built content, um, like that's being, you're pulling from the API on the back end, instead of pulling from the API on the front end, if it were to go down at some point that doesn't break your site so you can kind of judge, I do research and. Make a judgment call. I don't know about Ray, if it's probably the same thing.

Raymond Camden: 20:01

Yeah. I mean, even, even if I wasn't doing JAMstack, if I was evaluating a service, it's the same criteria, you know, who's behind it. How long has the company been around? Look at their support options. Look at how well they respond in general, uh, typical dev re type stuff that I do at my job. I look to see how they're doing it right on their service.. Brian Rinaldi: Yeah. And I think, I think it brings up an important point, which is that what, one of the things I love about JAMstack, but I think it's, it's not just, JAMstack this kind of common in web development nowadays. It's cause we don't build these things from scratch anymore. Right. Like, um, because you know, why. Why should I, I used to build a bunch of sites and every time I basically rebuild a CMS and it's like, you know, why would I create a CMS? Like I don't ever want to create a CMS. It's not really my expertise. So like, I'd rather get a CMS and rely on a company that knows how to create a CMS and has, you know, experts on that kind of thing and same thing with the search, et cetera. So. Like, you know, I can F I can then focus on building the site as opposed to kind of creating all the underlying technologies that make the site work, um, and lead those to, to kind of companies that have expertise in those specific area experience. Mm-hmm

Fernando Doglio: 21:25

absolutely. Yeah. It kind of. It's like a, a high level, uh, version of the discussion of whether should you create and allow your, every single library for, uh, on your own, or are you okay with, depending on, uh, you know, how third party dependencies in your code? Um, I think that, yeah, the, the same argument can be made. Absolutely.

Brian Rinaldi: 21:47

Yeah. Yeah. Obviously if you're choosing JAMstack, you're probably comfortable with. Fernando Doglio: Yeah, absolutely. I, but I, I gotta say I love it. You know, like I said, I don't ever want to build off again, if I had to build off again like that, you know, cuz I'm not good at that. And there's probably not that secure, but like there's companies that know auth and do it great. And it's just plugged that into my site done. Um, so yeah, it's, it's made, it's made the whole process much more enjoyable for me. Interesting.

Fernando Doglio: 22:18

All right. Finally, last question. My, and this is coming actually from myself, uh, because I've, uh, during the research, I found this concept of full stack on Jamstack that I. I'm really having a hard time reconciling it. Um, so can you give me an, uh, the audience kind of a quick version of an explanation of how do you think about that full stack on, uh, on Jamstack and, and, uh, kind of the frameworks around it?

Brian Rinaldi: 22:51

Well, um, something like an NextJS JS or SvelteKit or Nuxt JS or now Gatsby, um, they're all. They have both the back end and front end. Um, you know, so it is full stack, uh, like NextJS, for instance, react front end, and you know, to some degree use react on the back end as well, but it's most, it's like if running on node. Um, so it is full stack. It doesn't run. Like in what it does when you deploy it is it actually takes all of your backend code and deploys that off into serverless functions. So, so this is like you are doing full stack when you, when you do like have SSR pages, like server side render pages and stuff like that. That's a full of stack framework. It's just not deployed in the way, like you might think for your typical full stack where like you're deploying onto some server, the entire stack, like this, it automatically goes and separates out, like all of your functions and deploys those out as servers function for you. Um, so it's structured, it's designed to like, be able to kind of figure out what those pieces are and deploy them for you. If that, that makes sense.

Fernando Doglio: 24:05

Yeah, absolutely. Thank you. Interesting. Okay. All right. So, um, let's just go into the, uh, quick round that we ask to every, uh, of every guest. I know Ray has to go in, in, in a few minutes, so let's, let's just go quickly before he leaves. Um, so first question, what's the best advice you ever got, uh, career wise or otherwise?

Raymond Camden: 24:30

If it's, if it's not tech related, I will absolutely share that the best advice I've ever gotten is don't skip on a bed, like spend good money on a bed. I thought .That was, stupid and a waste of money . So I lay down on that bed and realize how much I like sleep that was given to me. And I give that advice all the time.

Fernando Doglio: 24:49

Interesting. All right. So next question. Uh, what's the most exciting project to worked on?

Brian Rinaldi: 24:54

Hmm I'm um, I mean, I've, I've built a lot of like, uh, company sites recently. Like, you know, I, I worked for a couple of startups recently and, and honest built, like the last one I built their, whole site, uh, using NextJS. Uh, so that was an exciting project, but I, right now I'm mostly excited. Like I, I got to kind of, I mentioned earlier I messed around was SvelteKit and I was really enjoying Svelte. And, and even though that's not exciting in the same in terms of like, I built some grandiose thing. Um, it was a lot of fun and I really enjoyed it.

Fernando Doglio: 25:32

Absolutely. We actually, uh, recorded, uh, an episode about SvelteKit, uh, a few hours ago., it'll be, it'll be probably, um, released with yours as well. If you're interested, keep an eye on it. Final question. Uh, what's one thing uh, that you wish you knew before you started coding,

Raymond Camden: 25:53

how unimportant math was? I've used math, like once in the last 20 years. I mean, outside like average, you know, stuff like that. Yeah. Math. I never used any calculus ever in my whole career,

Fernando Doglio: 26:08

but I bet you, but I bet you heard a lot of, you know, that that math was important, right?

Brian Rinaldi: 26:13

Yeah, yeah. Yeah. I would say like, you know, I was so focused on getting the project right. When I was young, like I thought there was a right way to do things. Um, and often I sacrifice getting the project done to getting the project right. Um, and. And, you know, anything you write today is tomorrow's legacy code. That you're gonna be like, ah, you know, yeah, I would've done that differently. So I've learned to kind of focus more on getting the project done, um, as opposed to getting it perfect.

Fernando Doglio: 26:49

absolutely a hundred percent agree with that. All right. That's all the time you have. Uh, so thank you both for being here for coming and please again, tell everyone where they can find you. And we'll just add all those links to the show notes.

Raymond Camden: 27:03

Raymond Camden on Twitter and my DMS are open and I love questions. Yeah.

Brian Rinaldi: 27:07

All right. And, um, @remoteSynth on Twitter, uh, and my DMS are open as well, but send your questions to Ray

Fernando Doglio: 27:19

All right, guys. Thank you again for being here and, uh, for the explanations. Yeah.

Brian Rinaldi: 27:25

Thank you.

Fernando Doglio: 27:27

Bye. Everyone. Catch you on the next one. Bye.

Raymond Camden: 27:30

Bye.