Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris. How are you doing today?

Chris Coyier: I'm doing alright. Back in the booth here. Got my lazy butt up and moved over here. Yeah. Hopefully, my mic sounds pretty good. I used Adobe's new mic check tool.

I feel like you dreamed about this one time, Dave, where there would be a tool that would just do a gut-check, make sure your mic isn't screwed up.

Dave: Yeah, I saw they have it. I haven't actually tried it, so yeah. Just give me a tool to let me know if I sound stupid before I hit record. That would be awesome because when you find out afterwards (that you sound stupid)--

Chris: Too late.

Dave: --it's very bad, so.

Chris: [Laughter] We have a special guest on this week. I feel like we've talked about his blog posts for a number of different episodes recently - Brian Rinaldi. What's up, Brian? Thanks for joining us.

Brian Rinaldi: Thanks for having me.

Chris: Yeah. Right on. Otherwise known as Remote Synthesis. That is your URL. Wonderfully cool blog name.

Brian: Yes. Thanks.

Chris: Yeah. We had you on precisely for that reason. I feel like it came up. I think Dave, maybe, or it was circling around the Discord - or whatever.

Right at the beginning of the year, you blogged "What is Jamstack in 2023?" It was kind of one of those perfectly timed articles that had people scratching their chin and saying, "Yeah. What is Jamstack?" [Laughter]

You weighed in on it, but I wonder if you could introduce us to that conversation and thinking.

00:01:52

Brian: Yeah, so it's actually a post I've been doing. Obviously not in 2023, but I've done it every year for the past few years because, even in the Jamstack community, we've been debating it a lot ourselves. Even quite a bit of disagreement over exactly what it means.

I think there was a year where, every other day, there seemed to be a new event or something about what Jamstack means. And so, I kind of shared my thoughts, and they've been evolving a little bit, I think. I tended to... I'd be the one who I started with purely static sites.

Chris: Uh-huh.

Brian: I started with Jekyll a long, long time ago, and so my view of what this is has evolved too.

The latest one is more I've come to the conclusion. I mean it is vague. It's intentionally vague. It largely describes a community that uses a lot of similar tools. They range.

You can build a site a million different ways and make it Jamstack-y, but there are enough similarities there that I think the term is still valuable. I kind of noted that you can read a post about Jamstack or go to a Jamstack event - or whatever - buy a Jamstack book, and you kind of know, more or less, what it's going to talk about. Obviously, there's some meaning there.

Chris: Oh, I could see that argument. It's almost like a vibe or something. Yeah.

Brian: [Laughter]

00:03:33

Chris: If we wheel it all the way back, the word didn't just come out of nowhere. It was invented almost for marketing reasons, right? Wasn't it Billmann - and whatever - the early Netlify days?

Brian: Yes.

Chris: That literally somebody ponied up $20 for a domain name and said that these three letters are JavaScript, APIs, and markup. That's literally what they said.

Brian: Yeah.

Chris: And that is going to be quintessential to what Netlify is. I don't know. It felt like a movement then.

It's nice to have a company that's kind of mission-driven, in a way, or has this philosophy on what websites can be. Then they build a tool around that. It kind of feels like they got their heads screwed on straight.

Brian: Yes.

Chris: That they're like, "This is a movement, and we're going to build this company around this thing." And it made sense at the time - even though there were people scratching their head, like, "What is the difference between JavaScript and APIs?" That's a weird one.

Then everybody thought M was Markdown forever, but really they just meant markup, like HTML. It just got a little convoluted.

You've been tracking this for a while and have worked in the industry quite a bit. When did it start to lose its - I don't know? Didn't it start...? It started strong, and then it was starting to--

Dave: I mean did it start strong, though?

[Laughter]

Dave: I feel like Hugo is Go, right? Already, we blew J. J is gone. [Laughter] Jekyll was Ruby, like, "Ooh, we lost the J already." Did it ever start?

Chris: Or was it only about the final website?

00:05:17

Brian: Yeah, and that's where I think the term, even initially, was super broad. What site isn't built with JavaScript, APIs, and markup? Even back then, it was not that uncommon that any site did that.

Even the J part has been a confusing aspect of it, the JavaScript part, because the original manifesto was entirely about client-side JavaScript. It was not about server-side JavaScript or, basically, about building the site with a JavaScript-based engine because, if you think about when it came out, this was in 2015 (I think it was) that the term was kind of invented. There weren't really very many JavaScript-based static site generators.

Dave: Right.

Brian: In fact, I used to give talks. Going back to about 2013 or so, I was giving talks on these topics because I got really into Jekyll and started learning all these different tools. I even built a whole GitHub repo where I was comparing all the different static site generators - at least the popular ones - and almost all of them were not JavaScript-based.

I would go to these events, and I'd get asked, "Oh, hey. You should give a talk about a JavaScript-based one because I want to build this in JavaScript," and I did build that talk. The net result at the time was, "Okay, here are your options. Please don't use any of them. They're terrible."

Chris: Hmm...

Brian: Gatsby kind of changed that.

Dave: Yeah.

Brian: Gatsby was the first one that really popularized building this with JavaScript and changed - even changed people's perception of the term because, suddenly, the J started meaning, like, "Oh, we have to build this with a JavaScript framework. Otherwise, it's not Jamstack."

Chris: Even this has lost me a little bit. Was it the fact that the tool that you called was written in Node - that kind of JavaScript?

Brian: No.

Chris: Or was it the fact that you authored components? It would be like card.js. [Laughter] It would be like rights.

Brian: Basically, the idea was that you were generating static sites. At the time, it was purely static sites. There was no static site generator that had server-side rendering. Netlify didn't support that. There were a couple of Netlify competitors, but none of them supported that. It was just basically a pipeline for generating static sites.

The way you added interactivity to your site was with client-side JavaScript that actually called out to APIs and other services and then added that interactivity. So, I could add auth to my site, or I could add dynamic content to my site. But that would all have to happen client-side because the entire thing was static deployed to a CDN. Obviously, that's a big part of what's changed.

Chris: Right. Firebase was there at the time kind of helping with that.

Brian: Yeah, exactly.

00:08:10

Chris: Even the ShopTalk Show job board was just a jQuery call to a JSON thing that spit out jobs, and we formatted them to look nice. That was the job board. There was no SSR there or anything. Yeah, interesting.

Okay, so there was a whole era of that, kids.

[Laughter]

Chris: Didn't Gatsby always have... like early Gatsby days, did it have client-side routing, though, or not?

Brian:Yes.

Chris: It did.

Brian: It was client-side routing. They didn't add anything server-side. Gatsby, until, I think, Gatsby 5, had no server-side rendering. It was still a static site generator. Everything that happened interactively was happening on the client.

Next.js was really the one who kind of started this bit of identity crisis in the Jamstack community because suddenly you could do server-side rendering and you could do static and you could kind of pick and choose on different routes.

Now it's gotten even way more complicated with, like, okay, different types of rendering. There's ISR, DSG. I can't even keep track of all the acronyms myself and I follow this way too closely. To the degree to where I even have now -- now my presentations are already like understanding rendering in the Jamstack because here are all the different ways you can render stuff, and it's gotten really confusing.

Chris: I totally agree. It's almost like the guy who writes the article had to in order to wrap your mind around it at all. I feel like good luck even just--

It's great that those articles exist, but it's like: Oh, my God. You almost have to slow down and do it yourself to understand.

It's true. There's the ISR, right?

Brian: Yeah.

Dave: Was the one that sort of was like, "Ooh, this doesn't exist in the cache yet so I'll build it really quick."

Then there's SWR, which was supposed to be in a similar bucket, but was like, "We'll serve you a stale copy and then regenerate it in the background so the next person doesn't get it." [Laughter]

Those are so similar, but companies had to fight over the acronym to make it sound like they were the technological innovators behind all this. It was such a silly time there for a minute.

00:10:32

Brian: Yeah, there was. I think there were three or four different acronyms that all essentially were the same thing. They had slight philosophical differences that I felt were so slight that, to the average user, it was like, "Um... I didn't even know. I can't differentiate these two things at all."

Chris: Mm-hmm.

Brian: You had to really dig into the details.

Dave: ODB.

Brian: Yeah. It didn't matter.

Dave: On-demand builder. Not old-dirty. [Laughter]

Brian: [Laughter]

Chris: All right, but was there any middle phase there? It feels like we went right from Jekyll, which it almost certainly has no JavaScript at all on the final build of the site unless you put it there, like a script tag that loads your jQuery or whatever.

Brian: Right.

Chris: Then we jumped to Gatsby (and probably Next and stuff in there) that shipped with the JavaScript bundle. Not only were you authoring in JavaScript, but it had JavaScript, too, which gave you this opportunity. I don't know. It almost invited you to, for example, hit APIs and such.

Brian: Yeah.

Chris: Moreso because you're already in this authoring environment of JavaScript. Then it's got this router sitting there client-side, which some people like and probably to this day because it makes clicking around the website have that no page spinner feel. An SPA, as we've called it - one of my least favorite acronyms that has just taken absolute hold in this industry.

Can you imagine being a beginner in this industry and be like, "We're going to build an SPA." What does that mean? "A single page app."

Then having their brain be like, "Oh, I see. Like a page, a website that only has one page then?" No, no. It's totally irrelevant to how many pages are on the website. You're like, "Why did you call it single page app then, you dorks?"

There are still SPAs that are Jamstack, right? I think that lost some people.

Brian: There is, and now there's a big movement to, you know, we have to add the new acronym to MPAs, which was kind of your traditional model. It's like, it has multiple pages.

But there are new tools that are kind of leaning into that. But yet that's where I think we've kind of gotten a little lost in Jamstack. This is my personal opinion. This is not obviously the Netlify position. I don't work for them. I don't represent them.

I thought it kind of got lost. Things got a little confusing. We also -- we being kind of just the general developer community -- seem to kind of think that Jamstack meant I had to use React or Angular or Vue. That the J meant I was using a JavaScript framework. I had to ship a JavaScript framework.

Chris: Hmm...

Brian: It essentially had to be an SPA. I think we kind of lost site of the original intent of all of this which, if you think about when it came out, one of the things I loved about it was the simplicity. This was back to Web development that I kind of understood way back when I started building websites, which was 25+ years ago.

It was a model I could understand. It worked really fast. It was easy to develop. There were just so many benefits to it, and I could teach somebody how to do this really quickly.

I'm not criticizing Next, per se, about this. But I could not throw somebody into Next and have them learn this in a day or two. This is, to me, a multi-week project just to get you started building stuff properly with Next.

Yeah, that simplicity got lost, and we kind of lost sight of what I think the original intent of Jamstack was. And to be quite honest, as you mentioned, it was a marketing term. Netlify really controls what the definition is, and their definition has shifted along with the capabilities of the Netlify platform.

Dave: Hmm-hmm-hmm.

00:14:42

Chris: Yeah, exactly, because now they have this server-side rendering stuff, too. Then you're like, "Okay, this has really jumped the shark," or something.

Here are two extreme examples. Sometimes extreme examples aren't my favorite. But in this case, I think it demonstrates the breadth, which is a site that ships a div with ID of root on it. It's totally client-side rendered, but that shell, it's hosted on a server that has no Python, PHP, Ruby, Go, whatever.

There's no server-side language at all. It is a statically hosted index.html file. It just so happens that it only has one div on it with an ID of root and that React boots up, looks at that thing, and client-side renders all the rest of it. And it's got auth that's powered by cloud functions. It's got data that it's pulling from fancy APIs. It boots up a ten-million-page e-commerce site. It's just the most complex thing in the world.

But that index.html file happens to be hosted on Netlify. You know? So, it's Jamstack.

Or a website that's just like a brochure site that just has the soup of the day on it, but it's an index.php file and it's hosted on a PHP server. That one is not Jamstack. Even though the spirit of the PHP one is way more original Jamstack-y feeling than the other one.

Now you have these two examples with this huge breadth in between. To me, it demonstrates that Jamstack -- or it could. I'm not hardline taking this position -- is pretty fricken' meaningless.

Brian: Yeah. I'm not totally disagreeing with you. In fact, if you look at the Web Almanac that came out, the most recent one, Laurie Voss and Salma Alam-Naylor (both on Netlify, by the way), they did a chapter on Jamstack. Their definition would actually have included your index.php--

Oh...

Brian: --because it was more about ultimately what... They judged it based on some of the underlying goals, which is we're trying to deliver something fast and that performs a certain way. And so, part of that was driven by the fact that they only have certain data that the Web Almanac can analyze, and so how do you find what's Jamstack and what's not Jamstack (using the data that they had)?

Their focus was more on the outcomes as opposed to the tools that achieved those outcomes. In theory, that site could fall into that. I'd say the more official Netlify definition probably still would exclude that PHP site.

I tend to be... I worry a little bit about... Not as much as I used to, but the more mushy we make the definition, obviously the less value it has. If it's just Web development, then why even go there?

That's where I got to this kind of framing around there are a common set of tools. If you go to a Jamstack event, you're probably not going to hear talks about building sites with PHP and WordPress because that isn't the approach. But you will hear about using things like Next, Astro, or 11ty, and you will learn about tools like Algolia and Contentful.

Chris: Mm-hmm.

Brian: And whatever you want to use for auth and different tools like that. There is some commonality there in how we build things that is at least understandable on a general sense, even if I can't pin it down and say, "Well, this is how you build a Jamstack site."

When Ray and I actually wrote a book about this, Ray Camden, and I wrote a book about this recently, we kind of went with this approach that's like we can't tell you how to build the Jamstack site, so we're going to give you a bunch of different approaches and then explore some of the tools.

Actually, the book company didn't love this idea because they're more used to, like, front to back, this is how you do something from beginning to end. And we were like, "Okay, this chapter, we're showing you Hugo. That chapter, we're showing you Next.js. That chapter--" and we jumped around a lot. But the idea was there are a lot of different approaches. They're all equally valid.

Ultimately, a developer who is building a site, I don't care (in the end) if the end result qualifies as Jamstack or not. I think there are beneficial approaches within the overall architecture. But if I end up building a whole section of the site that's purely built in PHP and server-side rendered while the rest maybe is Gatsby, Hugo, Next.js, or whatever, it doesn't really matter as long as I'm doing what needs to be done and I'm delivering a good result. If it doesn't qualify as Jamstack, there's no authority out there. [Laughter]

Chris: Which it kind of can't because there's literally no definition for it anymore. But I know. I know what you mean.

Dave: I wonder if it was an anti-hero? You know? We had LAMPstack, very specific: Linux, Apache, MySQL, and PHP, right? Then people tried to do MEANstack, Mongo, Express, Angular, Lull. [Laughter] Angular is good now, I guess, and it has signals. And Node.

Chris: [Laughter]

Dave: I guess maybe Jamstack was sort of like, "Hey, it's JavaScript, markup, and we kind of don't care where your data is. We're not going to be picky about a database, and we're not going to be picky about... We'll just assume you use an API to go get that."

Maybe the vagueness worked. You know what I mean? In 2015, that term came around, so seven something years, eight years we've been talking about it. Maybe it just worked. I don't know. Maybe that was--

Chris: It was the hero we needed?

Dave: Yeah.

Brian: [Laughter]

00:21:07

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you by Frontend Masters. That's frontendmasters.com.

Hey, Dave. They're pretty good, right?

Dave: Oh, I'm a big fan - big fan.

Chris: Heck yeah. They're super. I don't know. They just run a good business over there. Lots of good learning material.

One thing you should do is click that learn link in the header. You'll be taken to their learning paths area, just /learning at Frontend Masters. This is what I was so envious of when I was running CSS-Tricks is that I never had course material that was like, "Start here. Do these things, and it will train your brain forward in this arena." CSS-Tricks was never good at that. It was more like a newspaper, just somewhere where you landed via Google or whatever. This is better than that.

[Laughter]

Chris: This is learning done right because there's this big SVG circle that fills out the percentages of finishing a course. It gives you that satisfaction of actually learning something, right?

Dave: Yeah. The way my brain works is it's so much easier to follow a course end-to-end versus piecing together 52 different blog posts, YouTube videos, and stuff like that, hoping I understand React or something like that. That's what I really like about Frontend Masters is it's taught by experts - everything like that.

Chris: Yeah, man.

Dave: It's great. And one of the most common questions on ShopTalk Show is, "What do I need to learn next - or whatever?" Well, there's your answer. There are 10, 15, 20 courses that you can just go through and just A to Z it. Go for it.

Chris: Yeah, dude. Frontendmasters.com.

[Banjo music stops]

00:22:51

Chris: I think Phil Hawksworth factors into this a little bit. I remember at one point there was a PR on the Jamstack website that decapitalized it.

Brian: Yes.

Chris: It used to be Jamstack, and then he lower-cased it. It was kind of a speculative PR. It was one of those, "Let's talk about this," kind of thing, and people weighed in and stuff. I remember that. That's probably worth linking up in the show notes if we can dig it up. It was interesting to see what people thought because, even then, the idea was like, "It's more of a vibe, yo, than the acronym itself," so I think that was kind of a strong move.

Brian: Oh, yeah.

Chris: But he had some other thoughts that maybe surfaced later that were like, "It's more about the decoupling of technology than it is anything else. It's more that I can produce these pages over here as part of a prerendering step, and I can use some other company for auth and I can use some other company for getting content or whatever." The fact that I'm plucking those things up and piecing them together, that's what Jamstack is, is that, the bucket that I put them all in.

Brian: Yeah, and that's now the official Jamstack definition is really about decoupling. In fact, I don't think it mentions JavaScript APIs and markup because, when he decapitalized that, it was essentially saying that we're not using the acronym anymore. Even though you'll still see all these articles come out, like, "Oh, JavaScript, APIs, and markup is kind of the intro to Jamstack," and it's like really not anymore. Even within the Jamstack community, we generally don't use the acronym as having any meaning anymore.

His idea at the time was that at some point Ajax meant asynchronous JavaScript and XML, right?

Dave: Mm-hmm.

Brian: And it was capitalized because it was an acronym. Then suddenly, one day Ajax was just a way of using JavaScript because there was no XML. It lost that. We took the capitalization out and made it not an acronym. It still had some meaning that we understood, but it wasn't specifically that stack of asynchronous JavaScript and XML.

That was the idea behind decapitalizing. I think now it is really just, as they say, about decoupling. That's where I agree with them on that take. I do think the decoupling is an important aspect of it. But I don't think... I can't tell that to a developer and have that mean much of anything to them, like, "Okay. I get it. Decoupling. Now, how do I build that?"

"Yeah. Okay, now we've got to get to specific tools." And every time I think about it, I'm like, okay, I could tell you that, but then ultimately, I'm going to lead you down a path that involves certain tools. Again, those tools tend to be common across the Jamstack community. There are a lot of them. But I could list you out the eight to ten tools that pretty much everybody is using as far as the static site generator.

Chris: Right.

Brian: Even that term now doesn't actually generate static sites anymore. We still use the term, right? [Laughter]

Dave: Oh, wow.

00:26:10

Chris: It's funny to me that Netlify doubled down on the Jamstack term. They still do. It's all over the homepage. That's fine. They should own that, probably. It would be kind of weird to abandon it.

But there was a little moment where I feel like Vercel was almost strong-armed into it. It seemed they've totally backed away from it now, which is also probably the correct move. But it seemed like, "Oh, man. Are we going to have to use our competitor's term?" Is it? I'm sure that they're like, "Woo! Glad we ditched that." I think they're happy to see that term kind of lose meaning and stuff.

Other services, too. I remember Microsoft used it for a minute with one of their tools. They were like, "Does everybody have to use this?"

I think of AWS Amplify, too, which was kind of a tool they kind of put out to jump in on this a little bit. You can use your own tools, but we should offer some kind of static hosting. I feel like a lot of companies wanted to get in on the static hosting thing because they saw how beloved Netlify was, even though it surely had just the tiniest drop in a bucket compared to anything that Microsoft or Amazon are doing hosting-wise.

They saw blood in the water - or something - and tried to change stuff. But Amplify is almost funny because if the spirit of it is decoupling, Amplify comes along and says, "Here's static hosting in the spirit of Jamstack. Only, we have everything you need. Do not decouple."

Brian: [Laughter]

Chris: "No decoupling! Use all--" Anyway. I don't know.

Brian: Yeah, it's true.

Chris: I don't think if anybody even cares anymore.

Brian: I was going to say, yeah, Microsoft went with their static Web apps as their term.

Dave: Mm-hmm.

00:27:48

Brian: I don't know that Vercel had a term. But more recently -- I don't know if you know Brian LeRoux.

Dave: Mm-hmm.

Brian: He founded this company named Begin. He's been pushing this idea for the past year or so of functional Web apps as an alternative term.

I understand his differentiation. It'd probably take too long to explain here, but it's also probably just as vague as Jamstack (in many ways).

Chris: It sounds like Leo Laporte jammin' Netcast down everyone's throat for 20 years.

[Laughter]

Chris: Only to have it do nothing.

Dave: Well, wasn't it also Rich Harris has transitional Web apps and stuff like that.

Brian: Yes. Exactly.

Dave: That's kind of a separate, different thing.

I'm thinking... Hey, I'm thinking here. Are we creating a problem for beginners? You said, "Oh, man. I want to do websites."

You're like, "Yeah, cool. You should just build a simple site."

"Cool. How do I build a simple site?"

Oh, you've got to build a Jamstack site."

Then it's like, "How do I build a Jamstack site?"

Well, there are 70 tools you've got to know. Start here."

[Laughter]

Dave: I mean, I guess, is the term so convoluted now, the idea of a simple or basic...? Because Jamstack doesn't mean simple or basic, really, because it can do so much now.

Brian: Yeah.

Dave: But I guess, have we ruined the entry point, I guess is what I want to ask.

00:29:31

Brian: I will agree with you, yes, we have, but I don't think this is a Jamstack problem. Personally, I think it's a Web development problem. There's not generally a simple way to teach somebody how to build a website other than maybe, "Just go grab WordPress and run the install process and move on from there."

But generally speaking, other than that, the whole process of Web development has become complicated. There are a thousand tools, and that's not a Jamstack-specific issue. I do think it's been a problem for Jamstack from day one because there was not any kind of... It didn't tell you how to build anything. It was always broad.

Even when the term was created, it was like, "Oh, you could use Jekyll. You could use Hugo. You could use Middleman." I can't remember what other ones were popular back then, but even when I was giving that presentation, there were 300 and something different static site generators. Not everyone was used, but there were still a lot of them that were used.

It was never prescriptive. It was always kind of complicated. Things have only gotten more complicated. But a lot of that complication, to me, is additional layers that have been added onto building just the general website. Whether you call it Jamstack or not, you're going to be sent a thousand different tools, and now we have to run it through build systems and so on.

Chris: It was so funny that all of them are like, "Well, we need to have search on our website." All of them are like, "Whoa! We don't have search."

Somebody is like, "Oh, we need to have somebody who can edit blog posts but not publish new ones."

"Whoa! We can't do that." You know? Just name a feature. They didn't have it, really. It was mostly like nerds building websites for themselves and then had to grow up from there.

Dave: But I do. I do think, big picture, it shook up the day-to-day how to build a website. I think, "Go get WordPress," was the answer to make a small site. You know?

Chris: Yeah. That needed a little jab, didn't it? As much as I love WordPress, to have that be the default answer was probably not super great for the Web.

Dave: I mean we made our podcast empire on that answer, but--

[Laughter]

Brian: Yeah.

Chris: But still, I think you're right about that. It changed expectations for a good way, like, "We should expect more out of what it's like to build a website." For example, I want to be able to have my deployment of a website connected to the Git experience. That changed in the Jamstack land. I should be able to look at a preview of what my website is going to be like before I accept a PR.

Dave: Hmm...

Chris: That expectation changed because of Jamstack. That's awesome.

Brian: Yeah.

Chris: That's great. [Laughter] Good job.

Dave: That's how GitHub makes all its money now is doing deploy previews. [Laughter]

00:32:36

Brian: Yeah. Yeah. I mean I think it did shake things up a lot. I love where we're headed right now. I think we've kind of went through a period where the tools got convoluted and complex, and where we weren't even delivering on the promises that it said.

One of the original ones were about it being fast. But if you actually looked at Jamstack sites, particularly because we started sending these giant JavaScript bundles, they weren't necessarily that fast.

We said they were more secure, but once you start doing everything server-side, it's arguably not more secure. In fact, the secure part is not even part of the benefits listed on the definition anymore.

But I do think we've turned a corner. I love the new sets of tools. Astro has me really excited. Svelte Kit, some of the stuff that's going on with 11ty, I mean these tools are actually becoming, I think, a mature version of what we wanted back in 2015. We took a big detour around just throwing lots and lots of JavaScript at people. Now we're coming back to a little bit of that simplicity with multipage applications, as well as, okay, we need to actually live up to the promises we made about performing well.

Chris: Yeah. That's great. It can be - I don't know.

Yeah, I think your larger point that - I don't know. I feel like you're agreeable in that it's a nearly meaningless term, as if you sit down with a piece of paper and try to write down what the criteria is, or a Jamstack checklist or something.

But you can shrug and be like, "I don't care that I can't do that because I still know what to expect at a Jamstack Conf. There's still something to it."

Am I saying this for the first time on the show? You called it (at one time) a community term.

Brian: Yes.

Chris: Right.

Brian: That is what I said.

00:34:54

Chris: It describes the community more than it does the technology.

Brian: Yeah, I think that's kind of how I feel about it right now because I can't pin down the exact definition of the technology. But like I said, it describes something meaningful in the sense of I can go to these events or I can join the Jamstack community or I can read a Jamstack book or I have a Jamstack newsletter, and I have a general sense of what the content is going to be about, the tools that it's going to include, and so on.

Chris: Mm-hmm.

Brian: It is more of a community term. That's where if we thought, I mean if we believed it was an architecture at some time, but people were like, "Oh, it's not really a stack. It's an architecture."

In a vague sense, maybe it still is an architecture. But it really is, to me, a lot of people using very similar tools who have a lot of overlap. And we can all kind of get together and share ideas and share how to use these different tools with other different tools, so on and so forth, and learn from each other. That's what it is.

I know that's a mushy definition, and it's even mushier than the official one. I don't expect them to go with my definition, but I do think that's the reality of it right now. That's why I don't get overly concerned with digging into the specific technologies that it means because I think it's okay. It's okay that it's vague.

A lot of terms are vague. What's serverless? Tell me what serverless is because it's really hard to define what exactly serverless is, too, right?

We're used to these terms. As they mature, they start adding capabilities, and they start getting new vendors, the term becomes less and less meaningful.

Maybe serverless started out vague. I don't know. But I do feel like it's even more vague now.

Chris: It was just Lambdas. We should just keep it at that. That's all it means.

Brian: Exactly. [Laughter]

00:37:16

Chris: Okay, here's another one. We'll move on just a smidge. We ask all our guests this question. Why the hell did Netlify buy Gatsby? That's weird.

Brian: Oh...

Chris: [Laughter]

Brian: That one is easy. I actually wrote a post about that one, too. [Laughter]

Yeah, so why did Netlify buy Gatsby? Because of Valhalla. And I can tell you from conversations I've had with folks at Netlify, even the leadership of Netlify, for a long time this has been something they believe is important that bringing together all the different data sources that developers have to use to build applications nowadays is increasingly complex and that there's a way to kind of unify those into a single backend for your application, even if I'm using all kinds of different services, APIs, and so on. I can actually bring those all together and not have to constantly recreate the wheel and have all kinds of different, like, I'm authenticating with this API and authenticating with that API and then calling out to their other API and making a mess of my code with callbacks and so on. You know I'm waiting for this API call to come back before I call out to this other API - kind of thing.

We can make one unified back-end. That's what they believed. They bought OneGraph, I think it was like two years ago, along these lines. They invested in another--

Chris: Which ran for like one year, right? It looks like they threw in the towel very much on purpose on that, being like, "Hmm... Maybe that wasn't something that we want to support," so why would Valhalla be something they want to support knowing that OneGraph was ostensibly a failure?

00:39:08

Brian: Yeah, I agree. I don't know their plans for OneGraph. I know you can't sign up for it anymore, so the NetlifyGraph, as they rebranded it. So, I don't know what the future is for that.

But, okay, OneGraph had an underlying problem, which was that any API that OneGraph supported, you basically had to get either the vendor or Netlify themselves to build that into the OneGraph. It had difficulty scaling up to all the APIs that you would use. Even then, it still has limited capabilities because we talked to companies.

I worked for StepZen, who actually got acquired by IBM recently. I wasn't with them at the time, but I was with them for a year a couple of years ago.

We had a similar type of solution. So, when you talk to people who use these things, they tend to actually be... They're using all these external APIs, but what's really important to them is they have a lot of internal APIs that also need to coexist with this. What good is a one back-end API source that only deals with my external APIs when I have all these internal APIs that I still need to integrate it with?

The idea behind Valhalla is it's any arbitrary back-end you can connect it to - in theory. It can be my internal APIs, and it can be external ones. They're all into that kind of mesh, as you might call it.

Chris: It's more magical. It requires no adapter or whatever? Is that the thing? Could you speculate that OneGraph needed the adapters, thus it was worse technology. They saw the writing on the wall. They saw they could maybe get their hands on Valhalla, which is a similar concept but technically better, and that we should shut down OneGraph and buy Valhalla, and that's the real future?

Brian: You know, more or less, yes. I think that's the case. Yeah. Valhalla, for what it's worth, is essentially a productized version of Gatsby's data layer, which has been around since Gatsby started. But they started to separate that out, so you could basically use the data layer as its own product to create that kind of unified GraphQL back-end for your application that brought in--

As you know, if you've used Gatsby at all, that was one of the beauties of it when it came out was, "Okay, I want to use this data source." I'll just plug that into the back-end and, suddenly, it shows up in my GraphQL API, and I can use that in conjunction with any other APIs or whatever other data sources that it connects to.

Even I might have a plugin that I could just say, "Hey, I want to use this data source," and there's a plugin for this, and it automatically configures it for me. It does the authentication and whatever else needs to be done to get it to work. That's essentially what Valhalla is, a productized version of that backend.

Dave: Mm-hmm.

Brian: Yeah. It is, I think, more scalable. It probably solves more solutions than just, you know, I have to work with a company to actually have that integration built (like OneGraph did). In this case, you could add your own. You can create your own.

Yeah, a better version, and I think it brings... Up to now, Netlify really hasn't been involved in the data layer. I think seeing them trying to target bigger enterprises, I think that's an important aspect of the application. Obviously, the data is going to be an important aspect of your application, so I can see how they feel like this is a way they need to expand to really meet the needs, particularly, I think, of large enterprises.

This probably isn't targeted -- and I'm speculating here -- at the individual developer building their small, little site.

Chris: Right. There's plenty of evidence that once you take a slurp of enterprise that you keep slurping it because there's so much money there.

Brian: Yeah.

Chris: That's a possibility. Interesting. Yeah, and they have stayed out of the data thing. It's been very interesting.

I think that's contentious, almost. That it just seems like such an obvious move. "Dude, just give me something -- a KV store or whatever -- to put a little bit of data." It would just open the doors wide open on what you could do using just their core tools, especially because you want them to do it because they've done such a good job of DX stuff.

Brian: Mm-hmm.

00:44:13

Chris: Having it all in-house would just be like, oh, seemingly so nice, but they haven't. That could be a philosophical move. You know?

I remember I talked to somebody at Netlify ages ago when Gatsby was at its peak. It turned out that a ton of what was on Netlify at all was Gatsby.

Brian: Yeah.

Chris: They were like, "Man, if they," I don't know "made their own Netlify, Netlify would be screwed." That was the feeling at the moment.

Brian: And that they did, and Netlify wasn't screwed.

Chris: Yeah.

[Laughter]

Chris: Well, I don't even know what it was. I guess they did make a cloud thing, right? I don't know exactly how it worked.

Brian: Gatsby Cloud, yeah.

Chris: I thought the selling point was more like, "You can see previews," than it was hosting. But maybe it was both. I don't know.

Dave: I think it was just expensive. [Laughter]

Brian: You've checked it out?

Dave: Well, if I recall. I can't really. I thought it was, yeah. Netlify's free, 99, you know. And it starts at like 42 or something for Gatsby. Anyway. I think that was just--

Brian: Yeah. Yeah.

Chris: In a way, you can't blame them because you took VC. Your thing is just an open-source front-end tool thing. How are you going to make money? You've got to do something.

Dave: I think it's, again, speculating about Netlify, but they have the "We build your site" layer. They have now the data layer. Maybe they don't need a database layer, but maybe that's easier now. Because if they would have made a database layer, it would have been like, "Well, that sucks because I still have to use - whatever - raw SQL to get it out." You know?

But now they're like, "No, we've got the layer," so maybe there's a future there.

Brian: Yeah. I'm interested to see where they take it and how they integrate it. I don't have any insider information. I'm just speculating, myself.

Dave: Matt, if you're listening--

Chris: Neither of them are public, right? We'll never find out what the price tag was, right?

Brian: No.

Chris: Because neither of them are public. Yeah.

00:46:28

Brian: No, they weren't. Yeah, I don't think we'll know. I think we are going to see a trend of these companies getting acquired - to be frank.

Chris: Yeah? Who is next?

Brian: Most of them, their valuations have been shaved in half (at least). From the standpoint of somebody who is looking for a potential acquisition, you've got lots of ripe targets. Not only that, but the fact of the matter is the VC market is kind of almost closed off. I had my valuation shaved in half and I'm running out of runway.

Chris: I'm for sale! I'm for sale! [Laughter]

Brian: Exactly.

Dave: I am for sale. Yes. Yes.

[Laughter]

Dave: I am for sale.

Chris: But isn't that driven more by who is buying than who is selling?

Brian: Oh, yeah.

Chris: I don't know.

Brian: For sure. For sure. But I think, in that one week alone, which seemed like a pattern that you had Gatsby get bought by Netlify and then StepZen got bought by IBM. All of a sudden, it was like, "Oh, wait! Is this whole GraphQL mesh API a whole big thing?" It's like, eh... I think it's just bargain hunting, in a way.

I do think, philosophically, with what Netlify was pursuing for years, Valhalla fits with that.

Dave: Yeah.

Brian: Obviously, it's got to be a fit. But I do think we all knew Gatsby was well off its peak. Let's be honest.

Chris: Yeah.

Dave: That wasn't a surprise.

This is a speculation. I do wonder how much investors are involved, too.

Chris: Yeah.

Dave: Gatsby is probably looking at the bank account like, "Hey, we're not going to make it very far." Then they're like, "Okay, let's do a seed round." Then another round, and then the investors are just like, "Hey, the best situation here is to sell."

The VC markets, IC, I think I read something; it's down like 42% or something like that.

Chris: It could have been a board call. Who knows.

Dave: It could have been a board call. Yeah. What if Matt is on the board? Oh, man. We didn't know.

[Laughter]

Chris: No.

Dave: Conspiracy. No, he's not.

[Laughter]

Dave: Matt, if you want to bring us three in for consulting, we're available.

Chris: Yeah. Yeah.

Dave: We could talk through all this. Yeah.

Chris: A little expensive now, but.

Dave: You can bring us in.

Brian: [Laughter]

00:49:07

Chris: I feel like once you're at this moment where you're like, "Okay, I'm going to have one API," and that one API can go get data. It powers my search. It's connecting to all these different sources. You're such an advanced website. That's needy. That's not a hobby project in any way. You've got a team. You're building custom stuff.

At the moment you've got a big team and you're building custom stuff, I don't want such a crucial thing to be, like, "I want to write that." That's a brick of this app that I'm going to write. I'm going to write my servers that connect to these things and do these things.

I'm not going to be like, "Oh, you know the glue that glues my entire application together? I'm just going to use this thing, just a thing that was given to me." I don't know.

Brian: Yeah, I think you've got a point. When I was with StepZen, that was one of the things we'd hear from developers when we'd reach out. To them it was, "Well, I don't know that I want to hand it over to you," number one. Number two, they didn't feel like it was that hard of a thing to build for them. I think we're so used to writing the code to call out to these APIs that it wasn't a big impediment to them.

Chris: Yeah.

Brian: At least at StepZen where we would see value, at least during my time there, was actually (funnily enough) in large enterprises that had multiple internal APIs. Oftentimes, those internal APIs were maintained by a bunch of different teams who really weren't in communication.

Like me even as an internal developer trying to use our internal APIs became a complicated mess. Then they were like, "Well, we want to try and unify this. But building a project to unify that internally would be complicated, so can we just use your service?" To then, why are all these things together internally? Give us one back-end for all our internal APIs.

Dave: Hmm...

Brian: I don't know that that is necessarily where Netlify is going because I would suspect theirs is a little different. But that was one use case.

I was like, "Okay. That actually kind of makes sense to me," and I could see why they'd want to do that because it was cheaper and easier in many ways than a project trying to unify the existing REST APIs as they were.

Dave: You would think... You hope people are very deciduous about what data they have and where it's stored. But the reality is that's not how it works.

It's like marketing just bought Contentful - or whatever. But we had a WordPress, and then we had, you know, somebody wrote their own database - or something like that. These abstractions on top probably are pretty useful.

Brian: Yeah.

Dave: Yeah.

00:52:07

Chris: Well, we're not totally done yet. We've got to wrap up pretty soon. Everybody should subscribe to remotesynthesis.com. It's got an RSS feed. Heck yeah.

The takes have been delicious and spicy over there and interesting topics. We could get into this whole idea of the fact that developer conferences are still down 40% (post-pandemic). That's a crazy thing to talk about, and I think you're about right.

Your most recent, "Can Dev Rel Be Done Without Twitter?" which is incredible. Obviously, that was the epicenter for all conversation that's dying out faster than can be.

You seem to be the one writing about these things, so good job. Keep up that. are there any comments about either of those you want to make in our last few minutes here?

Brian: Oh... First of all, I appreciate that. I'd say, also, I never gave up on RSS. [Laughter]

Chris: [Laughter]

Brian: I'm glad to see it's come back around. [Laughter]

Yeah, particularly the events one, the developer conferences one, resonate. I mean that one kind of went crazy, and I wasn't really anticipating that. But it seemed to resonate with a lot of people because both people who run conferences and people who attend them and the people who sponsor them and so on is that there's definitely something not right in the current state of conferences.

When you see great conferences like An Event Apart -- and that's just naming one, but there are a lot -- just kind of calling it quits, you're like, "Okay, something is not right here."

I just finally decided to write that after about a year of just talking to people since events opened back up and saying, like, okay... People were like, "Okay. It's eventually going to come back in fully, right?" It just never did. Things just didn't seem right, and conference organizers were more stressed out than I'd ever seen them.

This is already a naturally very stressful job to take on is running a conference. They were even more stressed out than ever because it was harder to get people to come. It was harder to make any money off of it.

To be clear, I'm talking about not like the big conferences run by corporations. These are more like your independent or community-type conferences. I just worry because those, to me, in my career--

Chris: If you had to guess, in the middle of the pandemic, wouldn't you have said, "Oh, it's going to be crazy when the pandemic is over. This is going to come back. They'll be twice as big"? That would have been an easy prediction during it.

It's so strange that now it's just absolutely not the case at all.

Brian: Yeah. Yeah, I mean here we are. They've been open for a year and a half, and we're still not seeing the attendance that was there pre-pandemic.

Chris: There's something going on. It's not just people being like, "Oh, I'm still a little afraid of the pandemic." Yes, that's happening. There are some of those people. But there's no way that that's enough--

Brian: Yeah.

Chris: --to account for the downness.

00:55:29

Dave: I think you had a good notion in your post. You were kind of like, "You know 60% of people come from the content, 50-60% of people come for content." Right?

The acceleration of online-ness, I think, in the pandemic, you know, I can get the content better. There are better ways. I felt like that during all of my online conferences.

I would actually wait until the conference is over, and then I would watch the live stream at 2x and power the whole day in three hours versus sitting on my computer for eight hours. I mean it was maybe two hours if I'm skipping breaks and stuff like that.

I feel like there are better delivery vehicles for content right now, but you miss that camaraderie, which is also why I go to conferences to - whatever - get lost in a city with Internet friends.

Brian: Mm-hmm.

Chris: It was so funny how it had to be both, right? People would talk about, like, "Ah, screw the conference. We should all just get together and go eat barbeque or something." That's a great idea, but nobody would ever do that. You know? You can't.

Dave: Nobody does that. Yeah.

Chris: Nah, you've got to have somebody--

Dave: A pretense?

Chris: A pretense. Somebody has got to pretend to talk about JavaScript for a minute, and then you can go eat barbeque together.

Brian: Yeah. Plus, I need to convince my employer to pay for it, so. [Laughter]

Chris: Yeah, right.

Brian: So I can come hang out with you.

Chris: That's the bigger--

Brian: [Laughter] Yeah, which is, honestly, that's how most people pay for it.

Chris: Yeah. That's--

Brian: Yeah.

Chris: Everybody is working from home. The employers are like, "Your whole life is a conference!"

Dave: Yeah, basically.

00:57:05

Brian: [Laughter] Yeah. Yeah, and you know. Dave, to your point, it's true. This is what I think happened. Even what people watch - because I run a lot of online events as well. I've been running them for like 5.5 years, so well before pandemic times.

The behavior of people has changed even on that. The people who now go to these online events, most of them aren't attending live. They're watching the recordings. And often shortly after the conference ends or the event ends, they'll go watch the recordings at (I'm assuming) 2x or something like that. I'm getting a lot less live attendees but a lot more video-watching. Yeah, it's--

Dave: You know we had joked about it poorly at the An Event Part conference because we were like, "Oh, video is probably too expensive." Now it feels like a bad note.

But I think, for a live conference to also have video that you either monetize or put online, YouTube with commercials or something, that's maybe a great way to extend the life and revenue of your conference. I don't know. I hope people do that more.

Brian: There are people trying different ways of that. There are some complications. It can be very expensive to video the live conference. I've seen even people doing... We have a virtual version and the live version, and they're actually independent, kind of one runs one week and then the next week, we run the live version.

Chris: Hmm...

Dave: Hmm...

Brian: We're going to see people trying new things, I hope. Hopefully, we land on something that really gets this going again because these events, part of why I wrote this was like these events played an important role in my career. They were important to my development, not just in terms of the content, the things I learned, but the people I met there. And so, seeing them go away is just sad to me because I feel like it's an opportunity lost, particularly for people who are new to the industry, to get that information and meet those people who are going to have a big impact on their careers. Maybe that's where they find their next job. Maybe that's where they make a connection to get on the ShopTalk podcast. [Laughter]

You know I think they have an important role to play. And it's not going to be the re:Invent or the Builds or these gigantic corporate conferences. I hardly meet anybody there, to be quite honest, unless I already know them and we coordinate to meet. It's not the kind of place you meet people. You meet them at these smaller, independent conferences.

Dave: You've got my brain gears turning, so I'll have to revive the ShopTalk Conf idea. [Laughter]

[Laughter]

Dave: Maybe when I'm a billionaire. But anyway, Chris--

Chris: Yeah.

Dave: Yeah, we'll do it. We'll do it.

Well, Brian, thank you so much for coming on the show. For people who aren't following you and giving you money, how can they do that?

Brian: Yeah. Chris mentioned remotesynthesis.com is my blog. You can also find a link. I'm not really on Twitter anymore, so you can find me on Mastodon. Basically everywhere, I'm @remotesynth. That would be the easiest way to reach me.

Dave: Be sure to pop that blog in the RSS. It's been poppin' off this year. I feel like I had to read blog posts for this show because I was just like, I kept queuing them up in my "read later." But anyway, thank you so much for blogging. Appreciate that.

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, @ShopTalkShow, for zero tweets a month. Or, da-da-da-dah, we have a brand new @[email protected] over on the Mastodon.

Chris: Yeah, we got a Mastodon, finally.

Dave: Yeah.

Chris: Yay!

Dave: They let us on there. That's great, so you can follow us on Mastodon.

Chris: Mm-hmm.

Dave: There'll be at least tens of toots a month. Yeah.

Chris: We're up to one, so.

Dave: We've got one toot so far.

Chris: Pretty good. Yeah, that's what it says.

Dave: We're doing pretty good. And, of course, you can join us in the D-d-d-d-discord, patreon.com/shoptalkshow.

Chris, you got anything else you'd like to say?

Chris: Oh, ShopTalkShow.com.