Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about Web design and development. I'm Dave Rupert. With me is Chris Coyier. Chris, how are you?

Chris Coyier: Well, I'm doing all right here in my little closet. It feels all the more appropriate every day. We have another guest who is in a closet today too. Divya Tagtachian, how are you?

Divya Tagtachian: Hello. Hello from my closet.

Chris: Hey.

Divya: I'm doing well.

[Laughter]

Chris: Good. It sounds good, though. I feel like podcasting quality for everybody is just going to skyrocket in these home times.

Divya: Oh, for sure. Yeah. Everyone is investing in good audio tech.

Chris: Yeah. I tried to order a new webcam and it was like – [Laughter] – I got this email that's like, "The company has failed to ship this product to you." It was like you can't even get your hands on a good webcam.

Divya: (Indiscernible)

Chris: I had one. I just wanted a really good one, you know.

Dave: Ah…

Divya: Yeah.

Dave: Hey, I'm going to go ahead and forecast a 95% chance two kids will run in here and ask for printouts from the printer.

[Laughter]

Dave: I just want to forecast that for listeners at home.

Chris: Mm-hmm.

Dave: There's going to be an invasion here, so.

Chris: People might know Divya from a couple of different things. You're at Netlify, right?

Divya: Yep, that is where I am.

Chris: Dev'ing it up.

Dave: Never heard of it.

[Laughter]

Dave: Never heard of it.

Divya: We're a small startup.

Dave: What's Netlify? What's a Netlify? Is that the--?

Divya: It's like Netflix but not Netflix. [Laughter]

Dave: Netflix for websites.

Divya: Netflix for websites. I think one of the phrases I tried to get people to adopt, I think it was like – what was it? It's like Netflix and chill. It was like Netlify and chill. But I think there are so many connotations to that. [Laughter]

Chris: Mm-hmm.

Divya: It was quickly shot down, so.

Chris: Yeah. I can't see the actual company embracing it but, as a side joke, I think it works.

Divya: Yeah.

Chris: Dave was just joking, of course, because a lot of us use/love Netlify already. It's a Web host, I feel like. I mean I can let Divya do this, but I think I'd tee her up just a little bit.

Divya: Yeah.

Chris: Largely, for static files.

Divya: Mm-hmm.

Chris: Although, I think, even from day one, the message has been like, "But don't let that get into your brain too deeply."

Divya: Yep.

Chris: Static files is great for a million reasons but it doesn't mean that this thing is only for like Jekyll sites. It's great for Jekyll sites, but it can do a lot more.

00:02:55

Divya: Yeah.

Chris: Netlify themselves came up with the word JAMstack. It wasn't like JAMstack and then Netlify is like, "I know! We'll make a hosting company around that." [Laughter]

Divya: Yeah. It's been around. It's just a matter of naming the thing, right?

Chris: Right.

Divya: People have been doing a thing for a while and then someone is like, "This is what you all are doing," and you're like, "Cool." I think that that helped a lot because, with Netlify, they were trying to push this whole concept of static site deployments.

Chris: Mm-hmm.

Divya: Alongside that, the architecture, like you were mentioning, of building sites, so it's not just static or Jekyll sites. It's building statically and then adding dynamic elements to it with serverless functions and so on.

Chris: Yeah.

Divya: The JAMstack sort of encapsulates that because it's not only really nice for overall, like making your site super-fast and secure, but it's also really nice for overall developer ergonomics because you can now deal with things in isolation rather than have this giant monolithic application and have things break and then your entire site doesn't work. I think that's like—

Dave: Back in my day, we called it Bluehost and you'd FTP crud up to Bluehost or whatever.

[Laughter]

Dave: Which is fine if you were using Bluehost.

Divya: Yeah.

Dave: But I feel like Netlify, in particular, has some innovation there because I don't just FTP it. I send it actually up to GitHub and then Netlify hooks into my GitHub.

Divya: Yep.

Dave: And then pulls it, like does some checks, and tries to build the thing I just pushed. Then it'll tell me how well I did that. [Laughter] It'll deploy the site for me instantly. I didn't even have to -- I just had to do responsible version control and now my site is updating on the Web.

Divya: Yeah. Yeah, I think that's the beauty of it because oftentimes, I mean I'm primarily a front-end developer and I really hate having to do a lot of DevOps-y things. In the past, it would be, "Oh, I need to containerize my front-end and then I need to put it on some kind of hosting provider or something like that." There are a lot of steps to it.

Then you would just never touch it. You would just be like, "Well, I'm just going to hope nothing breaks because, if things break, I don't know how to fix it," or I'll spend an entire day trying to fix it. With Git, we're already version controlling things, and so it's a workflow that's fairly streamlined. You're not actually doing anything else. You're just hooking your deploy pipeline directly into Git.

That's automatically handled for you. Netlify does all the work. All you're doing is just version controlling, really, and then you just automatically get that nice deployment cycle going for you without having to do any work.

Chris: It's that clutch?

Divya: Yeah.

00:05:34

Chris: Netlify has been doing this for years and, as soon as it existed, you look around -- to me. I don't know if this was the first thing, deployment thing, to hook into Git. Surely not, but one that really captured the hearts and minds of the people, in a way. Now, I look around and the entire hosting landscape, I'm like, how can you possibly offer hosting that isn't a first-class citizen hooked up to my Git workflow?

Divya: Oh, definitely. Yeah, I think I remember--

Chris: It's wild.

Divya: Yeah, I remember having to do all that myself. I had a site set up in, I think, 2014 or something. I had it such that it did, every time I'd push to Git, it would auto-deploy, but I had to build that and it took me forever to build that cycle. It was just, again, the same thing. From a DevOps-y thing, it was like, if that thing breaks I have no idea why. [Laughter] I would be very upset if I had to fix that.

With Netlify, it's probably not going to break. If it breaks, that's probably on Netlify, not on me. Yeah, that just cognitive load of automatically being able to deploy and ship applications without having to think about that, it's huge.

Chris: Yeah. We've talked about JAMstack a bunch of times on this show, so I think people are largely familiar in that there's nothing you can't do on it either. I like to--I don't know--think about that sometimes because it's kind of fun, you know. Just because it's some static files, there's literally no limitation to that. It's not an architecture that says, "Well, that's good for X, Y, and Z and not good for 1, 2, and 3." Not really. It might be that there's not--

You know, I overheard a conversation the other day about community forums. It was like, "Well, I want to build community forums. Can I do that on a JAMstack?" The answer is you absolutely can. But I'd say there's way more off the shelf choices for not JAMstack.

Divya: Yes.

Chris: You have choices to make, you know.

Divya: Yeah.

Dave: Build the thing yourself and get spammed into oblivion.

[Laughter]

Dave: Or use … (indiscernible).

Chris: Right.

Dave: Those are your choices.

Chris: Oblivion is right. As a matter of fact, after--whatever--11, 12 years of having forums on CSS-Tricks, I closed them because I was like, I can't dedicate time to this anymore. Spam was kind of a problem but that might have been solvable. Mentally, I'm a little checked out of this after all that time, so I kind of ended up spinning them down a little bit. I did note that Netlify yourself uses Discourse for the forums there. Even companies that are obviously highly invested in JAMstack sometimes make other choices.

00:08:18

Divya: Yeah. Yeah, building it would take a long time anyway. The thing is, that is a really great -- so what we're trying to do is push people towards that specific -- a lot of companies, generally, use Discourse for forums because it's a really great solution for just making sure that everything works. You can easily answer questions. You can manage users and so on. For people who are community managers, the UI is easy to understand and easy to set up, and so they can focus on focusing on the community rather than all the bits and bobs that come with a DIY solution.

I think one of the things that I often hear about the JAMstack and I've had to field a lot of questions is this whole -- the focus of the JAMstack or a lot of the conversation tends to be around developers. I talk about that, too, because I'm a developer. But it's interesting because, when you build a website, developers aren't the only ones involved in that process. You have people who are content authors or people who are just not technical who might be contributing in some way. There are times when you think purely technical in the JAMstack, when you're like, "Oh, people have to use Git and write content in Markdown." It's very developer-centric where it automatically raises the barrier to entry for other people because now they have to learn Git and Markdown.

I think the general thought is that when people talk about the JAMstack, they talk about these different models, which are developer-focused. I try to shift the conversation into thinking more about how do we create the JAMstack that's more inclusive for everyone rather than for just developers. There are solutions where, for instance, if you think about it from a content perspective, CMSs are really heavy but they give you so much functionality that a lot of headless options might not do. A lot of headless sort of Git-based CMSs, I would say, generally have a workflow that's not as robust as you would have if you used WordPress, let's say. WordPress gives you plugins and gives you all these things that allow content authors to manage their layouts and do a lot of configuration. If you were to do JAMstack strictly, as a developer-focused approach, it kind of removes that control from them because they automatically are like, "Well, I'm just creating content," and the developers are the ones who have full control over -- or I need them to do all the work if it comes to changing layout or whatever that is.

I think you can actually change that so that, by picking certain tools that take those non-technical people into consideration, you can still have JAMstack approach that makes developers happy but also people who are not necessarily technical also happy. With the JAMstack, there's generally, with CMSs particularly, there are Git-based an API-based CMSs.

Chris: Mm-hmm.

00:11:15

Divya: I talk about that a lot. You can choose whatever you want. It doesn't matter. I think the more I use either of them, the more I lean towards API-based CMSs. The reason for that is, it's really frustrating when your content is tied to the overall developer cycle of things. Now you're automatically blocked because your PRs and everything are put alongside code PRs. That's really frustrating because then it just creates these roadblocks. People who want to just create content now can't do it liberally. They have to wait for the PR to be approved and then someone merges it. There's this whole process. But if it's API-based, they can just be like, "Whatever!" and just going to add content as they need. Then any time the site is requested, it just pulls from the API and refreshes the content.

Dave: Oh, I had just an example. I had a client that built out a static site generator, Jekyll or maybe it was 11ty at some point, but for their content. Then, yeah, it was like, "Oh, you want this uploaded? Oh, that's a change request."

Divya: Yeah.

Dave: We have to do a -- this is a whole -- you have to file a change request. That goes through DevOps. That goes with the networking team. It was just like, oh, man. Really, just was fixing a typo. [Laughter]

Divya: Oh, for sure. Yeah.

Dave: Yeah. Yeah.

Divya: I've seen that happen. I'm not saying that you shouldn't use Git-based CMSs because I think they are great for, let's say you have fewer contributors and, let's say, documentation for instance. That's a fine use case for using a Git-based CMS because I imagine, one, you're not making a lot of changes. Two, a lot of the people making changes generally understand the deployment and development cycle. That's fine. The same with personal blogs. If you're the only one contributing to it then a Git-based CMS is fine, more or less. I think when you add more people to the team and there are people who are not necessarily familiar with the development cycle who don't want to be blocked, then you might have to think about whether a Git-based CMS is worth the effort because it automatically makes it more frustrating to work with.

Chris: It's early days for them anyway.

Divya: Yeah, that's true too. Yeah.

Chris: It's just like there's not -- those things need to grow up. I use two different ones. I'm a fan because I think it opens up some cool possibilities. Here's one, by the way, that I think "traditional" or any other kind of CMS has no good solution for, which is just totally open, public contributions. I know Netlify worked on an idea, but we're so used to that as developers because of things like pull requests. Pull requests are already beautifully fleshed out as a concept in the world, of developers anyway. If your content lives somewhere that's in Git anyway, essentially, you can offer a pull request for that content and then you can build a UI around it that isn't so gross, that doesn't look like a pull request to the person doing the pull request.

Divya: Oh, definitely. Yeah.

Chris: That's so cool! That's cool. WordPress can't do that. I'm like a WordPress lover. I love it, and you can't do that, you know.

Divya: Yeah, I think the open -- I think Netlify calls it open authoring. A lot of other CMSs, Git-based CMSs, are using this. That is one huge benefit to it because, like you said, you automatically can take contributions from external people who are not part of the org because of the flow of how pull requests work and forking and so on.

Chris: Yeah, right.

Divya: Behind the scenes, you're essentially just allowing forking the repo, creating a pull request to the main repo, and the person -- you can create a UI around it so the person who is adding the content doesn't even know that. That is definitely one benefit to using the Git-based CMS that API-based CMSs don't have.

Chris: Yeah.

Divya: I imagine it would be really hard to do that with API-based CMSs. Yeah.

Chris: You've got to be happy with where you keep your data because I think, whatever your individual circumstances are, if you zoom out from that and look at the world and how they tend to operate, you're not going to port your data. You're just not. You're going to rebuild your front-end ten times for every time you actually move where your data is. Just make sure you're really happy with where your data is.

I totally agree. API-based CMSs feel great and I feel happy about that because it could be a WordPress site. You still have to host it somewhere, making that part of your stack not particular JAMstack-y, but it offers and API so you could do that. Of course, the ones that are always talked about in Netlify circles are ones like Sanity, which is so cool for choosing how you model out your data. They host it for you, so it's an API. Of course, the big players that everybody has heard of like Contentful do good there and you've totally decoupled and your front end becomes this playground. You can just totally tear down your front-end and build it in some other way without having to port your data. Gosh, is that cool.

00:16:19

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by AWS Amplify. You know AWS, right? Amazon Web Services powers most of the Internet, it feels like. There are a ton of things that go in the AWS bucket like EC2 allows you to spin up servers of your choice and it has all kinds of configuration. S3 is for file storage and Lambdas is for running cloud functions, all kinds of stuff that, individually, you can set up, use, and are great. But there's so much more than that. There are a ton of different things AWS does.

AWS Amplify is kind of package of tools to help you build full-stack apps for the Web. It's like--I don't know--just give me the stuff that I need that, usually, you need an app. Amplify is hosting. You need Web hosting? It's got that. It's got authentication for logins for your users. It's got GraphQL as a first-class citizen of it.

It's got serverless functions like I need the Lambda thing. I want to run some code in the cloud to hit APIs and do whatever else I need to.

It's got file storage if you need it. It's got some machine learning stuff in there if you need it. Amplify is this easy to use, full-stack framework for getting started quick with building Web apps. It's really cool.

The auth stuff alone is cool. It's just a few lines of code in there.

GraphQL has taken over the world of how to get things from a database; put things back in a database. Really a front-end development-friendly way to do database stuff. Love GraphQL. It's just built-in as a first-class citizen. It's this scalable API. You don't have to provision your own servers. It just does it up for you - pretty cool.

AWS Amplify is really cool. Definitely worth checking out, especially as a front-end developer. Check all that out.

[Banjo music stops]

00:18:14

Chris: Let's rapid-fire. There are so many questions and this is a softball for you because I'm going to take these questions from you because you did -- this is another thing I know about. You did this two years ago or something on your own blog where you just went on a bender of blogging. I feel like that's your style.

Divya: Yeah, I do. [Laughter]

Chris: You blog like crazy and then you just stop for a minute.

Divya: [Laughter] Yes.

Chris: This latest round was all -- I don't know if you did it on your own blog too, but I'm looking at dev.to. Do they just call it Dev? Is it just Dev?

Divya: I think it's call Dev.

Chris: Just Dev.

Divya: Yeah.

Chris: Yeah, which is cool. It's a great site, community-oriented thing. There's all of your latest blogging super-story was there. #jamuary was the hashtag.

Divya: Yes, #jamuary. Yep.

Chris: If you had to answer -- I'm going to ask you the questions that are the title of your blog posts, but you have to answer them really quickly in, like, 15 seconds.

Divya: Okay.

Chris: Okay?

Divya: All right. Let's try it.

Chris: Can a SPA be JAMstack?

Divya: Yes, it can be.

Chris: A single-page app.

Dave: You hesitated there. You hesitated.

Divya: [Laughter]

Dave: Okay. Keep going.

Divya: Do I have to -- is it a single word answer as well or do I just be like--?

Chris: I like the single word, but also a tiny bit of elaboration is acceptable.

Divya: Okay. Yeah, it can be as long as you're statically rendering some parts of it.

Chris: Hmm.

Dave: Okay.

Chris: Okay.

Dave: Okay. Okay.

Chris: Can a site be too large for the JAMstack?

Divya: This one is -- "I think it depends," was my answer for this one because--

Dave: Oh, we're going to get the sad trombone sound effect.

[Sad trombone - womp-womp-womp]

[Laughter]

Dave: Okay.

Divya: It depends because, for instance, the larger your site is, the longer it takes to build, especially if you're building it statically. For a lot of people, that can take a lot of work when it comes to optimizing the build or even just having to deal with--I don't know--a couple of hours to build the site. For some people, that's a deal-breaker and that's the reason why they don't choose to go the static approach.

There are ways that you can optimize for your site that's super large to be JAMstack, so you're just managing the cache a little better so your build isn't super slower. Your build is fast, not super slow, so you're not building every single page. You're only building the ones that change.

Chris: That's interesting. Does that work? Who facilitates that?

00:20:38

Divya: The thing is, one of the things that we're adding to Netlify, it's called Build Plugins, and we've been hinting at it. I think we had an initial private beta for a while and we're going to release it soon.

Chris: I got excited too early. I made a whole thing around it. Then I'm like, I think the vibe was like, "Just wait. It's not really ready."

[Laughter]

Divya: We are changing it quite a lot. Within the DevX team itself, we're like, "We're ready and we built a bunch of plugins." Then they're like, "We changed the API." We're like, "Cool. We need to update everything," which I think that happens with quick feature changes and so on.

The build plugins will give you access to how Netlify builds your site, which also gives you access to the cache. You can sort of manage what's in the cache and change what's in the cache if you want to within, like, through a build plugin. That gives you a lot of functionality.

Chris: Fancy.

Divya: Yeah, it's fancy because, previously, it's kind of a black box.

Chris: Well, the question goes, let's say you have a 100,000-page site. A hundred thousand pages is going to take a hot minute to render in anything.

Divya: For sure. Yeah.

Chris: Maybe 11ty can do it fairly quickly but it depends. It depends on what work it has to do and how many functions it's running and stuff. Let's say it took you ten minutes. That'd be pretty fricken' slow, but it could be even worse than that. I'm sure there are sites that are much bigger than that.

Divya: Yeah.

Chris: Then the question is, seriously, are we looking at long builds, long deploys, or what? You already talked about it because maybe you just break one page of that cache. Maybe you just deploy that one page. Maybe you just rebuild that one page, but it feels like early days.

Divya: It is very early days.

Chris: Nobody is saying, "Oh, we just do that out of the box."

Divya: Yeah, I think it's really early days with that, especially with a lot of JAMstack and static site deployments. I can speak just how Netlify works is that you automatically invalidate the cache every time you deploy. It can get, as you said, very heavy because if you invalidate the cache for like a 10,000-page site, it's going to take 10 minutes or more for the entire site to rebuild because we're just essentially building that 10,000 pages each individual one.

I think, yeah, JAMstack is maturing a lot, so you see a lot of e-commerce adoption. But I think, in general, we are tackling a lot of the challenges that come with building large sites on the JAMstack.

Chris: That would be the same problem with a forum, if you built it that way.

Divya: Oh, for sure.

Chris: You'd be like, really, every single comment is going to be an individual page? That's going to get big real quick. Anyway, related, is server-side rendering or SSR, is that the same thing as JAMstack?

Divya: No. I'm very adamant against, so I know -- [Laughter] This is a very hot take. I feel very afraid to say this.

Dave: Oh, good. Yes! Spice.

[Law & Order - dun, dun]

Dave: The spicy takes.

Divya: ZEIT has released a lot of articles talking about serverless server-side rendering. I call it -- it's just a bunch of hogwash to me because the whole concept of server -- server-side rendering is dynamic rendering, essentially, if you think about it. You're dynamically rendering every time someone requests the page, and so that is inherently not statically rendered. You can't call it statically rendered because the whole point of the JAMstack is you're moving away from dynamically rendered pages. That automatically gives you the benefits like speed and security and so on. If you're doing serverless server-side rendering, whatever, that's completely antithetical to this whole concept of static rendering. Also, I think a lot of problems--

Chris: So, it's still like prerendered. It's still like an HTML file or whatever. But in SSR, the way we're defining it here is that there is still some backend language that's spinning up in which to spit that thing out.

Divya: Yep, exactly.

Chris: Okay. Okay.

Divya: It's a hot take, for sure, because I know that there's a lot of contention in the JAMstack space around what or whether SSR is considered JAMstack. Netlify's take is definitely not. If you want to do it, you can do parts of your site using SSR, but just know that that's going to add time to your site, your overall build time.

Chris: Well, even Netlify, you even offer SSR because--

Divya: Well--

Chris: --a Lambda can spit out a static -- not a static.

Divya: Yeah.

Chris: A Lambda can return HTML.

Divya: Oh, for sure. Yeah. Yeah, so I would actually rephrase that in that we don't -- so we don't encourage it, but we offer you the ability to do it. [Laughter] It's sort of like--

Chris: [Laughter]

Divya: If you want to, you can shoot yourself in the foot, but we do not -- [Laughter] The way we market that is slightly different. ZEIT has also similar serverless functions. For them, they essentially push the whole SSR dynamic forward because they're like serverless functions allow you to do SSR at the edge, which I would argue a lot of -- so, again, when it comes to edge and serverless functions at edge, not a lot of companies do that at the moment.

Chris: Yes, Cloudflare.

Divya: Cloudflare has edge. Yeah, Cloudflare has edge workers and then Lambda has at edge, but a lot of people doing serverless functions today are not doing it at the edge. Even though your static sites are loaded from the CDN, which are edge nodes, the serverless functions are still origin servers. [Laughter] You don't get the benefit of….

Chris: I deal with that regularly.

Divya: Yeah.

Chris: We're like, I guess it's a cool Lambda but it's still USWest3 or whatever.

Divya: Exactly. Yeah, and so -- yeah, I think people forget that. They just automatically assume everything is edge and you're like, no.

Chris: Yeah, it just gets complicated, right?

Divya: Yeah.

Chris: Because you can put it behind -- so in our Brian LaRue episode, he was talking about this and how it does get complicated because the way they serve their app, they use Lambdas even to server otherwise static stuff.

Divya: Yes.

Chris: the Lambda runs once, generates the static thing, which goes into CloudFront somehow and then the Lambda never gets touched again. Technically, it's--

Divya: It's not Lambda. Yeah.

Chris: It's barely SSR.

Divya: Yeah.

Chris: One time it was SSR.

Divya: Yeah.

Chris: Then it's cached from then on out, which feels a little closer to JAMstack to me.

Divya: Definitely. Yeah.

Chris: Yeah.

Divya: I think that, yeah, that would be closer to JAMstack than SSR for every request kind of thing because that's not super--

Chris: Yeah.

Divya: Yeah.

Chris: Yeah, but I get the appeal of that approach too because, if you have a server back there--

Divya: Yeah.

Chris: --then it's like, oh, cool. I can check a JWT.

Divya: Yep.

Chris: There's all this stuff you can do that you can't on the JAMstack.

Divya: Oh, definitely. Yeah, so, actually, the interesting thing is, the other thing I've been thinking about is the future of JAMstack. Like, okay, as we've been mentioning, the JAMstack is growing in maturity but there are a lot of things that are still trying to be -- like a lot of infrastructure that isn't fully fleshed out yet or is still being developed. One of the things is just the ability for what we can do at the edge. I think we're still in the early stages of pushing the boundaries of what edge can do. But I'm excited to see where that goes because, for now, certain things you can do at the edge like, with Netlify, you can do redirects at the edge because that's edge logic that happens automatically, so you could just redirect without having to go to the origin server to redirect. Authentication can sometimes happen at the edge as well. It's just figuring out -- I think it's interesting and really fascinating to see what companies are coming up with in terms of what you can do at the edge and what logic they give you access to.

Chris: Yes. Amen. I could see that being a big deal for the future.

Divya: For sure because I think that automatically pushes the boundary of what JAMstack is. I think JAMstack, for a long time, in its infancy, people were really focused on the technology of, like, "Okay, JavaScript, API, Markup, JavaScript, API, Markup, whatever, whatever." I think at this point we're starting to see, with the infrastructure changes and developments, that you can do so much more.

In the early days, it was fairly static. You could do some dynamic stuff but not super dynamic stuff. Then I think, as the ecosystem emerged and microservices grew, you could do a lot more dynamic stuff but you're still pinging other APIs and so on.

Dave: Mm-hmm.

Divya: I think it would cool to see what you can do on the CDN that you currently are on and you're serving from. What does that give you access to and what will that give you access to? Then what would that open the possibilities for?

Chris: Yeah, it seems incredible to me. Yeah. It's this new layer of the stack that you're like, "Wait. What? What?!" You know because it's kind of like a Web worker, in a way, but a Web worker has to run on your client, but you don't have to run it on your client. You can run it before the client. You're like, "What?!"

Divya: Yeah, I think one of the things, for instance, I'll just talk about the limitation of JAMstack, which is something that comes up a lot that you can't do. You can't do Web sockets, for instance, well on the JAMstack or anything that's pub-sub style things because everything needs to happen through webhooks. An event happens and then it pings Netlify directly. Then Netlify is like, "Oh, okay, cool," or another service and you're like, "Oh, okay, cool. I need to rebuild."

I think what would be really cool is this ability for, like, let's say you have edge nodes and the edge nodes have a sense of what APIs you're connected to and when content changes. It's listening for content changes so the content doesn't have to ping it. It just automatically is like, "Oh, the content changed. Update."

Chris: Hmm.

Divya: That would be cool. [Laughter] I don't know. It's just things that people--

Chris: I think if you need that now, you just do it in JavaScript, right?

Divya: Yeah, essentially.

Chris: I just don't prerender that part. That's just not prerendered.

Divya: No, you wouldn't prerender because if something is updating that frequently--

Chris: Yeah … div.

Divya: Exactly, yeah. You just hydrate every time or something.

Chris: Okay, well, I agree. That's going to be some future stuff happening there. What's up with JAMstack plus WordPress? Is there any good story there? What's the story?

Divya: Yeah. I think it's growing a lot. WordPress has had the API to get content for a while, I think. They've had a Rest API for a while.

Chris: Mm-hmm.

Divya: I think they've started talking more about the static approach. Again, I'm not super-in the WordPress community, so I feel really bad about just being like, "Only recently they found the JAMstack," but it seems that way to me. [Laughter]

Dave: [Laughter] Until recently.

Divya: Yes. They found….

Dave: I think I've heard Gatsby, as a consumer of WordPress, is beginning to take off, I guess.

Divya: Yeah, I think Gatsby has been spending a lot of effort and time to create resources that will help the WordPress community migrate towards a JAMstack solution. Obviously, theirs is very Gatsby-centric, so you essentially might be migrating WordPress towards Gatsby specifically.

Dave: Right.

Divya: Or creating a solution where your content is on WordPress and your site is in Gatsby. That's a very -- it is JAMstack-y, but it's very not technology agnostic.

Dave: Mm-hmm.

Divya: But it is helping that community because I think it is giving them a sense of, like, oh, okay, static approaches exist. JAMstack is a thing. I've seen a lot of people start talking about it. There's a podcast called That's My JAMstack, and I think--

Dave: [Laughter] Nice.

Divya: It's really good. They talk a lot about JAMstack approaches and so on. I listened to an episode from last year. There's a guy by the name of Daniel Olson. He's building a thing called Shifter, which is like static -- it's like a static site generator for WordPress, which I didn't think was a thing. Then I heard the podcast and I was like, "Oh, that's cool." It's not actually using WordPress as an API. It's essentially just using WordPress as is. Then you have this build pipeline that just takes your WordPress and spits out a static site.

Chris: Well, that's a big deal because if you just use the API then you're on your own to rebuild the front-end.

Divya: Exactly.

Chris: You're not using the heart of WordPress, which is all these hooks.

Divya: No, you're not using the themes and the plugins. Yeah.

Chris: Right. Exactly.

Divya: Yeah, so that was pretty cool.

Chris: That's pretty interesting. What's funny about that is that there have been plugins for ages. What's the biggest caching plugin on WordPress? I forget what it's called.

Dave: Total Cache.

Chris: Probably that. Yeah, that one, W3 Total Cache, or whatever, which I used for ages. It seems like these days hosts want to be your cache--

Divya: Yeah.

Chris: --instead of that, for some reason, which I guess makes sense because you can do a lot from the NGINX layer and stuff like that and CDN layer. But anyway, how that one worked was the page was requested and it literally made a file called thatpage.html.

Divya: Yeah. [Laughter]

Chris: Then when it was requested again, it would just get that HTML file and serve that.

Divya: Yep.

Chris: Instead of asking PHP and asking MySQL and running all that stuff, which is cool, which is kind of JAMstack-y.

Divya: Yeah, it is.

Chris: [Laughter] But I think it was smart enough to know that not everything can be done like that. I don't know if it hydrated, per se, but it knew when to invalidate cache. I don't know. It obviously was complicated technologically. Otherwise, everybody would have just built their own plugin like this. I'm kind of curious.

I don't know what to do because I'm in that position where I'm like, I love WordPress, the authoring experience in there. I got it dialed in perfectly for me. I use all this stuff. I'm playing around now with some e-commerce stuff in there with WooCommerce. It's just easy and it's just great. It just works beautifully.

I'm obviously attracted to the JAMstack. I bought a bunch of other sites on the JAMstack. I like the dev experience. I like the speed. I like the security. I like everything about that. It just seems to me there's got to be a future in combining these things, these big industry players.

Divya: Yep. Yeah, because I think every time I talk to people who are in big CMS communities, whether that be WordPress or Drupal, that is one thing. You're so committed to that framework and all that comes with it because it gives you so much power and control over how exactly you want things to work, plugins, et cetera.

Also, the thing is, going back to my previous point, people who are building a site and don't want to get into code or whatever, they can easily build a site using WordPress without having to touch a line of PHP if they want. It works and it's great. But then, automatically, when you're like, "Oh, you should move to the JAMstack where it's secure or whatever, whatever," it's like, essentially, they lose a lot of that control because you're like, "Well, you can use WordPress for your content but you have to build everything else yourself." Then it takes away from the complete joy of using WordPress, which people are so committed to or that's the thing that they're very comfortable with.

I think it would be cool to see more solutions. I think Shifter is one. I think Strattic is another as well, which essentially is trying to build a way of allowing people to continue to use WordPress statically generating static sites, static pages--

Chris: Mm-hmm.

Divya: --from that itself, so that would be cool to see how that plays out and if that increases overall adoption within that community.

Chris: I think there's a spectrum of all the way from, "Oh, this site is going to be pretty easy," to, "This site is going to be incredibly difficult." I'm not on the incredibly difficult scale, but I'm pretty close, like pretty high up there to the point where it doesn't compel me immediately to just be like, "I'm going to drop everything and do that."

The other funny thing is like, for the industry at large, you still need a WordPress instance somewhere then and you're probably paying for that.

Dave: Mm-hmm.

Divya: Oh, that's true. Yeah.

Chris: It's like, you're not saving any money. In fact, it's probably going to cost you more money to run this stack in this way. It's like, well, just run WordPress locally or something. I don't know. Maybe, but that's not exactly the point, you know.

Dave: Less moving parts.

Chris: Yeah.

Dave: Might be nice, but.

[Banjo music starts]

Chris: Hey, ShopTalk listeners. This show is brought to you in part by CodePen. That's me, your host Chris, Co-Founder of CodePen also. Sometimes I like to sponsor our own show and tell you about CodePen.

It's a freemium app, so you can use CodePen for free, but I hope to compel you with the features of CodePen Pro. One reason you might upgrade is just because you like this show. That's fine with me. I'll take your support that way. Ideally, there's some part of Pro that makes you want to upgrade.

One of the little things you get with Pro is that you get unlimited embed themes. You might build something on CodePen in which to then use somewhere else, like use in a blog post or documentation or whatever. It's nice because you change your theme and then it changes on every single embed where you used that theme.

Of course, that's very important to me on, like, CSS-Tricks, for example, where I might want to change the look of the embed because we're redesigning the site or just want to freshen things up or something and have that theme change over the entire site. Of course, I do that. If you need several, a bunch of themes, just go Pro and you have unlimited of them, which is cool. Just one of a dozen or more features you get for upgrading to Pro on CodePen.

[Banjo music stops]

Dave: I think, you know, what surprised me and we've talked a lot about blogs, and I can hear people saying, "Well, JAMstack. That's fine for small sites."

Chris: [Laughter]

Divya: Mm-hmm. [Laughter]

Dave: "Personal projects," you know, that bummer who shows up in the Twitter.

[Laughter]

Dave: I think what I was surprised from JAMstack Conf that Chris and I went to last year that even e-commerce is starting to happen on the JAMstack. Then you bailout to a big commerce checkout flow or a Shopify checkout flow. You do all the data bits or all the user experience and then point where you take a credit card, you just have to go visit the big server.

Chris: You know another thing like that, these used to be an advertiser on CSS-Tricks ages ago, like eight years ago. It was called Foxy Cart. It's called Foxy.io now. The whole point of it was e-commerce that they just host, basically, a JavaScript-powered cart and then, eventually, kind of an iFrame modal checkout kind of thing.

Divya: Oh, cool.

Chris: You can still do whatever you want CMS wise with your products.

Divya: Yeah.

Chris: Like manage your products, your prices, and your pages and just build whatever you want. Then the moment you actually need to buy the darn thing, you click a little button that adds it to their little checkout flow and go from there. The whole point -- I used to do it on WordPress sites, which had its own e-commerce solution, but I liked the idea that you could take this and you could plop it on top of any CMS. I bet it's particularly JAMstack friendly, now that I'm thinking about it.

Divya: Probably.

Chris: Anyway--

Divya: I think they get compared to Snipcart because Snipcart, I think, offers a very similar approach.

Chris: Oh, yeah.

Divya: It's like a drop-in e-commerce solution for creating shops and things like that.

Chris: Right. That makes a lot of sense. It seems like -- like why not? Isn't that part of the spirit of JAMstack? It seemed like it is to me a little bit that you get to piece together services.

Divya: Yeah.

Chris: You're like, I'm going to pick this service for this. I'm going to do my forms over here.

Divya: Yep.

Chris: My API is going to be powered by this.

Divya: Yep.

Chris: My e-commerce will be this.

Dave: Kind of like no code for developers.

[Laughter]

Dave: I guess no code is for developers too. I see it in a design context a lot but, yeah, you're just like, "Oh, I want that thing."

Chris: We already do that anyway. Whatever you build, you're like, "I'm going to use this for my error tracking and I'm going to use this for my analytic solution."

Dave: Bootstrap. Bootstrap.

Divya: Yep.

[Laughter]

Dave: Always bootstrap.

Chris: Well, this is fun. Let's see. Are there any more hot take questions we can do there? Why is the JAMstack fast?

Divya: Well, the JAMstack is fast mainly because of the way that it is architected. Instead of dynamically rendering your site, you're statically serving them and so the site is already prebuilt. Instead of every time someone requests your site, they have to -- the servers need to go do work and then give you a thing, it automatically has the page available and it gives it to you. That's super-fast.

The other thing is that the infrastructure makes it faster. Let's say a static site statically prerendered. Yes. You're having it on an in-origin server like some EC-whatever, EC2 bucket or whatever, S3 bucket. You still need to go to the origin server to get the page and back, and so there's this thing called latency that happens. It's like the further you are from the server, the longer it takes. It's limited by the speed of light, so you can't really increase that.

With the JAMstack, generally, you're serving directly from a CDN, and so the CDN makes it much faster because the CDN is different from the origin server. Origin server, it'll be dependent on where you are, so you'd pick Virginia or wherever else servers on. With CDNs, generally, there's this concept of edge servers, so it's different from an origin server because an origin server has the ability to churn dynamic things, so it runs JavaScript or whatever you want to throw at it. It can churn and do that logic.

Edge node is not as highly functional but it is closer to the user. I'm in Chicago, so there's an edge node probably somewhere here. If I'm requesting a page that's statically rendered, I can just grab it from wherever the Chicago node is. Instead of going all the way to Virginia, it just gets it from Chicago, so it's much faster. The latency is automatically reduced. That makes it much faster, overall.

Chris: It's two things. It's not only statically rendered, but it's hosted on edge nodes.

Divya: Yeah, that's the other part.

Chris: Pretty cool.

Divya: Yep.

Chris: Does Google care about that? Is that a benefit? We know that they factor in speed at least a little bit, right?

Divya: Yeah, I think they factor that. I think I hear a lot of the SEO things, so I've always had arguments with people about SEO because they're like, "Well, even if your site is dynamically rendered, Google can run JavaScript, so whatever. SEO doesn't matter." But I think you do get benefits from statically rendering your content because now the bots just automatically know what your site is, and so the crawlers don't have to do a lot of work. For me, that's a benefit.

Of course, crawlers and SEO bots are much more highly functional than they were 20 years ago when people were actually putting HTML on servers. Yeah, but I would argue there is a benefit from an SEO perspective. Obviously, that's an ongoing argument with people who are like, "Well, I can still SSR and get SEO benefits," blah-blah-blah.

Chris: Yeah. I don't know. I think the only fact I know for sure because I saw it in a video from Google says that if there is literally no content on the page when we first crawl it and we know that JavaScript is going to run and the content is there, we're not going to ding you but it does go into a queue in which that it's a week-ish long queue. A week for your first pass and a week every time you change it. That seems like a lot. It doesn't hurt your SEO. It's just slow SEO.

Divya: Oh, no. Yeah, exactly. Yeah, so it's just generally a benefit when you statically render it for SEO unless you're willing to wait a week, which is--

Chris: I bet they factor in. How can they not factor it in?

Divya: Probably.

Chris: The page is right there ready to rock and roll.

Divya: Yeah, probably. They probably take Lighthouse into consideration or something, maybe. Who knows. Yeah.

Chris: All right. That was a lot of JAMstack stuff. You're also interested and involved in Vue and stuff. How does something like that, like a JavaScript framework like Vue, what does that have anything to do with the JAMstack?

Divya: Going back to your question on whether SPAs are JAMstack, there are ways that you can statically render a single-page app like one that's built with Vue. You can do that with various things like prerender.io. There's also a pre-render SPA plugin that I sometimes use that essentially will run through my Vue site and then spit out some static pages, which are really nice, so I don't have to do a lot of work. It can still be like blah-blah-blah. I can use Vue.

I think part of it is I really like Vue and I'm really invested in the ecosystem and framework. For me, it's just trying to find ways that the two can work together.

I think, also, the approach that, oh, if you want to be JAMstack, you have to be completely static and you can't use frameworks is pretty divisive, especially if we want people to build in this particular way. We can't just automatically be like, "No, you can't use your framework that you really like anymore. You have to build vanilla JavaScript or whatever."

I think the JAMstack doesn't discriminate between whether you use vanilla JavaScript or a single-page app. I think whole focus is like, okay, if you built the site in React or in Vue, statically, figure out a way so you can statically render it. There are lots of ways you can do that. I can't speak to React because I haven't done it in a while.

Chris: We already talked about Gatsby, which is 100% React.

Divya: Exactly. Yeah.

Chris: They can do it.

Divya: I think I'm talking more about create-react-app.

Chris: Right.

Divya: Within frameworks, there are also static site generators. Vue has a couple. There is VuePress, which is specifically for doc sites. Then there's also Gridsome, which is more for blogs or whatever you want to use. Gridsome is sort of Vue's solution to not having a Gatsby. It's like the Gatsby equivalent. That's one way to do static site generation stuff with Vue, so you have the functionality of doing anything, like having all of Vue and then being able to static render. But you also have, similar to Gatsby, all the GraphQL and all the extra niceties that come with that whole framework.

Dave: VuePress is the thing you see whenever you've been to any Vue website's documentation. It's just using VuePress, always. Right?

Divya: Yeah.

Dave: Every single one.

Divya: [Laughter] Netlify docs are always in VuePress, actually.

Chris: Oh, really?

Divya: That was a huge win.

Chris: Oh, that's cool.

Divya: Yeah, that was really fun.

Dave: I get a chuckle when I go to a new JavaScript framework and it's just in VuePress.

[Laughter]

Divya: It's like they didn't even attempt to change the theming. It's just like VuePress.

Dave: Yeah, it's just the great -- just the default. Then Nuxt is like the next--

Divya: Yeah, and Nuxt is the next level.

Dave: That's your build your own application kind of from scratch kind of thing.

Divya: Exactly. Well, Nuxt is sort of -- I don't even know if this is the fair equivalent, but it has a very similar architecture to rails in that it scaffolds things for you.

Dave: I called it Rails for Vue. I don't know if that's a compliment or if people take that as a compliment. It has similar ergonomics.

Divya: For sure. It's interesting. Have you had a RedwoodJS? It's the new framework.

Chris: That's what I was going to talk about next because I'm like, "Look at this stack of technology. How can that be JAMstack?" You know?

Divya: Yeah, so I had--

Chris: I literally don't even get it yet.

Divya: I was on -- so just to end the previous point, the thing that Tom Preston Warner, he calls RedwoodJS the Rails for JavaScript. I was like, I don't know if that's a compliment or an insult. [Laughter]

Dave: Hmm.

Divya: He's like, we don't have--

Dave: Yeah.

Divya: We don't have a Rails equivalent in the JavaScript world. I was like, I don't know if people liked Rails and we wanted that in our community.

Chris: Oh, they totally do. I like Rails. Dave likes Rails.

Dave: I want Rails, but I want Rails. I don't want Bundler.

[Laughter]

Dave: I Love the people worked on Bundler, but it just had a few rough goes, just like NPM is and will.

Divya: That's fair. Yeah.

Dave: Yeah.

Divya: Well, NPM is part of GitHub now.

Chris: That's what I think of, though. The point of Rails is you could be like, "I want auth. I want this error handler thing. I want this cool plugin that does tags good." That's not here. RedwoodJS is too new for that.

Divya: Yeah, so the thing with Redwood that I -- so, I was actually on a podcast with him on JS Party, and so we talked a little bit about that because even if you look at RedwoodJS, they call it full stack for JAMstack. I think I question that a little bit because I'm like, isn't JAMstack not full-stack? I think the point he was making was that it just -- so, the common argument or the common criticism for the JAMstack is that you have to pick and choose. Some people really enjoy that, but some people are like, "I just want a site really fast. I don't want the whole, like, having to decide what e-commerce solution I want, what auth solution I want."

Dave: Mm-hmm.

Divya: All of this, like having to build all of that. You're not building, granted, the logic around it but you have to make all those decisions, which is a lot.

Dave: Mm-hmm.

Divya: I think Redwood directly addresses that, that you're building a site and then all of these are just decided for you and you're just building with that infrastructure in mind.

Chris: Yeah, like if you didn't -- I mean it's saying, use Prisma. Prisma is an online database thing.

Divya: Exactly. Yeah.

Chris: It's saying, okay, there's data involved then. Redwood is saying, "If you're going to access that data, you're going to do it through GraphQL." Okay, thanks.

Divya: Yep.

Chris: "If you're going to build a front-end, you're going to do it through React." We're not even going to say that. We're going to say, "You have to use our style of React component," and that component is highly based around how it goes and gets data. Every component is going to say, "Well, it can be in one of these states then, which is error or fetching or success or all these things.

Dave: I like that part of it. That's just me.

Divya: Yeah.

Chris: Oh, yes.

Divya: It is nice. It's really nice for that because you don't have to decide. I think it addresses the people who are just fatigued by having to make decisions but still want to use JAMstack. It directly addresses their pain points.

Again, Redwood is super new, and so I think they have a lot more. It needs to develop a lot more. It's still not super mature.

Chris: Mm-hmm.

Divya: I know they're advocating for using it and they're like, "Use it in everything." You're like, "Well, it's not mature yet. [Laughter] I don't really want to dig in super deep."

Chris: I think that's fair but, also, the tools that it's built from are mature, you know, -ish.

Divya: That's true. For sure. Yeah. Yeah, Prisma is great.

Chris: What's the final juice? What's the magic juice that turns all those technology and then makes the JAMstack friendly? Does it pre-render or what?

Divya: I don't actually know, under the hood, what it does. I think it pre-renders some aspects of it, probably the front-end piece. Yeah.

Dave: Here, I'll just search the docs for juice.

[Laughter]

Dave: No docs found.

Chris: Well … say this thing is ready for JAMstack.

Divya: Yeah, so I think--

Chris: It's got to do something.

Divya: Yeah, so I think the front-end components, like the Web components and everything, are pre-rendered and put on a CDN. Then all the other pieces, like the databases, the GraphQL, the third-party APIs are all exposed through a GraphQL endpoint using serverless functions.

Chris: Hmm.

Divya: I think that's how it works. They also call it edge ready, so it's ready to be--

Chris: Oh…

Divya: So, I think that's--

Chris: So, it's your thing that you poked at earlier. The Lambdas are doing the heavy lifting here, in a way. It's not doing the Gatsby thing where they are pre-making all these files. It doesn't look like it's doing that. I could be wrong.

Divya: Yeah, I think Gatsby essentially pulls the APIs, pulls everything and then gives you static pages. This is sort of different because it's not doing that. It's not pre-rendering every single page. It's not pre-rendering the pages with the content in it. It's still available as a serverless function.

Chris: Yeah.

Divya: And then hydrating it.

Chris: They're rolling the dice. They're saying that's not necessary. That Lambdas are so good and so fast and so cacheable that we don't have to do that.

Divya: Yep.

Chris: Uh, we'll see. We'll see. Who is going to win, Gatsby or Redwood?

Divya: One has a giant investor behind it. [Laughter]

Chris: Yeah.

Dave: Yeah.

Chris: They both do, though, don't they?

Divya: We'll see.

Dave: Yeah. Well, they kind of both do now.

Divya: They both do. Yeah, they both do.

Chris: Yeah.

Divya: That's true. Yeah.

Dave: I have invested quite a bit--

Chris: Mm-hmm. I know Zach Leatherman is looking for--

Dave: --into 11ty.

Chris: Yeah. [Laughter]

Chris: Yeah.

Divya: [Laughter]

Chris: He's looking for the $5 million to $8 million seed round.

Dave: Yeah.

Chris: [Laughter]

Divya: Cool. [Laughter]

Dave: I do like -- maybe it's new. Well, what's funny is, I went camping on spring break. Then come back and there are eight messages, I feel like, in the ShopTalk twitter, like, "You need to talk to Redwood." I just was like, "Well, I guess another JavaScript thing was born.

Divya: Yeah. [Laughter]

Dave: [Laughter] You know, while I was camping. But knowing Tom Preston-Werner is involved.

Divya: He's so willing to talk. We got him on JS Party, which I was amazed that we did. Then we talked to him for a bit. he was like, "I'm happy to talk to anyone about Redwood. I think he's trying to send stickers to whoever.

Chris: He must be. Yeah, he must be on that kick because we got him too, but not for like another six weeks or something. But, yeah, we're not as cool as you who got him right away.

Divya: I know. I think we've been hounding him for a while. We've been like, "Can we talk to you?"

Chris: [Laughter]

Divya: I think, because he's been talking about Redwood for a while, and so I didn't but K. Ball did. He jumped on that. He was like, "Let's try to see if we can get him on the show." Jerod was also -- they're both, like, very on the ball.

Chris: On the ball.

Dave: Nice.

Chris: I get it.

Divya: [Laughter]

Dave: Hey… No, I'm like, I didn't know it had a form helper, which is actually excellent. That would sell me on this.

Chris: You don't need that. Netlify does that.

Dave: To be honest, I love form helpers.

Chris: Oh, you mean a different -- like a -- not a helper like process your forms, but like a--

Dave: No, like a Rails style--

Divya: Like it creates it for you. Yeah.

Dave: Like labels, inputs, and errors.

Chris: And errors?! Ooh…

Dave: Yeah.

Chris: Nice.

Dave: Yeah, I just said errors and everyone said, "Ooh!"

[Laughter]

Chris: Ooh…

Dave: That's exactly -- that just -- we are just a broken species.

[Laughter]

Dave: You say, "It handles errors," and everyone goes--

Chris: Ooh…

Dave: "Oh, my god! I'm checking it out!"

Divya: Very important.

Dave: (Indiscernible)

Divya: Yes.

Dave: Well, I guess we kind of maybe need to wrap up here, especially because my neighbors are mowing and that's always good for audio.

Divya: [Laughter] Cool.

Dave: If you could forecast one, two, three years out, what is JAMstack in the next -- like, should we be moving or what's your forecast?

Divya: I think it's as I was saying before. It's going to mature a lot more, and so we're going to see, as edge nodes get more logic and as you can do more on the edge, you'll see a lot more functionality. I think we'll also move away from JAMstack being like JavaScript API Markup specifically and more into this whole way of building things at the edge because I'm actually almost invested in this. I've drunk all the Kool-Aide. It's very much the more -- you see a lot of this with Cloudflare workers and Netlify is also building stuff at the edge and so on. That would give people so much more they can do. Your sites can remain fast. You still get a lot of flexibility in terms of that.

The other thing that will, I think, also start happening is that you'll see a lot more frameworks similar to Redwood that are full stack JAMstack where it decides things for you so you don't have to make those decisions yourself because I do think that that is something that creates a lot of hesitation for people who want to get on the JAMstack that they have to make all these decisions and so on. Then the next thing, also, is that we'll hear more about various migration patterns of how people move to the JAMstack because I think, generally speaking, we don't hear a lot of that. You don't hear a lot of people being like, "I have this giant monolithic application and then I migrated to JAMstack." There are very few of those. I think we'll start seeing more of those in more solutions around how we can do that in an organic manner. That's just how I see it. It's a very optimistic look at the future.

Chris: Well, that's a nice place to wrap it up.

Dave: Yeah. Thank you, Divya, for coming on the show. For people who aren't following you and giving you money, how can they do that?

Divya: They can follow me on Twitter. I go by @shortdiv. That's probably the best way to contact me.

Dave: Awesome. You mentioned it, but JS Party, you're a frequent host on that.

Divya: Definitely. I'm also on JS Party very frequently as a panelist. It's a podcast I really love and enjoy being on. You should definitely listen to that.

Dave: My favorite episodes are the yep/nope episodes--

Divya: Oh, those are great. Yeah.

Dave: --where people are forced to argue both sides of some hot drama, so those are really great. Check those out.

Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShoTalkShow, for tons of tweets a month. And, if you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you. Chris, do you have anything else you'd like to say?

Chris: I'm server-side rendering. Result: ShopTalkShow.com.