Visit nx.dev to get the preeminent open-source toolkit for monorepo development, today.
Colby Fayock chats with John, Ward, and Dan about what Jamstack is, what to consider regarding storage, how to handle forms in Jamstack builds, whether you need to start from scratch when using Jamstack, and what the developer experience is like on the Jamstack.
John Papa @John_Papa
Ward Bell @WardBell
Dan Wahlin @DanWahlin
Craig Shoemaker @craigshoemaker
Colby Fayock @ColbyFayock
Visit nx.dev to get the preeminent open-source toolkit for monorepo development, today.
Podcast editing on this episode done by Chris Enns of Lemon Productions.
Craig Shoemaker 0:04
Welcome to Web Rush, the weekly talk show that brings you Stories of Real World development from industry experts. And developers like you and me. Each week, Ward Bell, Dan Wahlin, Craig Shoemaker, and John Papa, find out what it takes to write, deploy and maintain apps that stand up to the demands of the real world. And now, here are your hosts.
John Papa 0:28
Welcome back to web rush. This is Episode 121, one to one. And today we're talking about a topic, a lot of us here really love and that is the jam stack with react. And we'll talk about some variations of react and some other tools you can use as well as the jam stack. And we're probably gonna have to explain to people what the heck the jam stack is out there, because it's relatively new. It's been out for a couple of years, but maybe you know about it, maybe you don't, but we're going to talk more about it today. And in for expert panel, I have my co hosts, Ward Bell and Dan Wally and I was gonna call you, Dan white, like Barry White, Dan, because I know you're a big Barry White fan these days aren't a huge,
Dan Wahlin 1:10
huge
Ward Bell 1:13
you know, since we're on the jam stack, we're obviously going to be jammin with Barry White.
Dan Wahlin 1:20
You know, I'm here I'm here for
John Papa 1:22
folks I know as we're doing our audio check before the show and Dan was starting to break into some Barry White for us. So we'll have to convince him to do that on every one of these days.
Dan Wahlin 1:32
Need to look up some more songs I think first but yeah, I'll jump right on that john.
John Papa 1:37
Well, speaking of people with really buttery, smooth voices, our guest today is Colby Fayock, how you doing Colby?
Colby Fayock 1:44
Not too bad. How are you?
John Papa 1:45
I'm pretty good. So it's gonna be one of those shows, folks. Coby. I'm going to introduce you to the folks out there just to make sure that he has a idea of what you do and where you're from. All right. Sounds good. To Colby works as a developer community as a developer advocate for applitools. You can find them helping others learn JavaScript, react and other web tools, with articles, video tutorials, courses and books. And he's Colby fak on Twitter, and we'll drop that into the show notes. Welcome to the show, Colby.
Colby Fayock 2:16
Thanks for having me.
John Papa 2:18
So you wanted to come on today, you wanted to come here I was,
Ward Bell 2:22
again, registered ama stack.
Colby Fayock 2:26
I was nice about the request.
John Papa 2:28
And I was so excited. I scheduled you twice for some unknown reason. But that was a little weird. So once I figured out how to use a calendar and email, we scheduled the show to talk with the jam stack. Can you kind of first start with folks on like, what is jam stack? Is this just another one of those words that we make up to make it sound like what we do is interesting, what is this?
Colby Fayock 2:49
So a little bit, but so it kind of came from the idea of a little bit of a negative connotation around the word static. So when you're talking about a static website, you typically think of you know, HTML and static assets, maybe in an s3 bucket or somewhere on Azure. But that might have a negative connotation if people want to have something that's dynamic. So the marketing team at netlify. And the people who work there came up with this term jam stack, which tried to expand on that. We're also incorporated the dynamic pieces of what makes the web Great. So that's become really popularized with things like JavaScript, where Originally, the jam stack stood for jam stack API's and markup. But JavaScript isn't necessarily required. It's more just on that static base. But JavaScript is really what popularized that
John Papa 3:42
acronym JavaScript API markup JavaScript API markup, that's what jam stood for, does it still stand for that? Or is it just become like, now it's just jam stack.
Colby Fayock 3:51
So most people say it still stands for it. But the community is trying to push away from that, because apparently causes more confusion. So they even change the spelling of it. So now, instead of capital j, m, it's capital J, lowercase a stack. So and it's not even necessarily a stack. It's a architecture and, you know, kind of philosophy for building applications. But you know, at the end of the day, it's static applications with dynamic aspects with tools like JavaScript
Ward Bell 4:23
applications, what's the static application.
Colby Fayock 4:27
So the static part comes in with how it's hosted. So whether that's dumping into static storage, and then maybe you're putting a CDN in front of it, ultimately, that first request is going to be that HTML that might be rendered out. And then once you get into the browser, if you are providing the dynamic aspects of it, that's where you're gonna load in the client side libraries that kick in and maybe they're making API requests or you also have the option of that kind of dynamic piece of it coming at the compiler. time. So another way to do it is, maybe you have a blog where the entire website doesn't need dynamic stuff in the browser. It's going to use, whether it's JavaScript or any other language tool for a static site generation, where it's going to build out each of those pages HTML. And that's all the person who's visiting your site is actually get to see
Dan Wahlin 5:20
what you just named one. I think a blog is a good one, although, well, two questions in for it. Number one, what are the primary scenarios where you'd see this being useful? I can think of some, but I'm sure you have some real life ones. And I guess as part of that, what if like, my blog needs search, though? Because now we're not talking static, obviously,
Ward Bell 5:40
if I want to buy something
Dan Wahlin 5:41
off your site? Yeah.
Colby Fayock 5:44
So yeah, so now jamstack lends itself well to e commerce as well. So that depending on the scale of your e commerce site, it might be challenging because you don't. So if you have a website, and e commerce store that might have like, you know, just throwing a number out there 1000s of products, when you compile those pages to be static, that compile time might take a long time. So that's where you might lend yourself better to somewhat server side solution where it's going to be able to dynamically hit those routes. But say you only have 10 products on your page, you can build each of those pages out as static, you load that initial experience, which the browser that first hit might only need to know the metadata. So the image of this site, the title, and then you can load in the data, the dynamic aspects, like the price, because that needs to be really dynamic, right? And things like the Add to Cart button to make sure that people aren't trying to over buy, or you know, that it's actually available for somebody to purchase. So have
John Papa 6:40
we just really run in circles chasing our tail like a dog, since my dog is sitting here, and you're all commenting on it? Think about let's go on the Wayback Machine. I remember a gentleman or friend of mine, who was some of you on this show might know his word Bell, wearing a bathrobe walking into an audience trying to explain to several 100 people in technology, what this new thing called spa was, we're gonna build a spa, we're gonna go to the spa and single page applications. And the hardest thing I remember about that term, which it still exists, but you know, it's died down is I don't want a single page for my app. I have more than one page, my app, why would you call it that? Now we're talking about static web apps. And you know, to the examples that weren't Dan threw up there, like search or buying something that's not static. And I get your explanation, right? It's not that the entire site is not changing. It's more in the way it's hosted. But are we just shooting ourselves in the foot with some of these terms? And now we're talking about jamming? Like, do I really want my stuff to jam? I mean, I'm being sarcastic and Siri log jam here, like, what's the point?
Colby Fayock 7:48
So I think there's a little bit of that, but I think it's also, so of course, people are gonna be dogmatic dogmatic about that they might be dogmatic about using rails as their framework. But, you know, there's nothing wrong with any of these solutions. But I think overall, the goal should be learning the best parts of each of those so that we can bring a solution for it, you know, maybe a static site isn't the best for your particular scenario. But the nice thing about it is you get a lot of benefits out of the box, like it's going to be really scalable, if you're just serving those static files, right, from static hosting, you know, especially with a CDN in front of it. And it's gonna be really fast, because you're not having to render that HTML in a server verse, you're just dumping it out of static storage. So you're getting a lot of benefits from that aspect of
John Papa 8:30
it. One thing to keep bringing up, which I'd like to dive into more in the show is, if I take one thing away from jam stack and static web apps, it's this. It's that we keep talking about hosting off of storage or hos hosting off a CDN, we're not talking about having a full blown ASP. NET, Java, PHP, web server in the backend or node server, hosting HTML and CSS and JavaScript and images. We're talking about storage, which isn't a new thing. But I'm getting from you that maybe the way we do that is either easier or more efficient or more predominant these days. What's your feel on the storage aspect of that?
Colby Fayock 9:15
Yeah, so I think that's a good point, because there's been solutions. I know Asher's, come out with the static web hosting. I haven't actually tried that yet. But companies like natla phi and for sale have popular lies popular is this static hosting solution where if I check out my website, and GitHub, I can have a build command that'll statically generate that site. They'll run that build command on their servers, dump it into storage, and serve it from their CDN. And that's all you have to do. You make that integration connection, run the build command, and you have a statically generated site hosted on netlify. You know, from there, going back to the kind of server full solutions, you still might use a server, but at that point, you're using it for data, whether it's querying it at build time, or if you're in the Client hitting an API to provide that dynamic value.
John Papa 10:04
They can have hidden things. Right now it's about time to hit it up for a word from our sponsors,
Craig Shoemaker 10:08
Hey, are you building apps in react Angular node, or some other framework? Well, with Nx, you can build your full stack apps and shared mono repo integrate with modern tools and reinforce best practices, you'll get advanced cogeneration, and automatically configured tooling like Cypress jest and prettier that will simplify your workflow. annex also helps you simplify the relationships between applications and shared libraries to make it easier to share more code and develop more consistently across teams. And the best part is, you'll build higher quality apps and spend less time on configuration. So visit nx dot dev to get narwhals popular open source tool kit for mono repo development today. Alright, and
John Papa 10:51
we're back in Word hit it because I know your face is making all sorts of contortions over there. Yeah, I'm
Ward Bell 10:57
trying to get I'm missing something. And it's I'm sure it's me. I'm trying to miss the dividing line. So if I, if I understand this is mostly for where I'm consuming the resources of the site, right? There is, if I have an app, because I spend most of my time building applications that are you might characterize as forms over data where I'm asking the user because I build for businesses, internal apps, that are sort of over the web, or even public facing ones. But where they're asking for, you know, they're having the interaction with the user, is give me your first name, your last name, your Social Security, you know, just endless forms. I take it that's is, is that kind of application suitable in the jam stack? Or? Or is? Or is it because my vision is that this is a site where I'm just browsing around a jam stack would be for some, we're just browsing around looking for content? If I got that distinction, right, or am I way off base.
Colby Fayock 11:55
So I think that's definitely part of it, I don't think it needs to be only something that you're browsing around. And I can get to that in a second. But as your forms example, you know, whether or not you do need to provide any dynamic aspect to that form. Loading that form in its initial page really doesn't need to be special in terms of generating something server side, you know, or it can, but you can also load those things in the browser where, say, You load that static form. And if you need specific data for that person, you can load that through an API onto the site. But that first form experience is going to be loaded a lot faster, because you're just giving them that HTML, which then gets hydrated inside of the browser.
Ward Bell 12:34
That would be if I get the word static that keeps killing me because killing me, it's my it's my, it's my, it's my, it's my understanding, I'm trying to understand where that dynamic quality of a static site it lives. Again, in my, in my application example, I almost never composed a form in a way in which you know, what the fields are going to be with on the form unless you know what the data is, because what you choose to ask the user depends so much on the data and the account. And so everything about that is dynamic. And now I'm not saying it can't be rendered server side, clearly, it could. But that's my whole worldview wrapped around that. So I'm getting the sense that's not the optimal path. Any anybody can do anything in any technology. But I assume that's not the target. That's not the sweet spot for jam. So the sweet spot for jam is something where what I'm rendering tends to be the same for everybody who asked for that page. Is that approximately right?
Colby Fayock 13:39
I mean, I think that's where you're probably gonna see the most value. Because if you're able to serve that static site very quickly for everybody if it's not going to be special. Now, of course, like there's a lot of good value to that. I still think, though, that saying, like, kind of turning it off for the dynamic aspects isn't the right way to look at it, though. Things like a, an sp a, like you were talking about before a single page application. You know, that's kind of looking at like the React world where you're still bringing in these applications that have complete dynamic aspects to it. It's just that underlying underlying requests from the storage, where you're serving it from that has that static nature to it, where it's not being rendered on the server, it's coming from storage statically, where then inside the browser, it may become dynamic.
Dan Wahlin 14:28
You're basically shifting the functionality to pay the server's literally just gonna dump it to the browser, but then the browser can take over and do whatever you want. Is that accurate to what you just said?
Colby Fayock 14:39
Yeah, yeah. Because at that point, you're you have react or whatever your front end framework of choices, that's gonna hydrate the application. And then from that point, you can do whatever you want.
Dan Wahlin 14:50
So really, the if you look at the, you know, we have all these speed measurements we can do for time to first pixel time to this time to that instead I was like, four scenarios where you absolutely need. And I can think of many, especially mobile, where you need that super fast, you know, load time paint time, whatever you want to call it. That's what this is designed for. Would that be accurate?
Colby Fayock 15:14
Yeah, no, I think that's, you know, right on it. Because if you look at ecommerce, for example, like we were talking about before, now, that definitely has the dynamic aspects to it. But those dynamic aspects aren't those critical pieces, where if you get that in front of a person, you know, as fast as possible, that's gonna correlate to your conversion rate. So if you're getting that first request very quick, the person can see that and understand it, and then get tuned in to those dynamic aspects, they're going to be able to understand what the product is, and then go ahead and purchase it once that kicks in.
Ward Bell 15:46
What's the jam stack, and what I've heard of is server side rendering of it, which has the same goal of making the first page load of the first request to render really quickly,
John Papa 15:57
and what can you have server side rendering without a jam stack and vice versa.
Colby Fayock 16:02
So it's funny because that line is kind of, we're coming back around that circle, again, where that line is getting blurred, particularly by next j, s, and Marcel. But the traditional difference between that is that the, the rendering that you might typically see inside of a server side rendered request would be happening at compile time. So when you build the site, it goes through and compiles all those HTML files, that gets served to the browser, and then it hydrates as opposed to server side rendering, where on the server that request, that's what renders out that page and gets served to the browser, and then you might still hydrate it if it needs more dynamic values.
Dan Wahlin 16:38
That makes sense. Yeah. So basically, if if your goal is to have just pure HTML, and maybe some JavaScript served directly, in other words, no intermediary, such as node or PHP or dotnet, or something like that, the jam stack would fit that well. What are your you know? Because now the discussion would be okay, you have this compile step you keep mentioning, right? And to do that, by hand, I suspect would be a little challenging. So what are your What do you lean towards there? So I know you've mentioned react, but obviously, there's a little more to it than just react.
Colby Fayock 17:13
Yeah. So that's kind of where it comes a little bit back full circle, because it really depends on the problem you're trying to solve, where kind of before I was talking about e commerce where if you have 10 products, the compile time is going to be short enough where maybe you can wait for a deploy anytime you make a change. But if you have 1000s of products, that might take too long, and you need something more dynamic where server side rendering might come in. But so let's take this another step further. Next, j, s and ourselves. So now they have kind of an inner Mayor muttering Aries, can't say that word, a middle step, where it's kind of a hybrid between the two, where what they'll do is they'll kind of provide a caching mechanism, like you might traditionally see in front of a typical server full solution where they'll serve that page statically, but they're also giving you an invalidation time where once you set that the person, if it's invalid, the person who first hits that page will get it served statically. But in the background, they're going to refresh the page so that the next person gets the new. So that's very similar to traditional CDN caching mechanisms that you'll see. But it's kind of bridging that gap between the two solutions. You know, again, it's kind of coming back full circle with all that. But I think the benefit at that point is you're still able to bake yourself into that the React framework, like something like next year, yes, where you don't have to think about those things. And you can have all of your mechanisms and data fetching, kind of built in together.
John Papa 18:40
But somebody needs to know what the jam stack is to build jam stack. I mean, I keep coming back to the words and the terms. And let me let me quit ask this question. By the way, I've been building apps with Angular view, spelt, react, etc. For years, what is new and different that I need? Not should but need to know about this platform that would really grab someone's attention. If you have like that 32nd elevator pitch, what, what would make me or somebody else one of our listeners to really gravitate to it.
Colby Fayock 19:12
So if I'm going to give an elevator elevator pitch, I might say something providing the dynamic aspects of the web with the benefits of a static website or something like that. But I think they're really, you know, there really isn't too much on top of what you were kind of getting at. Because what it is, is really a mechanism that we can have a different discussion rather than somebody dwelling upon the static nature of it. So yes, we are serving static files with a jam stack site. But that doesn't mean that the page can't be dynamic.
John Papa 19:38
So I guess we're I'm coming back. And I appreciate your explanation on this is that it's really not as hard as you make a lot of these things out to be it sounds mean, the jam stack, we come up with these new words all the time for our technology in the industry. And sometimes it's like, what the heck is that thing and how do I use it? It sounds like it's basically the same old apps you've been building. It's just now you can add some additional features are take some additional benefits using some of the tools like natla phi, oversell as your static web apps, etc. Is that close? I
Colby Fayock 20:07
think so. And I think it also, it's able to leverage the browser and some like native features that you get out of the box with the browser, rather than relying on a lot of the server to do some of those things. So with react, for example, it feels really good to build applications in this manner with react because of the dynamic nature of react inside of the browser, where it kind of next JS kind of builds on top of that idea. And again, you don't have to think about those kind of things. So as another example, react, just kind of started talking about where they're going to have server, not server side rendering, but server components, where you'll you might have components that don't necessarily need to ship a lot of JavaScript with it into the browser. But a framework like next year, yes, might handle that abstraction for you. So you don't have to think about it. All you know, is you're developing that application that reacts. And that's going to decide what you need, what it needs to be static and dynamic to provide the best value to the person visiting your site. if,
Ward Bell 21:04
if, if I'm sorry, if I've got an app, or I'm thinking about building an app, do I have to think I want to make this jammy right out of the gate? Or can I retrofit? How much you know? How pack? How painful? Is it to retrofit an app, which I suddenly discovered should have? Because I'm worried about load time? You know, the jet, you know, do I load the jam stack on later? Or do I have to architect for jam right from the, from the get?
Colby Fayock 21:32
Yeah, so I think you know, that's tricky. So I'll give you an example. So when I worked with thankee, we actually kind of started shifting down this idea, because traditionally, it was a pearl house, where the entire website was Perl. And you know, all the API's were Perl based server side and such. But we started to cache everything with fastly. So we tried to cache as hard as we could with that, so that we can provide ultimately a fast experience. Now, when we were trying to rebuild the checkout for that application, we decided that we wanted to serve that page statically, and then load in the experience with JavaScript and API's. So that's why I bring that up is the transition was a little tricky, because it was something that the developers weren't really used to us kind of asking for. At that point, they didn't really have REST API, REST endpoints. So we had to kind of get them in that mindset of what we were trying to do, and try to establish that. But it also really provided a better experience for the people visiting the application. Because we can provide all those dynamic aspects right inside of the browser, and have a little bit more wiggle room for what we were trying to do.
Ward Bell 22:36
Let me refine my quest, but we're fine. Because we as soon as you started with Perl, I knew we were you know, like nothing from Perl is ever going to be, let's
Dan Wahlin 22:44
suppose is my first language. My first language? Yeah, well, I had a good first I could have said COBOL. Yeah. I don't recommend first language. But anyway, go ahead.
Ward Bell 22:56
You know, you know, if you use one of the modern web, so called Spa Tech style spa technologies, and I built something like that. And now I say, oops, you know, I this needs, this needs to be jammy. And I'm turning it into a is that transition, you know, crazy town? Or? Or can I say, all right, yeah, there's a cost of doing anything, but but, you know, going from a modern, modern designs spy app with with a web API's, and you know, underneath it, maybe restful API's? That's, that's something you can do, you can do that, when you need it, or no, you really should architect this for jam right from the start, which is, which is the there's no definitive answer. But give me a sense of that contrast.
Colby Fayock 23:51
Yeah, no, I think that you would be in a decent position. So just as an example, if it is built on react, or Angular or you know, your, your favorite framework, like at that point, you're already kind of halfway there. The the biggest issue that you're gonna see is if you try to take that and compile it on node, which is where it happens to build those static pages, it might be trying to use browser API's out of the box that aren't available. And that's going to be where you get caught up. Now, if you're not using any of those browser API's in a way that happens on that first render, you know, it might work perfectly for you. Just as an example. I was doing mapping for a long time with leaflet not sure if you're familiar with leaflet, but it relies on the window in order to to work. So we had to figure out a way to prevent leaflet from even getting loaded when it was getting compiled. which turned out it wasn't too bad because we were able to hook into the Webpack system to do that. But, you know, those are the kind of things that you need to consider. Otherwise, it'll just simply break and it won't compile.
Ward Bell 24:57
Yes. And that's also a constraint for anybody. imagining doing server server side rendering, you have that same problem.
John Papa 25:04
So we restate the problem, I'm not entirely following what the actual problem was there.
Ward Bell 25:11
Go for it. Colby.
Colby Fayock 25:12
My problem where so the so the question, though was taking single page applications, can you kind of just make them jammy? Right? And the idea is, can you make them statically? generated? Right? That's that right. So
John Papa 25:26
I heard you say, you can take an Angular and react app that you have, you're halfway there. But then you said something about the browser API's? I'm trying to follow where that came in?
Colby Fayock 25:35
Sure. So the issue is, if you want to take that and render those first page experiences inside of node, you're not going to have access to the same browser API's that you might have in node. So if you're trying to learn ...
John Papa 25:48
Let's stop there. So who would be put who would be, let's say, node your chosen technology with react? Who would be trying to build the app in Node? Or why would I be doing that, as opposed to outside of jamstack? Well, that's the people they are.
Colby Fayock 26:06
That's the common runtime that's used for compiling applications. So like, next JS Gatsby, they'll run those, they'll run the React code on inside of node, we're getting
John Papa 26:19
so you're specifically talking about server side generated applications, not just pure react without those,
Colby Fayock 26:26
but also at compile time. So to bring them to the, like, the jam stack philosophy is being run on. So it depends on if it's server side, or if it's at compile time. So at compile time is where you're going to deliver that rendered page from HTML, as opposed to server side, where that's gonna, that rendering is gonna happen on the server. So let's go back to a basic create react app
John Papa 26:46
app, I just said app app. That's weird. So we have a basic react react app, web app, without any this gem stack or server side rendering. And what normally happens is they build it somewhere with node with NPM, run, build, right? generates the assets that are needed for that app. And then I host that somewhere, I can actually host that up on storage, but wanted to s3, Amazon wherever, versatile netlify and Azure, then there's a compilation process in the browser still, or a translation process, whatever we want to call when it gets to the browser browser has to look through that JavaScript and other assets to figure out how do I then take that react dish code and kind of show it right. Am I right so far on that old style process?
Colby Fayock 27:34
Yeah. And I think the biggest difference there is when you serve that HTML page that create react, produces, it's really giving you that div that has the ID on it that you're mounting on. And that all happens in the browser, as opposed to that div getting filled out at compile time with all the code from that first, React render.
John Papa 27:54
And when you say the second scenario at compile time, you're talking more about doing that compilation process on a server somewhere?
Colby Fayock 28:02
Yeah, but then you would store the HTML of that resulting
Dan Wahlin 28:07
component, a CI CD type process, right? I would assume,
John Papa 28:10
right? Yeah, genocide, right. And that's what I'm trying to get. The difference here is, it's where is, I think we can all agree that most of these modern web technologies have really two steps, I'm going to take out the words build and compile in this sentence as best I can. The first step is take the thing that you designed and developed, let's say it's react, and then run a command on it, like NPM, run build, that actually puts all the assets together into bundles. Step one. And then the second step, often, not every modern web technology has this, but most of them do, is once it gets to the browser, it's supposed to be an HTML form. Right? It's got to be HTML, CSS, and JavaScript. So the browser's can all just deal with it. Often, there's some in between. And I think that's what you're referring to, is that compile step? Is there something that has to happen to make that actually end up being HTML? Is that what you're getting and getting that?
Colby Fayock 29:07
Yeah, and at that point, it's really just providing performance benefits and things that are going to be a better experience for the person. Because you know, at the end of the day, when you serve that create react app page to the browser, you're probably going to end up with a somewhat similar solution. But when you do it with a static site generator, you know, or like next JS or Gatsby, you're going to render out all those pages to HTML. So that way, that first HTML doesn't include just as mol shell the page, it includes everything the person wants to see what that first request. And that's why you're coming back to next j. s and Gatsby in with react or nuxt with view and so on and so forth. Exactly. Yeah. And I think there's a lot of
Ward Bell 29:52
them, sorry, the hurdle you were alluding to back before was if that first rendering rook in order to make that First rendering, it requires calls to browser API's that do not exist on the server side, and there are plenty of them on the window object, then you would, then you would fall down. Because it couldn't do that pre rendering before it's shipped over the wire. And that is a classic problem for SS first for server side rendering as well. So you just you have to be aware of that I, right off the top of the head, I'm trying to come up with an example of where I would trip on that one. But I know, I know, there are plenty of examples.
Colby Fayock 30:30
So even some something simple like if you want to use the window to grab a node, oh, yeah, because the window won't be available. If you want to grab a node and do something that you might not be able to do specifically in react. Now, of course, we want to try to do everything the React way, but we can't, you wouldn't have access to the window, and that would break. Whereas if you put that inside maybe a use effect hook or with the older API, it might be component did mount. At that point, you're running inside of the browser, and you have access to it so you can make those processes.
John Papa 31:02
Speaking of breaking windows, it's time to break into another spot for a word from our sponsors.
Ward Bell 31:06
So john, one of the things I like about AG-Grid, which is a data grid component for the kind of complex grid scenarios that we encounter all the time in enterprise apps. One of the things I really like about it is that it works for a variety of frameworks, angular and react viewer, are just vanilla j. s,Does that ring a bell for you?
John Papa 31:28
No, it really does. There's all these different companies that I work with, where they have no choice, but to use a lot of these different tools, they have different teams working on them. So being able to port their code or share that code, that technical investment they have is really important to them.
Ward Bell 31:43
So it's important to us, I do believe we're a consulting company. And I, you know, we never know what our clients going to want to use Angular react view, but they're all going to need a grid. And it's great to be able to reach for the one grid that works everywhere, ag grid,
John Papa 31:56
you know, at any size company, too, because you could have these teams that maybe they only use one framework, but eventually they're going to switch to another one and be able to take that investment again and use it reuse it is really nice.
Ward Bell 32:07
So if multi framework grid makes sense to you, you should certainly go over there. And check out AG Grid at ag dash grid.com. And tell him Ward and John sent you.
John Papa 32:21
And we're back and Colby, you answer a lot of these questions really well. And I know we've been kind of picking at the seams and pulling threads and trying to figure out what the heck is this thing? But I'd like it if you could kind of just tell me what is it like using it? What's this developer experience for the jam stack.
Colby Fayock 32:39
So one of the things that's kind of really great about the jam stack is the tooling that's kind of coming out of it. So I don't know if it's because there's so much money behind it or what it is, but there's just a lot of great focus to the developer experience. So right now, for instance, I'm using next year, yes. And with a simple command, you can get an application up and running, if you have node installed on your computer, and you immediately have access to a react application that gets building and running. Like I kind of mentioned before, using nullify oversell, you can host it on GitHub and push it up with an integration right to those sites. And if you're a person, an individual or a small business that just wants to get a presence on the web, that's really powerful, because it's easy. And it's also cheap. The there's a lot of generous free tiers out there to get people kind of moving on this kind of philosophy. And it's, it's a great way to kind of get your name out there or your small business out there without having to worry about managing servers and all the experiences that go with that. So,
Ward Bell 33:41
alright, you got me intrigued. But I know nothing about this, which is obvious. But I think hey, you know, I think I want I need this. What's my learning path?
Colby Fayock 33:53
Sure. So I have a book that is a good look called jam stack handbook that you can check out but there's a ton of resources online. Jam stack.org, I believe is a good resource to kind of get your feet wet with kind of just learning more about the philosophies and stuff. Right now, if you're in the React world, you know, it depends on the framework that you're interested in. But in the React world, to the bigger ones are next js and Gatsby next year, yes, you might need to do a little bit more manual work with things like the data layer and kind of the API's using it. But Gatsby, on the other hand, has a huge plugin ecosystem where you can really get up and running with some powerful solutions without having to do a ton of actual code. You know, that could be a good or a bad thing, depending on how you're looking at it. But it's really powerful for people who want to get that web presence.
Dan Wahlin 34:42
So if I'm a, you know, pretty experienced react developer, it sounds like you know, if I'm used to create react app, for example, and I want to move to next j s, pretty easy experience overall, but to get started, I mean, I can apply most of my skills.
Colby Fayock 34:57
Absolutely. Because as soon as you run that So the they have a create react are so similar to create react app, they have create next app. And at that point, you're spinning up a new template with kind of essentially what you have a create react app. But next year, yes. And then at that point, you can layer in your data fetching API's that they ship with. They have multiple options between static, grabbing that statically or on the server, you know, that depends on where you're hosting it for the server side aspect of it, because it needs to support it, of course. But at that point, you're really just developing a react application with these API's that are helping you out in the background, where things like creating a new page, you create a new file, and that file name represents that new route.
John Papa 35:42
Colby, thank you so much for coming on the show today to talk about jam, stack and react. And next j s as well. We've had some folks talk about these topics, I think by themselves a lot, you know, react, obviously, and next j s, folks in versal. But I really appreciate how you kind of put the pieces together for us. So thanks for doing that. No problem. We'd like to end our show with our final thoughts. For our listeners, this could be just a thought on topic or something else that's happening in the world that we want to let people know about. And it really could be just about anything. So I'm going to start with our co host here. Dan wall lien, what's your final thought for folks,
Dan Wahlin 36:19
my final thought today is going to be something I've been trying to do a lot more and that is to mix it up. And what I mean by that is we're all still dealing with stuff, I guess you could say going on pretty much around the world still, at the time we're filming or recording this. And so one of the things for me that gets a little repetitions with work is meetings. And you know, some of the meetings, I have to be directly involved like a podcast, for example. But others I'm there mostly to listen and just kind of make sure I'm up to speed on what's going on. So I've been I've mentioned a couple of the things I do on Twitter recently. But one of the things I like to do is walking meetings, which is a meeting where I know I don't have to be on video or something. But I do need to listen. So I'll just grab my phone, I'm usually on teams. And so I'll grab my phone, I'll go out for a walk in media, or I'll just go outside in the backyard, you know if you have that. So anyway, I guess I just wrap up by saying, I think we get so much into the routine these days that we don't think about hey, you know, there might be some other ways I can mix this up, make it a little more fun.
John Papa 37:24
Thanks, Dan. That's a really good tip. And my tip, one final thought for today is I've been doing a lot of running this last year and the hardest part for me has been to find shoes that actually don't hurt my feet. I've run now I'm gonna I'm gonna put a tip out there. The ones I found that I like are called on o n running shoes. I dropped a link in there. I really liked the shoes and I found good ones for running for hiking. They have waterproof ones now and just for walking around as well. But the key is find a pair of shoes that fits and feels right for you because everybody's feet and body are different. So don't chintz out on a good pair of running shoes. I just make that my final thought. Word what's your final thought?
Ward Bell 38:08
He's You guys are so profound. I you know, it's like, a part of me really wants to go there. Because because we're in a time where we're sort of rethinking a lot of things about particularly how we meet each other in the world and how we restore a kind of conversational approach to the world rather than armwrestling. So I guess I'll just vote for that. I'm really looking forward to having conversations again. And of course, I'm really looking forward to being able to see people in person again.
John Papa 38:44
Yeah, it'd be nice that we're doing these video calls to actually know that people aren't just wearing a T shirt, you know, above what they can actually see inside of here, right? You can wear like a blazer and a shirt. I saw a guy in the news the other day, and he's wearing like a blazer and a tie and everything. And the woman's like you look good today. And the guy goes, that's great. But I'm actually wearing, you know, Hawaiian shorts. And Colby, what's your final talk for our listeners today?
Colby Fayock 39:10
Yes, I was listening to the technical debt episode. And it got me thinking, you know, as developers, we have a lot of powerful tools, tools in our belt where we can automate so much of our process where we don't have to think about some of the things and tools like GitHub actions specifically has been something I've been enjoying a lot lately, where whether it's running, simply running tests or deploying some kind of custom solution, being able to automate those things are ways that we don't have to think about those technical aspects that you're even if it's running prettier on a pre commit hook so that you're not having those conversations in code reviews. But automating as much as he can can save you time and energy.
John Papa 39:50
great tips. And yeah, just some links into there for the tips and for the final thoughts and for the show notes. So,
Colby Fayock 39:56
Colby, thanks
John Papa 39:56
again for coming on and sharing all this about jam stack and thank you All of our listeners for listening to get another week of web rush. We'll hear from you and you'll hear from us on every Thursday morning.
Transcribed by https://otter.ai