Dan kicks the show off by asking our guest Sean C. Davis to define for us what doesn't fall under JAMstack. Sean explains what isn't JAMstack and then dives into what's changed over the last year or so that brings us to the tools and approaches that hybridize the server end of things to bring more server side to the JAMstack.

So, JAMstack lifts away from a monolithic backend to provide an independent front-end with a supporting set of back-end tools rather than a back-end with supporting front-end tools. This episodes dives into the implications of this approach as a reaction to the more traditional monolith.

Special Guest: Sean C Davis.

Sponsored By:

AJ_O’NEAL: Well, hello, hello, and welcome back to JavaScript Jabber. On today's panel, we have myself, AJ O'Neill. We've got Dan Shapir. 

DAN_SHAPPIR: Hey, hey, from Tel Aviv. 

AJ_O’NEAL: And special guest, Sean C. Davis. Tonight, today, this morning, whatever it is, we're going to be talking about Jamstack and we're going to start with what it isn't.

DAN_SHAPPIR: Yeah, that's actually the question that I wanted to ask because it kind of, you know, we've had several episodes discussing jamstack in the past. And one of the first questions that we ask is what is jamstack? And we get a, usually a pretty good answer, but the problem that I kind of have with this answer is that almost anything could be defined as being jamstack, almost any website because you know, what is jamstack? It's, it's markup. Well, every HTML website is markup. It's JavaScript. I mean, you know, JavaScript is pretty ubiquitous. Certainly to people who are on this podcast, APIs, almost every website these days uses APIs. So is every website jamstack? Maybe it is. So my question is, when is something not jamstack? When, when would you look at the website and say this isn't jamstack this is something else and you know maybe this way we'll get a better understanding of what jamstack actually is by understanding what it isn't. 

 

Did you work your tail off to get that senior developer gig just to realize that senior dev doesn't actually mean dream job? I've been there too. My first senior developer job was at a place where all of our triumphs were the bosses and all of the failures were ours. The second one was a great place to continue to learn and grow, only for it to go under due to poor management. And now I get job offers from great places to work all the time. Not only that, but the last job interview I actually sat in was a discussion about how much my podcast had helped the people interviewing me. If you're looking for a way to get into your dream job, then join our Dev Heroes Accelerator that makes you attractive to your dream employer, but you'll be able to ask them for top dollar as well. Check it out at devherosexcelerator.com. 

 

SEAN_DAVIS: Yeah, well, thanks for having me guys. I really like this question. It's interesting to me, particularly because I would probably have answered it completely different a year and a half, two years ago or so, because I feel like the landscape of what is Jamstack and really the definition of what is Jamstack has changed largely in 2020. And so if I give you... I'll kind of give you the old answer first because I think I started getting more heavily involved probably around 2017 or so when it was a newish concept at that point. But not also, not really because the Jamstack doesn't really redefine anything. It takes practices that we've had and patterns we've followed for more than two decades and just kind of put them together in a new way. So I think if I were to back up a couple years ago and answer that question, what isn't the Jamstack, I would probably say it's not something that is running on... It's not running on a server and if anything's dynamic, we're grabbing that data or that interactivity is all happening on the client side of things. But what's interesting is that over the last year, two years or so, we've seen this explosion of these more, almost like these hybrid type of solutions with, in particular, I think Next.js has been a huge player in kind of redefining the way we think about what the Jamstack is today and so now, the way I would answer that question is really, it's a little bit different because I think the Jamstack, like you said, it can be a lot of different things. And so what isn't it today? Really, to me, it's not a monolithic application. It's not your WordPress from 10 years ago or your Ruby on Rails app where you have this one framework and you deploy it. And it's everything's there. Your front end's there, your back end's there. It's all, it's all operating on the same server. You're managing the whole thing. I think what it is more today is about this distribution of systems and services. And, and the Jamstack is it's, it's almost like every project is its own unique stack. And that is the Jamstack. So I can take a little bit. Oh, I should say I could take, I can take the things that, and the services and the tools that I prefer to work with, or that will solve or serve the project best. And I can piece those things together. And so that's kind of the way I think about it today. And it almost, as a result, it becomes harder to define because the definition and the breadth that it covers continues to grow.

DAN_SHAPPIR: I think it's interesting. Oh, sorry, AJ. I just wanted to kind of point out that I like the fact that you mentioned WordPress because it kind of seems to me that in a lot of ways, the Jamstack, by the way, I'm just used to saying gem stack, but I understand that it's supposed to be called the Jamstack. It seems to me kind of a reaction to WordPress that people were kind of, you know, a lot of people love WordPress justifiably so, but I think that there was also kind of a reaction against some of the things that went along with WordPress, that sometimes it was difficult to build performant websites with it, especially large websites. Sometimes it was difficult to make websites that used it really sufficiently secure. So it kind of seems to me that Jamstack was kind of like a collection of practices that were like the opposite to an extent of the way that WordPress kind of did things. And that was kind of initially at least codified into what the Jamstack is. Would you agree with that? 

SEAN_DAVIS: Yeah, I think so. And I think that's why it's changed so much over the last few years, because it feels like, yeah, it started as, Hey, we're going to, we're going to, we're going to do everything the opposite way. So WordPress is all together while we're, we're breaking it all apart. WordPress is dynamic in real time, well, we, we don't necessarily need to do that. We can, we can have a powerful build system, but then that build system can develop a few up to thousands of individual HTML files, and then we put those up on a CDN. And I thought one of the things that really appealed to me early on were a lot of the big benefits and the, and the talking points around what is the jam stack. I think you mentioned performance. Like it's, they're just static files. So they're probably going to, they're going to be a little bit faster because we don't have to interact with the database. We're just reading an HTML file. It's a little bit more secure because our content editors can write that. They can still write all the content in whatever CMS they choose, but then the, the visitors to the site don't have any idea or any, any way of really knowing where that content is coming from, because it's already been built. And it's, it's static. And then I think one thing that I talked about and kind of swayed me early on, but I feel like we don't necessarily talk about as much today is that there's this concept of, or maybe what I should say is that the by-product of the Jam Stack is you get to bring the best, the best tool for the job. You choose the thing either that you like the most or that you think will solve your problem the best. And that can mean different, it can mean different vendors, different toolkits, different languages for individual solutions and services within your application. Whereas if I'm a, and at the time I was working for an agency. And so the struggle in the agency world was, Hey, if we're going to do all WordPress sites, that's great. But now we've just limited ourselves to, we have to go find PHP developers or we're a Ruby on Rails shop. Now we got to make sure we can find people who are interested in working on and with Braille. And it's interesting that the Jamstack has, in one way, it's pushed us toward more, it seems like JavaScript is the popular language within this methodology, but it doesn't have to be the only one we're using. There are plenty of static site generators and other tools written in other languages that you could employ if that's your preference. 

AJ_O’NEAL: So I would say to me, the opposite of Jamstack is WordPress, as we said. It is because I think of these as you're starting with a blog and you're adding functionality to it, like comments, like search, et cetera. Would it be fair to say Jamstack is not something for web applications? For example, Gmail. Gmail would not be Jamstack. 

SEAN_DAVIS: I want to say...Yes, that's fair. Or like if you're going to 

AJ_O’NEAL: very concept of what Gmail is, is that there is no static content other than no, there's no static content on Gmail. I don't, I don't think there's a single element on the Gmail site that is static content aside from maybe the Gmail label. The left hand bar is dynamic. The load screen is dynamic. The search bar is dynamic. The widgets bar on the right is dynamic. The content area is dynamic. I don't think there's anything about this possibly feasibly say is Jamstack-ish. 

SEAN_DAVIS: Yeah. 

DAN_SHAPPIR: On the other hand, oh, sorry, go for it. 

SEAN_DAVIS: Yeah, I was gonna say, you're right. None of it's static. However, if you consider the Jamstack to be this methodology and model of having distributed services, well, I mean, you could build an email service that is, hey, I've got a React front end and I'm using some database as a server like Fauna or Hasura or, you know, something in that world. And then I've just got this series of serverless functions that I've employed that they perform my server-side tasks. Is that seems like that kind of fits the definition of Jamstack. And maybe that gives you what the power you need to run an email client. 

AJ_O’NEAL: I'm going to push back on that one. 

DAN_SHAPPIR: Potentially. Yeah. Me too, kind of, because if you go down that route and you know, if you just look at the definition of the thing, then you're potentially correct. But that would literally put every client-side rendered application as a gem stack application. And I don't think that that's the case. From my perspective, if the solution does not involve at least some degree of server-side generation of static content and not the same static content for all pages, I mean, not effectively a blank page everywhere then it's not Jamstack. I think that from my perspective, some static site generation is a must. Now, you mentioned before that the tools like Next, like others, they also support SSR. So theoretically, you could actually build a solution with Next.js that doesn't involve any static content, HTML generation. But then from my perspective, you've used a Jamstack capable tool to build the site that isn't actually Jamstack. That would be my perspective. 

SEAN_DAVIS: Yeah, that's, I think it's so interesting. And that's why I find this conversation fascinating because that's a, I feel like that is a totally fair point. Like, okay, so the one thing you got to have for it to be a Jamstack site is something has to be generated statically. But that's to say that I can. So I guess, I guess what almost what you're implying here is that you can, you could use the same set of tools to build two different apps. So I could use next, I could use some serverless functions. I could use a hosted database and depending on the particular, the outcome that I create, it may or may not be a Jamstack site. Is that fair to say kind of what you're getting at? 

DAN_SHAPPIR: I think so. I think that. The gem stack, rather than being necessarily so much technology, from my perspective, it's more of an approach. It's an approach that's enabled by technology. I mean, obviously, it's about running JavaScript on the browser side. So having the ability to run JavaScript on the client side is, you know, as a technology is a must for gem stack to exist. But gem stacking, from my perspective, is more of an approach. And sometimes when you're talking about approaches, then definitions tend to be fuzzy because a tool can support multiple approaches. It's a legitimate thing to do. And then you could use that tool to build something with a gem stack approach, or you could use it to build something else, or you could use it to build some sort of a hybrid solution. So that would be my take on it in that regard. 

SEAN_DAVIS: Yeah. I think that's it's really interesting because it's, I don't know why, but I keep coming back to Next. I feel like without Next, there's a little bit of a clearer definition because you, it's almost like every tool you piece together does its one thing and does that thing fairly well. And now we throw Next into the mix, which is a great and super powerful tool. And then pair that with Vercell or now Netlify is new next on Netlify support. And now we have this framework that feels like it's a, it's a full stack framework and there, and there are others popping up like, I think that's what Redwood JS does and, and then there's Blitz, which I believe is also built on next, and now it seems like we've got full stack frameworks. Popping up built on top of what we're originally static site generators. So where's the line? Are these still, do they still fall within the Jamstack space or is it more about how we apply them and what comes out of them that determines whether or not we're still working within the Jamstack ecosystem? 

DAN_SHAPPIR: So you actually posted really nice article a while back. I'll actually put a link here in the comments so that it will show up in our show notes about comparing the build times, or the performance, you might say, of static site generators, although in this case performance doesn't mean what the visitor experiences, but rather what the developer experiences as they deploy or build the site. And you used interesting terminology here, because you were comparing six static site generators but you kind of split them into two groups. You called one the basic generators, which included 11T, Hugo and Jackal. And then you had the advanced generators, which included Gatsby, Next, and Nuxt. So I think that kind of highlights the fact that you could have multiple approaches within that same Jamstack world. And then again, it's being in approach rather than a specific technology. It's kind of, I think that's the whole point. And then again, you could mix it with other technologies when they're appropriate. 

SEAN_DAVIS: That's funny you bring that article up as well, because that was one. So I was talking to, it got published to CSS Tricks and I was talking to Chris Coyer about it. It was like, I've got this idea. I think there's a spot for it. We haven't really, I haven't found this comprehensive benchmark of build times for some of these popular static site generators. So let's put something like that together. And, and then it became a whole thing that kind of getting into the weeds of like, okay, well, how do we measuring it is one thing, but then how do we talk about what we're measuring and as, as we analyze that data, and then I wanted to give each of the creators or maintainers of those six static site generators that we chose to start with some opportunity to, to comment before I published it and I got into a conversation with Guillermo, the founder CEO of Next and Vercell. And he's the one who brought up that nuance between maybe there are two different types of generators that you're studying here because there are the ones like the Jekyll 11D Hugo that are really more geared toward. I'm going to you give me a bunch of data and some templates and some assets, and then I'm going to give you static files and that's what you're deploying. And then there are these other ones, these fancy static site generators, most of which are built on some other framework, like Next and Gatsby being built on React, where they're kind of giving you this whole, this whole ecosystem, tons of, tons of extra features, big, vast plugin library and I know some of the simpler static site generators have plugins as well. But then, and so as a result, those build times tend to take a little bit longer, which was, that was the nuance of like, this isn't just about build times because it's more about this, the arming developers and folks who are making decisions with the, the power to say or to see, hey, these builds and these tools take a little bit longer, but then to think about why do they take longer? Because, which often is because it's giving you more stuff, more tools as a developer, and then often more capabilities once the thing is built as well. 

DAN_SHAPPIR: I think that the build-dime discussion is really important in the context of the penetration of Jamstack and also the emerge the fact that hybrid solutions have emerged. Because if you look at Gemstack originally as being the sort of quote unquote un-WordPress, as we kind of initially defined it, then most WordPress sites are not extremely huge. They have potentially hundreds of pages, maybe thousands of pages, but usually not more than that. And then if you're talking about statically generating a couple of hundred pages, and you're going to do build, you know, part of the definition of Jamstack is that you're going to build your entire website each and every time so that it has the same version across all the pages. Well, we could live with that. But then if you start trying to take Jamstack to other types of websites, let's say a newspaper website. Then instead of talking about hundreds of thousands, you're potentially talking about tens of thousands, hundreds of thousands, maybe even more pages. And then it becomes kind of impractical to potentially to statically generate everything. And then you're starting to think about various types of hybrid approaches. 

AJ_O’NEAL: You could statically generate only the things that are changing, which I guess if you're changing your nav bar, that could be everything, but still, if it's only a couple hundred thousand, what's it going to take? Uh, Sean, 30 seconds. You did that Hugo test. 

SEAN_DAVIS: Yeah. Hugo was, uh, Hugo was incredibly fast. I don't, I don't, I don't recall what the numbers are, but it just didn't, I think I got up to either stopped at 64,000 or 128 because I started having issues with, with some of the generators and we couldn't let the thing go on for hours, but yeah, it was like. Nah, no, no problem for Hugo. Just flying through it. 

AJ_O’NEAL: Do you remember roughly what was the number of seconds that it would take for something in that range of over 25,000? I'm gonna see if I can bring up your article. 

SEAN_DAVIS: Yeah. 

DAN_SHAPPIR: I don't recall that the article had the actual exact numbers, but I remember the graphs, 

AJ_O’NEAL: but I got too many tabs open. I can't find it.

DAN_SHAPPIR: the everyday type of a problem of a web developer, too many tabs. Aren't you using the grouping feature now in Chrome or whatever is your favorite Chromium browser? 

AJ_O’NEAL: I am not aware of the grouping feature yet. Let's see. 

SEAN_DAVIS: Okay, so I've got- 

AJ_O’NEAL: Add to new group. Yeah, I'll have to, ooh, this is gonna change my life, Dan. This was worth it right here. For anybody listening, this is what makes this episode worth it. Chrome and Brave add to group feature for tabs. You're welcome.

SEAN_DAVIS: Okay, so I'm we've kept this thing fairly up to date. I know there are a couple generators here who are behind on a few versions now. But my current numbers are the okay, the biggest it got was 64,000. And so little more context for folks who haven't read this is it was a baseline, super simple site. So there's no I tried to strip out any CSS and no, like, so no interactive JavaScript. And then every, and then, and then generated individual pages as markdown files with a, uh, front matter was just a title and then a couple paragraphs of body text. And so when I say 64,000, I'm saying there are 64,000 markdown files on disk that the static site generator is reading and then converting to pages during its build process. And for Hugo it looks like that's averaging somewhere in the ballpark of say 25 to 26 seconds, which was the fastest and then slowest of the six was Gatsby, which is 870 seconds. We do that. What's that? 

AJ_O’NEAL: Really that I would not have expected something built in node to be slow like that. Must be a lot of stuff. It's keeping in memory for indexing or something that it's, it's not doing efficiently because node and we don't worry about memory management. 

SEAN_DAVIS: Yeah. And I, I don't know exactly what it is. I know Gatsby's gotten some negative attention for that. And that's why, uh, we ordered in squared loop. Yeah, who knows? But that's why I was like, okay, so this conversation isn't all about, look at the, look at the chart and Hugo super fast and Gatsby super slow. So use Hugo and don't use Gatsby. Like there, no, there's a ton more, more nuance, but yeah, I don't know. It's not, it's not just react because the interesting thing is so 170 seconds is somewhere in the ballpark of 14, 15 minutes. Compare that to Next, which is also built on React, and that's running at 167 seconds, which is more like three minutes. So what's that, four, five times faster than Gatsby? So I think it's interesting. I don't know what one is doing over the other to give us that result. 

DAN_SHAPPIR: It could also be issues around the plugin and data flow architectures, for example. I would assume also that reading data from different sources could have a significant impact on the generation time. 

SEAN_DAVIS: I guess that could be true with the way that this next example was built. It's just using Node to read those files from disk. And then I think that maybe the gray matter library to parse the the front matter and body content. Whereas Gatsby it's all wrapped up in this, this fancy plugin architecture where you're actually going through, uh, I believe a graph QL server to, and it's still being processed with node, but I think there are a lot of more, lot, lots more bells and whistles that are happening during that process. 

DAN_SHAPPIR: Yeah. What I'm also trying to say is that in reality, this is like looking at, uh, at, uh, to an extent to a browser, browser performance that's doing, let's say doing a browser comparison between, I don't know, the performance of Chrome and Firefox and Safari and whatnot by looking at how fast they render about blank. It's like, I would assume that in different scenarios, like you said, involving stuff like getting data through GraphQL and stuff like that, that could potentially end up in really different results. But I agree that if you're looking at straight-on generation of static pages, from let's say simple database queries, that's probably a good indication of the type of performance that you're gonna get. 

SEAN_DAVIS: Yeah, I think that's fair. 

DAN_SHAPPIR: In that context though, and kind of going to AJ's comment before, suppose that I were to create an architectural solution where I don't generate all the pages in build time, I generate some pages on demand. That is the first time that a particular URL is hit. I check whether that resource was generated or not, and then generate it on the fly and deploy it as it's being generated. So first visitor pays a certain penalty, but repeat visitors get good performance. Would you call that Jamstack? 

SEAN_DAVIS: That piece, probably not. That feels more like... 

AJ_O’NEAL: What? That's like optimal Jamstack. Sorry, I cut you off. Go on your explanation. 

SEAN_DAVIS: Okay. I think that I feel like, yeah, the ideas, I don't know what that sounded to me. Like that sounded to me like more, more of these or the server side caching that I would, I had previously employed when, when building say rails applications. I, what I was thinking of here, and maybe this is what you're, you're getting at and, and misunderstanding a little bit, but from the Jamstack perspective, I think you'd want to be maybe even a little bit smarter than that so that you don't have to necessarily react to the user, but you can say, hey, I've got hundreds of thousands of pages and I use this content management system to manage all that content. And then I'm gonna build static files from there that you make a change to see you add some new article, edit an article and that that build process is holding on to its cache from previous builds, knows what changed and then only generates what it needs to generate and then still deploys all of those files out to a CDN so they're available statically so that in that case, your first visitor doesn't suffer at all. Everyone's still hitting that static file. It's a complicated pattern to achieve and I haven't been able to do it successfully, but I know it's something that folks are going after, especially as to try to get Jamstack sites to scale.

 

Have you ever wondered if you could be offering a faster, less buggy experience for your customers? I mean, let's face it, the only way you're going to know that is by actually running it on production. So go figure it out, right? You run it on production, but you need something plugged in so that you can find out where those issues are, where it's slowing down, where it's having bugs. You just, you need something like that there. And Raygun is awesome at this. They just added the performance monitoring, which is really slick. And it works like a breeze. I just, I love it. I love it. It's like, it's like you get the ray gun and you zap the bugs. It's anyway, definitely go check it out. It's going to save you a ton of time, a ton of money, a ton of sanity. I mean, let's face it, repping through logs is no fun and having people not able to tell you that it's too slow because they got sidetracked into Twitter is also not fun. So go check out ray gun. They're definitely going to help you out. There are thousands of customer centric, customer focused software companies who use Raygun every day to deliver great experiences for their customers. And if you go to Raygun and use our link, you can get a 14 day free trial. So you can go check that out at javascriptjabber.com slash Raygun. 

 

DAN_SHAPPIR: The reason that I brought it up, it's interesting. As some of our listeners may know, I work at Wix and Wix doesn't employ a native gemstack type of approach, but its architecture is, you might say, gemstack influenced and is progressively more so. So we actually do this type of deploy to CDN on demand. That is, when somebody publishes a website on Wix, it isn't automatically statically generated and deployed to CDNs. But the first time that a particular webpage is hit, if that page can be statically generated, then we statically generate it, and then we push it onto the CDNs. And the reason we do that, there are a couple of reasons. One just has to do with the scale and rate of change. Wix hosts hundreds of millions of websites, and new versions of them are published literally every second. So we couldn't, like if you look at the entirety of the Wix platform as you know as a one humongous website we could not deploy everything on every on every publish because there's literally a publish like every I don't know microsecond and we could not deploy all the pages because there are literally hundreds of millions of pages so and also there's a significant difference between the ratio of the visits of some of the pages. So there are webpages on Wix that get, you know, tens of thousands of visits a day, maybe more. And there are webpages on Wix that, you know, get hardly any visitors at all, because somebody just built their website on Wix and then forgot all about it and never ever tried to promote it or anything, and it's just there. So, but we are taking from the gemstack book the whole concept of when it is possible to statically generate the page because sometimes it's more feasible, sometimes it's not, but I won't go into the details because this is not an episode about Wix. But in those cases where it is, then we definitely do, when there's a request for that page, we definitely then statically generate the page and then push it onto the CDN so that for that page come from the CDNs and the CDNs are not invalidated until the content of the page actually needs to change. So there's certain benefit that's similar to that, to what you get from the gemstack, but there's also a certain difference. And like I said, we've been heavily influenced by the gemstack approach when architecting this type of a solution. 

SEAN_DAVIS: That's really, it's really interesting. And yeah, I've heard of similar patterns. I think, okay, so it's like we're performing the definition of the jamstack on the fly here as we peel back the layers. So one of the things we said was that you got to have some sort of static content on your site to be a jamstack site. So, okay, fair. Now the interesting thing that we're talking about is, okay, well, when you create that content, does it matter if you are proactively or reactively creating that content? proactively creating it, you've got this build process that looked at the content and, or some external factor that triggered the build and then preemptively built this static file, or are you reacting to some action by the user? And then assuming that if one, yeah, one person interacted with this page, content's changing all the time. So now I'm going to cache it until there's some reason to invalidate it. And I'm going to build that one particular page, but the end result is the same for future visitors. They're just accessing a CDN and a static site. So yeah, like 

AJ_O’NEAL: I would give this a litmus test though. Okay. So one of the things would be the design WordPress is designed interactive first and the caching was added on and the caching causes all sorts of problems. In a Jamstack site, caching should not cause problems for users. Meaning maybe they get a slightly older version of content that was updated five minutes ago or something, but it shouldn't, it shouldn't cause problems for users. So for example, going back to the blog, if every single time someone comments on a blog, you're re-rendering the site. That to me would not be Jamstack because you have created an interactive application that is building and caching as it's being interacted with as an interactive application. That would fall in the WordPress or Rails category to me. If you're using something like Disqus, maybe that you build on your own, that services comments on the blog as an addendum, as a widget, but the site itself is mostly static content, perhaps with optimizations. But the site itself is mostly static content and you're adding a widget on top of it that uses an API, that I would say would still remain Jamstack. So if you have interactive builds that are because of user actions, that's not Jamstack. If you are optimizing and partitioning how you build the site to make sure you're not overloading your service, I would not say that that precludes Jamstack. 

SEAN_DAVIS: And so in that...Do you think there's, is there something else baked into that definition where you say, are you saying the majority of the content on a page should be static? In other words, like, okay, 

AJ_O’NEAL: so the core value of the page should be static. Where, where we could go all the way to the edge on this would be stack overflow, stack overflow. When a post is first created, it's really hot for maybe a couple of hours, if you're lucky, and you get an answer within a couple of hours. But after two days, the post is cold. So if you, that would be this dividing line where if we were to consider Stack Overflow from a Jamstack perspective which I would love to see what this year's blog reveals because they always have interesting things about how they run the third most popular site in the world on a total of three servers in someone's bedroom. Actually, I think it's 28, but, and it's not in a bedroom. But still, Stack Overflow is the most optimized site on the internet, as far as I know. I don't think anybody services more users for cheaper cost per user than they do. But that would be like the dividing line where you could have maybe a hybrid approach. If you've got something where you know content's hot when it's fresh, but as soon as it cools, it's cold storage. It's highly unlikely for something to change. It's not interactive. But in the first couple of minutes or hours a Stack Overflow page could look like an instant messaging app almost, which is where I think it would, that would fail. 

DAN_SHAPPIR: I have another example, I think, like from a different type of a category where that line becomes interesting and goes exactly to your point about thinking, you know, what is cacheable and what isn't as part of the architecture, what, you know, the cacheable part being added on the front end by JavaScript that reaches out to backend APIs let's say you're on a serverless system, think about, for example, a store where you've got the product page. So in most cases, product pages are mostly kind of static. Most stores don't change their product that often that you cannot generate all the product pages statically. You might have an issue if you have a huge amount of different products. And I can give an example of that 200,000 products, then maybe that's a problem. But if you've got, I don't know, several hundreds up to several thousands of products, then that's not a problem. You can statically generate all your product pages. But you probably don't want to statically generate the number of items in stock, because that changes every time somebody buys a product. So what you might do in that case is say, okay, so the product page, the picture, the description the name of the product, et cetera, all of that stuff is going to be statically generated. But then I'm going to use client-side JavaScript to fill in the amount of products available in stock, maybe even do adjustments on prices, stuff like that, depending on locale, whatever. So that's the dynamic part that I would add in. And if I go again back to the WordPress type of an approach, because it was monolithic, like Sean initially said then all this information came together and kind of had to be generated dynamically because that would have been the only way to go. Whereas with the gem stack approach, you think about that thing, create the separation between the static and dynamic stuff, between the cacheable stuff and the stuff that you definitely don't want to cache. And that stuff that you don't want to cache, that stuff gets added on the front-end side. And that, to me, is the crux of what gem stack is about, really.

SEAN_DAVIS: Yeah, I really liked that. I think that that pattern is, it makes a lot of sense that, that the primary purpose of this page is content that isn't going to change. I can statically generate it. As you were given the product example, I immediately thought this, um, an example that I had, I had worked through at one point was a reality site and it was the same sort of thing, like the majority of this, we know, we know all the properties in this company's database. We've got all the images for the properties that we need. We can generate all the property, all the property pages. They don't, they don't change very much, but then whether they're maybe available or not, or if there are ratings or anything like that, that might change more quickly, these like really subtle pieces on the page. Those are the things that we're, we're changing in real-time when, when the, when the request happens, I think that's yeah, that makes, that makes a lot of sense to me.

DAN_SHAPPIR: In other words, if you're putting a real time clock on the top left hand corner of your website, that shouldn't be done on your server side. 

SEAN_DAVIS: Yep, that is true. 

DAN_SHAPPIR: We've been talking about Jamstack a lot, but I know that there are several other things that you're involved with, which I really wanted to bring up. And I'm not sure we even have time for all of them. So I'll mention the three. I have more things that I wanted to talk with you about Sean, and you decide which one you want to go with first. So you, you had a really nice blog post that I saw called three rules for keeping components organized, which I think is definitely a worth a discussion. But I know that you're also involved. First of all, the company that you work, you work at, which is Grouparoo. And there's also this thing, another thing that you're involved with, which is called unmute. So you pick which one of those three you want to talk about first. 

SEAN_DAVIS: Well, maybe we can, why don't we start with, with Grupuru. It feels like kind of an interesting segment from where we're, what we're talking about here since we've, we've, we spent a lot of time talking about kind of like data and these, these backend architectures and, and, and like disparate services, I feel like it fits in kind of well. 

DAN_SHAPPIR: Go for it. 

SEAN_DAVIS: Yeah. So it was maybe a couple, two, three months ago or so I had, I'd spent the first eight, I should say the last eight years or so, primarily in the agency world and doing some freelancing along the way there as well, where it's a new website, new web application every three months or so. And I had done it long enough. I felt like I needed to change. I wanted to get into the product world. And so I came across this new seed-stage startup called Grouparoo and was fortunate enough to be their first hire just a couple months ago. And I found it really interesting. It's not quite in the Jamstack space, but it's got some parallels here where it's all about syncing customer data. And so essentially, the premise is we've got... Or most product-based companies, but maybe we can focus more on early startups trying to grow your audience. And you've got customer data in some space, whether it's a data warehouse or a product database or something like that. And then you've got other teams or individuals who need to use that data in one of many services. So email service like MailChimp, maybe a customer support service like Zendesk or something like that. And so what GroupRu is doing and it is kind of creating this new space among a handful of other competing tools source of truth. So that product database or data warehouse and syncing it with these, these third party services. And so it's intriguing to me because it felt like this new space, one of these things like why, why, why hasn't this existed before, but also this goofy sort of parallel to the jam stack and kind of the way we're moving as developers where...What we seem to be doing less and less is building these gigantic monolithic applications, these custom services that we manage, we have to host on our own servers and keep up. And we got to hire developers to do it. And more and more, it feels like we're just, we're finding the tools that will serve our business needs more and piecing those together to kind of concoct this recipe that works for our organization. So I think that's it's an interesting space to be in right now, for sure. 

DAN_SHAPPIR: So just to clarify that I understand it's essentially a sort of a middleware solution that integrates data from certain sources and then exposes them to other services effectively. 

SEAN_DAVIS: Yeah, yes, exactly. And I think the Grouparoo’S difference is that we're, we're looking at data from the source of truth from the database rather than I think a lot of solutions, maybe not all of them, I'm not an expert in the space yet, I'm brand new to it, but up until this point, a lot of information was captured kind of on the client side, like through, through events and interactivity with that user. Whereas, Grouparoo is going more toward the actual product database and then syncing that with the tools that the various business teams are using. 

DAN_SHAPPIR: Cool. Like you said, the more services that we're using and Jamstack is certainly a catalyst for that. The more we need to be able to integrate those separate surfaces and make sure that they all work with a single source of truth. It's definitely something that I see as a growing need. 

SEAN_DAVIS: Absolutely. 

DAN_SHAPPIR: And the other thing, I actually went into this site and I thought it was a really, really interesting concept is the unmute thing. Can you tell us about that? 

SEAN_DAVIS: Absolutely, yeah. So this has been... This has been cooking for a little bit more than a year. And I'm super excited to see it finally coming together since it's good timing. So I have been fortunate enough to be able to work in this industry for almost a decade and really have had a great time learning and love the jobs that I've had. But over the last year or so, which is shamefully, only over the last couple of years, I really realized that like majority of the people in this space look exactly like me. I'm just another white dude with a beard and I don't feel like it should be that way. 

DAN_SHAPPIR: I do have need to mention that both AJ and me, AJ and I are beardless, at least at this point in time. But everything else, you're absolutely correct.

SEAN_DAVIS: So it's like, well, I feel like I've got this responsibility to use the experience I have, maybe the positions that I've gained throughout my career to give a voice and maybe help some help folks from underrepresented communities have more of a chance and more of an opportunity and maybe build a community around that. And so there was this idea was kind of cooking right around the time. I was closing up shop on this other podcast show I had going on, which was called, it was called Squirrel Stories. I did it for a couple of years and it was a real, real goofy thing where I'd have folks on who would share their weirdest and most embarrassing stories to a live audience. And so I had a ton of fun with that. But I was like, this is great. I love everyone's got their own weird, quirky, personal story to share. And, and that was a lot of fun to do, but it was, it was time for me to stop doing that. And now I felt like, and there's this, this other thing that I feel like is so important and it's the thing I, and it's involved with what I do every day for a living. So let's put these things together. And I found a few friends who felt just as strongly about it as I did. And so we, we came together and we've got this concept, which is called Unmute. And we're really anxious to kind of see what it becomes, but what it is starting as is an event-based storytelling platform for underrepresented folks in the tech industry. So I don't think it's not necessarily tech conference-esque or tech meetup. It's kind of, it's in that vein a little bit, but the idea being that it's a little bit more about the people and about the people's stories about having a safe, fun, open, real space to share these stories and to interact with one another. And we are, we're able to, we've, after a lot of planning, have our first event, which is going to be virtual since we're still in COVID times. And that's next month, April 22nd. And we've got a pretty, it's, well, I'll just call it a real story. I'm really looking forward to here in this particular storyteller next month. And then we'll see where it goes from there. Probably try to hold an event every two to three months or so and hopefully build a little community around this and then let the community tell us where we should go with it. 

DAN_SHAPPIR: So for now at least it's one or more people talking about their experiences related to tech or something like that? 

SEAN_DAVIS: Yep, it'll probably have some tech focus there as well. And it's not just developers. We wanted to be inclusive of all the roles in that space, which don't get as much of attention, like product project managers, designers, et cetera. And so this first story is from a woman who is a, it started as a graphic designer, now kind of in the UI UX space and is just, she's...She's actually working her way through a memoir now and is telling an experience she had while visiting New York City in college. So it's not necessarily tech related. It's kind of got some design elements to it, but it's more than anything, it's a human experiential story. 

DAN_SHAPPIR: Is it a free event or do you need to purchase tickets or something? 

SEAN_DAVIS: They are, it is free. You can register on the website. It's unmutedstories.com. And while we're doing them virtual, they will be free. That may change if we have to go to... Or not have to, but if we decide to do some in-person events at some point. But for now, virtual, free. And we're going to play around with the time so that we can try to get folks from various time zones. So it's not just catering, to one particular area. 

DAN_SHAPPIR: Cool, I think that this is a really, really interesting thing that you're doing. I'll definitely check it out. I do think we need more voices in our community. And I'm really happy that you're being really proactive about it. So good for you. I like to say that having privilege or privileges even in and of itself is not a bad thing. I think the point is, or the question is, is what you do with those privileges, whether you leverage them for good or for just for selfish ends. I think that that's what makes a difference, in my opinion, at least. 

SEAN_DAVIS: That's a really good way to put that. And yeah, you can tell I'm stumbling over my words and like, yeah, I'm trying to be, trying to use that privilege in the right way, but still kind of learning the right way to go about that and the right way to talk about it as well. 

DAN_SHAPPIR: AJ, correct me if I'm wrong, but I think we're nearing the end. So I think we'll keep the one about the rules for organizing components for future interviews. So you now have another reason to come on our show again in the future. 

AJ_O’NEAL: I would love to hear those rules. Yeah. All right. Well, go ahead, Dan. 

DAN_SHAPPIR: No, as I said, I just think that they're worth a longer discussion that we have time for. 

AJ_O’NEAL: And you're on. Agreed. I just said Agreed. All right. Well then let's head on over to Picks. 

 

This episode is sponsored by Sentry. Sentry is the thing that I put into all of my apps. First thing I figure out how to deploy them. I get them up on the web and then I run Sentry on them. And the reason why is because I need to know what's going on in my app all the time. The other thing is, is that sometimes I miss stuff. I'll run things in development, works on my machine. We've all been there, right? And then it gets up into the cloud or up on a server and stuff happens, stuff breaks. I didn't configure it right. AWS credentials, something like that, right? And so I need to get the error reporting back. But the other thing is, and this is something that my users typically don't give me information on, is I need to know if it's performing well, right? I need to know if it's slowing down because I don't want them getting lost into the Twitterverse because my app isn't fast enough. So I put Sentry in, I get all of the information about what's going right and what's going wrong, and then I can go in and I can fix the issues right away. So if you have an app that's running slow, you have an app that's having errors, you have an app that you're just getting started with, go check it out, sentry.io slash four, that's F-O-R slash JavaScript, and use the code JSJabber for three months of their base team plan. 

 

AJ_O’NEAL: I'm going to channel Steve for the first pick. I told him I would honor him in his absence today. And the question is, what's the oldest age someone should get a circumcision? Asking just cause I wanna know the cutoff. 

DAN_SHAPPIR: Okay, you do know at what age Abraham was circumcised by the way. 

AJ_O’NEAL: I actually, I probably should know that, but actually, no, I there's no reason I should know that. No, I don't. But I thought it was a little bit. He said it's oh, this. Oh, sorry. The joke wasn't done yet. There was an addendum to this. It's the cutting edge of humor. I was going to say it's a little edgy. And then I saw his word there. And he actually said it's the cutting edge of humor. So sorry for being a little irreverent. It's not a joke that I personally would have picked, but it is a joke I personally did laugh at. That said, I will also go ahead and do my own picks next. So for those of you are listeners who are looking to level up, I am doing some mentorship right now as I'm working on the Beyond Code Bootcamp course. So if you are interested in asking me questions, please hit me up on Twitter at underscore beyond code. We can talk about Git, we can talk about JavaScript, we can talk about Bash. We can talk about all sorts of things. What I'm doing is live episodes. So I get you get a couple of other people. I'll put some material together. We'll rough through it. And then later on I'm refining those with the feedback into the course material and of course I'd be happy to extend a discount to any of our, our listeners and especially those people who are participating in this kind of burnt, burnt pancake rough draft session with me. Also, I have to pick Vim Essentials, which is something that I've got up on webinstall.dev. So Vim Essentials, I've got up on webinstall.dev slash Vim hyphen essentials, or it's on the homepage. This is basically, if you are not a Vim nerd and you do not want to be a Vim nerd, but you would like it if Vim would behave sanely without learning how to do all the configurations, this is for you. This is your linters, your stylers, your basic things where you don't have to learn custom key commands to use them all just bundled together that'll install in two seconds. Well, maybe four or five, depending on the speed of your internet connection, but it's all the plugins that I use and recommend that are low maintenance, high value plugins. And then I mentioned earlier in the show, so I'm going to pick these, the stack exchange performance site that shows you their architecture. And I actually already closed the tab, but it was for SQL servers for SQL servers run not just Stack Overflow, but the entire network of Stack Exchange. And again, the number of servers, load balancers, everything that they have is a bare minimum. They are as efficient as crazy. Every couple of years, they do a blog, not necessarily on the Stack Overflow site, but perhaps on one of the employee sites. And so I'm including one of those, which is Stack Overflow Architecture 2016 edition. For those of you that are interested in that kind of stuff of course, the static site generator article that we talked about that shows actually in one of the graphs, Hugo doesn't show up. And you might think that's surprising. It's just because the bar is so small that literally it can't fit on the graph at the scale of the other, uh, runtimes or, or generators. That's right. And last of all, if you want to save yourself hundreds of dollars, if not thousands of dollars, I always recommend that you learn to use a VPS and I'm going to put a little plugin for something that I get a little bit of kickback on. You can get a hundred dollars or 60 days free on digital ocean. If you use the link that I include, and I'm not plugging this because of any sort of thing other than that, I really believe in digital ocean. And when you just want $5 a month guaranteed costs to be able to do something like a static site, it's what I use and I I think that more people should learn about it. I see people using Heroku and AWS and Kubernetes and all these things, and they're spending hundreds or even thousands of dollars on things that could cost them $5 a month, and I am not exaggerating when I say that. So I know I sounded like a total ad that whole time, whatever deal with it. Moving on to you, Dan. 

DAN_SHAPPIR: If you sounded like an ad, then so am I going to sound like an ad? I actually originally did not pick this, but because we kind of discussed adjacent stuff, I even kind of mentioned some of these things. I'm actually going to pick a post by one of my colleagues at Wix that was recently published on Google's web.dev website, in which he kind of describes the transition that we underwent, which I also mentioned in our conversation. When I joined Wix six years ago, we were essentially totally client-side rendered. So we were using the blank HTML type of an approach, which was great at the time because it really reduced server costs, but then started having performance issues as websites got ever more complex on the one hand, and people started moving ever more to mobile devices, which have less computational power potentially. So we using this type of an approach which I mentioned about generating the content and pushing it into the CDN on first visit, which forced us to essentially re-architect our solution according to some of the principles that we talked about in this conversation about separating the static stuff from the dynamic stuff and really thinking hard about what can be cached and what cannot be cached and where everything could be placed in either one of these two buckets. A link to that post, I think it's really well written and describes our journey in this context. So that would be one pick that I have. And the other pick that I have is also kind of related to web performance, actually really related to web performance because that's what I do in my day job. And a few weeks ago, we actually had on the show Jake Archibald from Google. This episode should be out already a few weeks by the time that you listen to this podcast. He was a really excellent guest and we talked about Stop All Over the Place. He recently published a series of posts. Apparently, he's a Formula One fan. So he had this excellent idea of actually measuring the speed of Formula One websites. So the speeds of the various companies that participate in Formula One races. And he did a comparison, kind of what you might call it a race between their websites. And it's really interesting to see how he measures their performance and analyzes it. So if you want to measure and analyze the performance of your own website, it's definitely worthwhile to see how a real professional does it on a real, on a real website, actually several real websites and, and compares between them. So these would be my two picks. 

SEAN_DAVIS: All right. Am I up? 

DAN_SHAPPIR: Yes. Now it's your turn. 

SEAN_DAVIS: Ooh, all right. Okay. So I'm going to give you. I'm going to give you one technical and one non-technical one. I'll do the technical one first. Cause I was just on a, I had a call this morning with someone in India and we were kind of shooting around this, this idea for a side project. And during the conversation, he sent me this website that I hadn't seen, but I think it's, it's great, simple, but great. And it's, it's free JavaScript resources. It's called. Well it's, it's like javascript.com except five instead of an S so java five. Crypt.com. I don't know how, how we say that, 

AJ_O’NEAL: but JavaScript with a five and then let you know. 

SEAN_DAVIS: Yeah. 

AJ_O’NEAL: Not, not strict JavaScript, just Java script. 

SEAN_DAVIS: Yeah. But right that that exactly. But it's, it's a great little resource where there's, or it's kind of just like a hub of JavaScript resources, books, websites, courses, interview questions, code challenges. Looks really pretty cool. I'm going to start poking around that as well. And then my non-technical one is this TV show we finished. And maybe everybody knows about this by now, but it's called Ted Lasso. And it's on Apple's TV streaming service, which is a little bit weird. I think I had a free subscription from getting an iPhone or something like that. So I had gotten a couple of recommendations to watch it. And it's odd because it's a soccer slash football based show. So it's a sports based show. But it's great. I think you could enjoy it without being a sports fan. I'm not a huge sports fan myself. But I'm describing it as the show that 2020 slash 2021 needed. It's all good, all happiness. Totally perfect. So it's like, if you need a break from the world, that's a, that's a good break to take for sure. 

AJ_O’NEAL: And with that, thank you very much, Sean, for joining us on the show. It was great to have you and have a little bit of healthy debate. I actually would look forward to having you again, so we could continue the discussion for all of you listeners. You have the most excellent day ever. Just take a deep breath in, feel the smog. No, you're in your homes. Feel that warm musty air and be energized and go on your way. Adios.

DAN_SHAPPIR: Bye. 

SEAN_DAVIS: Bye. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C A C H E F L Y dot com to learn more.