Live September 2022
JavaScript Jam Live discusses the new Enhance web components framework, the framework-platform business model, and whether Heroku is dead.
Episode Description
JavaScript Jam Live discusses the new Enhance web components framework, the framework-platform business model, and whether Heroku is dead.
Episode Summary
This JavaScript Jam Live episode from September 2022 opens with a discussion of Enhance, a newly released framework from the team behind Begin that focuses on web components and leveraging native browser capabilities rather than heavy tooling. Anthony Campolo and Ishan Anand explore how Enhance compares to Lit and Eleventy's web components support, then step back to explain what web components are and why adoption has been slow — touching on shadow DOM limitations, server-side rendering challenges, and the self-fulfilling cycle of low usage. The conversation shifts to a broader analysis of whether frameworks need their own hosting platforms to succeed, using Begin, Vercel/Next.js, and Gatsby as case studies. Theo joins briefly to argue that Gatsby's decline stemmed from architectural overreach — particularly its GraphQL abstraction — rather than its cloud platform. The final segment tackles whether Heroku is dead following its elimination of free tiers, with Danny offering insider perspective from his time at the company and the group debating why Heroku never transitioned into enterprise. The discussion threads together around a central thesis from Ishan: frameworks drive platform demand, not the other way around, which shapes how companies like Edgio approach supporting the ecosystem.
Chapters
00:00:00 - Introduction and Show Welcome
Scott Steinlage opens the Wednesday edition of JavaScript Jam Live, welcoming the audience and encouraging listeners of all experience levels to participate. He emphasizes that the best conversations happen when audience members raise their hands, ask questions, or share opinions directly on stage.
Co-host Ishan Anand joins and sets up the day's agenda, noting that while they have prepared topics, the show aims to be as listener-driven as possible. He introduces the first topic of the day: the release of Enhance, a new JavaScript framework focused on web components that caught the community's attention during the week.
00:03:30 - Enhance Framework and Begin's Web Components Bet
Anthony Campolo provides context on Enhance, identifying it as a project from the Begin team built on their existing Architect infrastructure-as-code tool. He explains that Brian LeRue and the Begin team have long advocated for writing HTML and using the web platform directly, and Enhance represents their effort to package that philosophy into an accessible framework with a proper developer experience.
The group discusses how Enhance fits alongside other web component efforts like Lit and Eleventy's new Island feature. Anthony speculates that Zach Leatherman built Eleventy's web component support partly in response to the third-party Slinkity project, which brought React, Vue, and Svelte into Eleventy in ways he didn't prefer. The conversation touches on the growing trend of static site generators wanting to slot in components and partially hydrate them, following patterns popularized by Astro.
00:09:45 - What Are Web Components and Why Haven't They Caught On
Ishan steps back to explain web components for less familiar listeners, describing how frameworks like React and Angular introduced reusable, isolated components but required significant tooling to achieve that isolation. Web components offer browser-native APIs — including custom elements and the shadow DOM — to accomplish the same goals without external frameworks, and they now ship in every major browser.
Anthony adds context about the political dynamics, noting that web components have been primarily driven by Google and have suffered from a chicken-and-egg adoption problem. Enterprise teams building internal tools have shown the most interest because browser standards offer long-term stability without framework version churn. The discussion highlights how the "year of web components" remains perpetually next year, though new frameworks like Enhance may finally shift that narrative.
00:16:00 - Server-Side Rendering Challenges with Web Components
Ishan shares his firsthand experience from 2018-2019 trying to use web components with Lit for a progressive web app, where the team hit a wall with server-side rendering. The shadow DOM's dynamic nature made it difficult to serialize component state into raw HTML for initial page loads without running JavaScript, a problem that React avoided by rendering to standard HTML.
Anthony points out that Enhance appears to address exactly this gap, expanding custom elements on the server and setting up documents for progressive enhancement. The group agrees this should be more prominently featured in Enhance's marketing, as solving the SSR problem for web components is a significant selling point that could genuinely move adoption forward.
00:21:30 - The Framework-Platform Business Model
The conversation broadens to examine whether successful developer platforms need their own frameworks. Ishan observes that Begin's pivot mirrors the Vercel/Next.js model — a company tying its hosting platform to a full-stack framework it controls. Anthony notes pushback against this model, pointing to Netlify's approach of working with every framework rather than building one, and arguing that Gatsby Cloud's struggles show the risks of tight coupling.
Theo joins briefly to argue that Gatsby's decline was driven by architectural decisions like forcing GraphQL into simple use cases, not by the cloud platform itself. Ishan synthesizes the discussion into a thesis: framework popularity drives platform demand, not the reverse. He shares how this plays out at Edgio, where the team debates whether to build their own framework or focus on best-in-class support for existing ones, ultimately choosing the latter to serve customers where they already are.
00:31:30 - Frameworks as the Instrument of Demand
Ishan expands on his thesis that frameworks are the primary conduit through which developers adopt new technologies. He cites React server components, where the React team explicitly told developers to wait for their meta-framework to support the feature, as evidence that meta-frameworks mediate developer adoption of platform capabilities.
He also discusses Google's Aurora project, which aimed to improve web performance by working directly with meta-framework teams rather than targeting individual developers. The collision between JavaScript-heavy frameworks and Google's push for faster sites has resulted in Google funding framework improvements, reinforcing the idea that frameworks are the leverage point for ecosystem change. The segment also touches on Edgio's experience being among the first outside Vercel to support Next.js features like incremental static generation.
00:36:00 - Is Heroku Dead?
Following Heroku's elimination of its free tier, the panel debates whether the platform is effectively dead. Anthony argues he would no longer recommend Heroku given alternatives like Railway, Render, and Fly that offer better products at comparable prices. Danny, who previously worked at Heroku, provides insider perspective, noting that Heroku remains popular in the Rails and Laravel communities even as JavaScript developers have moved on.
The discussion examines why Heroku never made the leap to enterprise adoption, with Danny attributing it to an engineering-first culture that neglected ops teams and their need for flexibility. Kyle and others connect this to broader trends around serverless frameworks and containerized deployment gradually filling the gap Heroku once occupied. Ishan references a Twitter thread evaluating Heroku's legacy, noting that despite its business limitations, it catalyzed the entire dev-tools venture ecosystem through projects like Heavybit.
00:48:00 - Serverless, Containers, and the Power User Problem
Anthony describes the ongoing convergence of serverless and container-based deployment, drawing on his experience with Redwood where the team discovered that pure serverless didn't meet all user needs. He explains how containerized lambda functions and improved Docker DX have made the two approaches nearly indistinguishable when frameworks handle the abstraction layer.
Brontify and Kyle bring up the idea of custom runtimes and tailored container environments, discussing how power users and larger organizations might benefit from building their own deployment tooling. Danny points out that team size fundamentally changes which tools make sense, and Ishan ties the conversation back to Theo's composability summit talk, which graphed how different technologies suit different team scales. The episode wraps with Scott thanking all participants and encouraging audience engagement for next week's show.
Transcript
00:00:00 - Scott Steinlage
All right, super exciting stuff here. Today is Wednesday, September 7th. Can't believe it's September already. 2022. Crazy, crazy, crazy. How does time fly? Yep, summer's coming to an end. The fall is beginning, y'all.
00:00:25 - Scott Steinlage
Welcome to JavaScript Jam Live. We're here every Wednesday at 12 p.m. Pacific Standard Time.
00:00:38 - Scott Steinlage
we talk about all things JavaScript, obviously, as well as really anything in web development too.
00:00:51 - Anthony Campolo
Anthony, what's up?
00:00:52 - Scott Steinlage
Welcome. Gonna have several people coming in today, as always, to join in on the fun.
00:01:01 - Anthony Campolo
Oh, there we go.
00:01:02 - Scott Steinlage
Invite. Ishan is a co-host there.
00:01:07 - Anthony Campolo
What up? How goes it?
00:01:11 - Scott Steinlage
Hey guys, I was just finishing up the intro here.
00:01:15 - Anthony Campolo
You can say anything we want,
00:01:19 - Ishan Anand
us and everybody who listens after this.
00:01:21 - Anthony Campolo
Right.
00:01:24 - Scott Steinlage
But let me finish up here. So, yeah, thank you all for joining us today. Greatly appreciate it. More than anything, though, if you're a beginner at this, if you've been doing this for a very long time, and what I mean by this is being a developer or learning to be a developer, then we want to hear from you, no matter who you are. It doesn't matter. In fact, that's when we get the most value out of things and have some of the best conversations, when the audience is partaking in these conversations with us. Whether you have a question, you can feel free to request to come up and speak, and we will allow it to happen. In fact, we encourage it. And if not just a question, maybe you just have a comment or an opinion, whatever. Feel free to come on up, and we'd love to hear from you. And Ishan is in the house today. He is our co-host here for JavaScript Jam Live.
00:02:39 - Ishan Anand
Welcome.
00:02:39 - Scott Steinlage
Ishan, thank you for joining us. How are you doing?
00:02:43 - Ishan Anand
Good, good. Thanks, everyone, for joining us. So there were a couple things I put into our usual doc on things that came up this week, but as Scott said, we like to be as listener-driven as much as possible. But the top of the list was it's another week, another new JavaScript framework came out, and this one was called Enhance, which is interesting. A focus on web components and using the platform instead of miles of tooling. Actually, a bunch of people had quick rundowns of the highlights, I think either in the newsletter that went out or will go out. I linked to Jason Lengstorf's list. It's got kind of what you might expect from a Next.js-influenced framework, but really focused on web components. So it's got file-based routing, HTML as the native templating language. You're basically building native custom elements. You don't need a transpiler. You've got single-file components, which those folks who come from a Vue background will appreciate. First off, actually, I think, Anthony, I...
00:04:12 - Anthony Campolo
Question for you: do you know who the creators of the framework are?
00:04:18 - Ishan Anand
Sounds like it's the guys from Begin. Is that correct?
00:04:22 - Anthony Campolo
Yeah, exactly. It was funny, I have a buddy, Ben Myers. He sent me a link to it and he was like, "I'm talking to these people about getting them on my stream for this new framework." And he showed me the docs, like, this is interesting. I was looking through and I saw you could deploy it to Arc with Architect. I was like, "Architect? That's really interesting. I don't usually see that in people's docs." Architect is the underlying framework that the Begin platform is built on. So then he was like, yeah, here's the blog post announcing it. It was on Begin. Like, oh, so this is Begin making a web components framework. And that framing is much more interesting to me because Brian LeRoux has been tweeting forever about how you should just write HTML and use the platform, but then render the platform in a Lambda function and serve it. And so that's kind of his whole deal. I think this is them showing how you can actually do that with a front-end framework instead of writing it all yourself, which everyone admits is not a sweet DX.
00:05:24 - Anthony Campolo
So I think it's great. I think it's kind of a putting-their-money-where-their-mouth-is moment for them.
00:05:30 - Ishan Anand
Yeah, I mean, there's a whole greater context, which is, you know, Begin has been around for a while, and I know they said they're launching a new Begin. Do you want to give us a little bit more context on that?
00:05:43 - Anthony Campolo
So I don't know anything about that. What's funny is I got into Begin like two years ago, actually, when I was first getting into serverless functions and Lambda and deployment platforms at all. I thought it was interesting and really cool and different, but then it eventually became clear to me that there was a lot more stuff happening around containers and that kind of stuff. So I kind of went more in that direction because basically it was the question of, like, what can we run Redwood on? That was kind of what drove my interest in platforms for a very, very long time. You couldn't really run Redwood on Begin because it just didn't quite work right yet. So I kind of stopped paying attention for a while. But I always would recommend it to people if they wanted just a really, really clean abstraction on a tiny set of the best AWS services. Because that's also Brian LeRoux's pitch: you don't need all of AWS. You need a tiny, tiny subset of AWS. So he built an extremely concise framework and syntax and infrastructure-as-code thing just for those services, which is cool.
00:06:54 - Anthony Campolo
But it wasn't really something that made sense for me at the time and what I was doing. So I kind of fell off following it for a while. I wrote some blog posts about it, but all this was well over a year ago.
00:07:07 - Ishan Anand
Got it. What are your thoughts? We can get back to Begin in a second. What are your thoughts on the framework itself, if you've got any? Or do we need another framework, and do we need one that's web-components-based? Every year it feels like the year of web components is always next year.
00:07:23 - Anthony Campolo
Yeah, I feel like stuff like this is going to actually move the needle for web components in a very real way, the same way that Lit has for me. I'm curious, how does this compare to Lit? How does this compare to... now Eleventy has a web components implementation called Island, a play on islands. So I think now there's like three framework/web-component kind of things out there, which means they can push each other to get better. Web components can get better. I think it's good. I've not been super gung-ho about doing web components, but I like the idea of using the platform, and I want to be able to use web components the same way I could use these other frameworks, have the same kind of experience. So I think it's good. To me, I could learn new JavaScript frameworks all day. I find it really interesting. And I think there's usually a handful a year. So people complain about how there's a new one every single week. A framework like this I think comes around maybe once every six months, you know? So I don't know, read through the docs, build a hello world example, you might learn something.
00:08:30 - Ishan Anand
Yeah, actually I was going to bring up Lit, because that is the other best-known web component framework. I wasn't aware Eleventy had added the Island.
00:08:47 - Anthony Campolo
Yeah, it's very new. And it's probably because someone had invented a whole Eleventy meta-framework called Slinkity that let you hack React and Vue and Svelte components into your Eleventy projects. And Zach Leatherman does not like those frameworks, so he didn't really promote that at all. So he was like, well, people want to do this. I don't want them to do it this way, so I need to build my own thing. This is me also speculating as saying these things publicly. It's just me as a fly on the wall. But yeah, that one's pretty new still. It's only been a month or two, I think.
00:09:20 - Ishan Anand
Oh, interesting. So are you referring to him doing that to kind of replace Slinkity, so to speak, or am I misunderstanding?
00:09:29 - Anthony Campolo
Not necessarily just replace Slinkity so much as he sees this is the right
00:09:34 - Ishan Anand
way to do it.
00:09:34 - Anthony Campolo
Sorry, he sees where the puck is going. He sees that with things like Astro especially, people want static site generators that also can slot in components very simply and then partially hydrate them.
00:09:46 - Ishan Anand
Okay, that makes sense. Maybe we should back up and explain to those in the audience who aren't aware what the difference is with web components and why you would want to use them.
00:10:03 - Anthony Campolo
I think you'd actually be the best one to give that. I could make an attempt, but you probably know more about web components than me.
00:10:11 - Ishan Anand
I'll attempt it, and I'll throw the second part to you. Although I'm happy to offer my thoughts, the second part is going to be what's been holding web components back. Let's back up. The big change with a lot of these so-called modern frameworks, the Angulars, the Reacts, the Vues of the world, was that when you built your website, you broke the pieces of that page into these reusable components, whether it was a button or whether it was a card. Each component could have subcomponents, but the key property of your components was that you got a certain isolation of behavior and styling, and you knew that component was the same no matter where you placed it. If you think about a regular, let's say, button HTML element, it can get changed depending on the context of where it's in. The CSS of the parent might interfere with it, and it didn't necessarily have behaviors that were co-located directly into that button, so to speak. The way to think about this is you are basically given the ability, when you use one of these tools, to create your own element. Like, if you create a card element in React or a Card component, you're basically creating a custom element.
00:11:34 - Ishan Anand
But what React does under the hood, or your tooling does, is it helps create the reusability and the isolation between your component and the other components on the page. What web components does is it says you don't need all that tooling. You can essentially get the ability to get that isolation for your components and that reusability natively in the browser. Somebody said, why do we need frameworks to do this? Let's just give people the ability to create their own version of div, span, button, whatever. And we'll give them the same controls to isolate their code the same way the platform natively does with other components. That's what web components are. It's essentially using features that are shipping now in every browser today to let you create your own version of HTML elements. That was off the cuff there. Anthony, anything you think I left out?
00:12:35 - Anthony Campolo
No, I mean, I thought that was pretty good. I think there's also larger contextual things about who's creating them, who is pushing them, who is kind of pushing back on them. It seems like a thing that's mostly been driven by Google. I think Google has always had a hard time with open source, so that probably hasn't helped. But they're also really deep into the standards because they obviously control the browser to a very large extent. So I think they wanted it because they wanted something that would be built into the browser, but they had a hard time. And this goes back to your question, why haven't they picked up? I think they had a hard time really convincing people to use them. So then you have a self-fulfilling prophecy. No one uses web components, they don't ever get better, no one wants to use them because they're not very good. And then you also kind of can't say, "Don't use a framework, use the platform." But then really they still needed people to build web component frameworks, as we're now seeing with things like Enhance.
00:13:32 - Anthony Campolo
So I think if they kind of lean more into the idea of, like, hey, you can still use a framework because it seems like developers want to use a framework, but you can use a framework that uses web components, I think that's where it's starting to make more sense to people and becoming an easier sell.
00:13:51 - Ishan Anand
Yeah, where I've noticed it be an easier sell is when I talk to, strangely, enterprise internal web app tools. Those folks know that whatever tool I build, if it works, nobody touches it, and they want something that's going to continue to be supported as much as possible. So interestingly, they look at that as the most future-proof in the sense that it's not subject to the vagaries of, I don't know, we're on Angular 1 this year and now it'll be Angular 20, or React this versus React 18, and we have to worry about continuing to maintain it and update it. They just know that, hey, this is now a browser standard. It'll continue to be the same moving forward. That's actually one of the places I've seen it seem to pick up traction, or at least interest.
00:14:51 - Anthony Campolo
Yeah, that makes a ton of sense. And that's why we want standards in the first place, because standards will hopefully stay the same and we can align on them and then build stuff together on it. So I think that all makes a ton of sense. And yeah, I think it's also just because there's so many frameworks already, everyone already kind of picked a side. So you had to make a difference. You had to make a certain pitch to each person depending on what framework they were using. And some of them are better positioned against web components than others.
00:15:21 - Ishan Anand
Yeah, it's interesting. So I'll tell you the places I've seen it actually fall down. I was part of a team that, man, was this 2018 or 2019, maybe even earlier than that, was trying to use Lit and other tools for a PWA, back when that was a big important thing that was top of everyone's tongue. One of the problems, for example, we ran into is that there wasn't a good way at the time to do server-side rendering and then hydration with web components. The reason for that gets into this thing that with web components, part of giving you the ability to do that isolation I was talking about means giving you access to something that the browser creates called a shadow DOM. Normally there's a DOM, a document object model it creates for everything on the page, but there's another one called the shadow DOM that's used in creating that isolation when you create web components or use web components. That's being used dynamically in the browser, but there's no way to serialize that out in a way that, when it gets first displayed back to the browser as raw HTML, it's able to populate the shadow DOM without running JavaScript.
00:16:48 - Ishan Anand
That was, for example, on first load. Performance was one of the areas, and server-side rendering was an area we ran into. A framework like React just uses regular HTML as what it serializes its output to, and so that was more possible. I don't know if they've actually fixed that with web components or not, but...
00:17:10 - Anthony Campolo
It seems like what something like Enhance is aiming itself at. It's giving you this more backend server-side-rendering kind of thing. So it seems like the frameworks have picked up on what the missing pieces are and are trying to fill it in.
00:17:29 - Ishan Anand
Sorry, say that again.
00:17:31 - Anthony Campolo
So, I mean, how much have you looked at Enhance so far?
00:17:34 - Ishan Anand
I looked at it. So I've only looked at it the last two days, and I've not actually run it through its paces. Personally, I've read through the documentation and its architecture, but I haven't actually played with it.
00:17:47 - Anthony Campolo
Yeah, because it seems like it gives you the ability to do server-side rendering with web components, and that kind of seemed like what it was for and what it was pitching itself at. So that to me makes sense because if you're talking about this current problem where web components fall over, then that's where, naturally, frameworks will fill in, saying, hey, here's how we can take this thing that's 90% of the way there. There's build conventions to fix or make a nicer DX or just remove footguns for these other pieces.
00:18:19 - Ishan Anand
Well, I missed the part then that they support server-side rendering. It should have been the first thing I looked for. But I know Brian has talked about it before, so I should have expected that. I didn't see server-side rendering in there, but I'm going to Google search it right now.
00:18:42 - Anthony Campolo
Here we go. Rendering. So you want to go to the concepts: HTML single-file components are rendered on the server, where Enhance does the tedious work of expanding custom elements as well as setting up your document for progressively enhancing components for dynamic render in the browser.
00:19:01 - Ishan Anand
Yes, there I see it now. Thank you.
00:19:06 - Anthony Campolo
Actually, I saw Theo tweeting about server-side rendering and web components also. So he got into an argument with someone about it.
00:19:16 - Ishan Anand
Oh, I didn't even notice Theo come in. I was busy looking at the website right now. Let's see if we can get Theo to jump in.
00:19:24 - Anthony Campolo
So we should get Danny up here too.
00:19:29 - Ishan Anand
Let's do it.
00:19:34 - Anthony Campolo
See?
00:19:34 - Ishan Anand
Invite to speak. Okay, well, I sent the invite, but you never know sometimes.
00:19:47 - Anthony Campolo
Yeah, that's a good note for them, though, that they should make this more front and center as part of the pitch if it wasn't clear to you in the first place.
00:19:56 - Ishan Anand
Yeah, I saw the single-file components, I saw all the other things, but I'm really curious how they solved the problem that we ran into, which was, to be fair, over three or four years ago. So then, are we really on the cusp of the year of web components?
00:20:16 - Anthony Campolo
I don't think you can really say that, yeah. I think just because there's more work around it doesn't mean they're actually going to get picked up. Maybe no one's going to use Enhance, but I think it puts them in a better position to actually get adoption. But it's still not entirely clear to me that web components will ever catch on beyond what you're talking about in terms of use for more corporate-type stuff. But I mean, this is just kind of my bias in terms of the developers I talk to and what they actually care about or don't care about.
00:20:52 - Ishan Anand
Yeah. What we often call B2E tools, business-to-employee, is where I've seen people like it. But again, for the maintenance issues we discussed earlier, it looks like Theo replied. He's busy preparing for the stream, he says.
00:21:06 - Anthony Campolo
All right, that's all good, man. I appreciate you stopping by anyway.
00:21:09 - Ishan Anand
Yeah.
00:21:11 - Anthony Campolo
Coming up with PlanetScale's CEO. So people should definitely check that out after this.
00:21:16 - Ishan Anand
Oh, interesting. Okay. Yeah, folks should definitely check that out on Theo's stream right after this, I think, right? It's right at the top of the hour.
00:21:26 - Anthony Campolo
Yeah.
00:21:27 - Ishan Anand
Okay. The other part that I thought was fascinating about this was more an ecosystem thing, which is Begin has been around for a while. They seem to be tying, if I extrapolate from the announcement, the new version of the platform to this new framework. It feels to me similar to a story we've seen before where a company creates a popular framework and then creates the hosting platform to support it. Begin was around without that, and now it seems like they're pivoting to say that is the model that works. That could be the lesson I'm going to take away from this. Or am I extrapolating too far?
00:22:12 - Anthony Campolo
Begin was more so built on Architect, like I was kind of originally saying. But Architect is an infrastructure-as-code framework. It's more like, you know, CloudFormation. It's more like a SAM, Serverless Application Model, than a front-end framework. So I've been talking forever about how there's going to be this kind of merger at a certain point where you're going to have all these frameworks have really nice infrastructure-as-code setup so people can just deploy these things in single commands. And I think that's a good thing, to have really tight integration between an infrastructure-as-code thing and the framework itself. But it can go awry when you end up with these 10,000-line YAML files and you have no idea what they're doing. So it has to be done carefully to be done well. But I think there's a lot of power in that.
00:23:02 - Ishan Anand
So okay, they had an infrastructure-as-code framework, but they didn't have a full-stack framework. And I guess I'm talking about the model where there's a full stack because...
00:23:10 - Anthony Campolo
They're literally saying, just write HTML and stick it in a Lambda function, and then make that Lambda function expand to a route, and then that's your web page.
00:23:21 - Ishan Anand
Yes. Which is a model that appeals... I guess what I'm coming to is the closest example of this, obviously, that comes to mind is the Next/Vercel, as opposed to, heck, what Vercel was before when it was Zeit, which was more container-based. And that type of model, the question is, you look at all the popular frameworks. A lot of them are exploring a hosting platform that's integrated to their full-stack framework. Is that what we think the future model is, or is there an alternative one?
00:23:59 - Anthony Campolo
I know a lot of people push back against that because some people don't like that every framework will have its own deployment platform, because then they won't be able to share work across each other. You end up with a subpar experience. And then you have someone like Netlify, where Netlify is like, we want to work with every framework. So they specifically did not build a framework, and they're hiring people as liaisons to all of these different frameworks to make sure they all have a nice experience. So I think that's the smart thing. Vercel's done this too. Despite building this whole thing that was super nice for Next and making it the nicest way to run Next, it's a great way to run all sorts of stuff. They realized you can't just make a deployment platform for one framework. This is why Gatsby Cloud seems to be floundering.
00:24:50 - Ishan Anand
So that's interesting you say that. There was an article I didn't include in the newsletter this week that just said, is Gatsby floundering? But Gatsby is another example of a framework that built a platform and...
00:25:02 - Anthony Campolo
I don't know what Gatsby's numbers are. Maybe they have plenty of customers, they're making tons of money, and everything's fine. All I know is that I don't really know anyone right now who wants to build with Gatsby and is excited to build with Gatsby.
00:25:14 - Ishan Anand
Is it Gatsby is floundering, or is it Gatsby Cloud that's floundering?
00:25:19 - Anthony Campolo
Well, it's the same. The reason why people don't like Gatsby is because of the build time. Because when you actually deploy the thing, it's a huge nightmare. But it seems like the fact that they built a whole company to solve that didn't make it explode as the biggest framework ever. If anything, I just saw fewer and fewer people be interested in Gatsby because other frameworks were created that could do similar things. So I think they just got a lot of competition that figured out how to do similar things, because Gatsby was really early. Gatsby came out six or seven years ago, so they were the only game in town for a long time in terms of what they did. But then they ended up with a lot of legacy stuff that made it hard to get beyond the bottlenecks they had built into their own system.
00:26:02 - Theo
Getting triggered by this.
00:26:04 - Anthony Campolo
Me up.
00:26:07 - Theo
Here. Good enough. I do actually have to run in like five or 10, but I have to complain a little bit about Gatsby. I think it's another one of those examples. I compare it more to Angular than anything. I don't think that the cloud platform is as big of a deal in their demise. What I think happened here, more specifically, is Gatsby found a good workflow. Roughly speaking, using tools like React to build static sites in a dynamic-ish way was powerful. They proved that. But the way that they chose to prove that was full of questionable architecture decisions and a very aggressive approach that had a lot of assumptions that proved out not to be true for the majority of use cases. The amount of effort they put into their GraphQL abstraction layer as the way to plug things in and get data into and out of Gatsby is just not what you should be using for a blog. If you're reading text files, you don't need to throw GraphQL in the middle of it. I feel like a lot of the use cases that we thought Gatsby would be best for just ended up not being the case, because something that didn't force you to use pieces you didn't need was just better. Being much more minimal, kind of going the more React approach of, here we have these primitives, we're not going to tell you how to use them, ended up working out much better.
00:27:22 - Ishan Anand
So that seems to match what I have read, and it's that I think the use of GraphQL where you didn't need it was potentially overkill. Now, it does give them a really powerful plugin ecosystem. But I think, getting back to the original thing we were talking about, popping back off the stack, the popularity of the cloud is not affecting the popularity of the framework. It's the framework popularity that's affecting the popularity of the cloud. As much as we want there to be interoperability, the frameworks are driving demand and interest. That is.
00:28:04 - Anthony Campolo
Yeah, I think that's good. I agree with that. The thing I would add is that think of if, instead of building a deployment platform, they improved their framework to remove all these issues. If they continued iterating on it, maybe some of that could actually compete with people. Because once they built their own deployment platform, they had to keep building the framework the same way because the two were kind of locked in with each other. So I think it forced them down a certain route that probably didn't allow them to fix the issues that they may have been able to fix otherwise. But I agree, them building the deployment platform is not the issue why people stopped using it.
00:28:40 - Ishan Anand
Yeah, I mean, I feel very close to this personally because look, on our platform we support a ton of frameworks including Gatsby and Next, and we have to prioritize which ones are the most popular that we obviously make sure we fix and make compatible as much as possible. It's very much the statement I often use internally: the frameworks are driving demand. That is the thing to look for. As an example, when it comes to edge computing, the frameworks that are embracing it are going to be the ones that are driving demand for edge compute. People aren't going to use anything unless it's through the lens of a framework. A great example.
00:29:23 - Anthony Campolo
So when is Edgio going to build a framework?
00:29:28 - Ishan Anand
It's funny you say that. We've often discussed building a framework. We actually built a framework in the past. We contributed to an open source framework called React Storefront. Eventually React Storefront ported to be on top of Next instead of a custom build that did its own [unclear] of things like the server. But we also want to be agnostic. We want to be able to tell our customers, you bring whatever works the best with your platform, whatever works the best with your team and your team has the skills for and that you're interested in. So the conversation, and this is why it's close to us, because the question you ask comes up a lot. Right now we think it's best to be where our customers are, which is on these other frameworks, and making sure our support is as good as possible for those rather than launching our own framework in the market. React Storefront is a good example. That's something where it sits on top of a popular framework like Next.js. We may continue to do enhancements and work with the team that works on that. But I don't know, maybe this is famous last words.
00:30:40 - Ishan Anand
I don't know if I see us creating a whole new whole-cloth framework by ourselves unless we think there's a gap in the market that we can solve. And right now I think the best thing that serves our customers is to support the frameworks they're using. But it's a good question.
00:30:57 - Anthony Campolo
Yeah, did you have your hand up, Theo? You may have had a thought there at some point. But yeah, continue on your line of thought, Ishan.
00:31:07 - Ishan Anand
Yeah, so this is why it's really close to us because I pay attention to this a lot. The thing I was talking about was frameworks driving demand. Edge computing is an example of where I think frameworks will drive demand. Another one is, look, when the React team rolls out server-side components, they very explicitly said, hey, if you're a day-to-day full-stack developer, you don't need to really worry about this until the full-stack framework you are using supports this. It's an acknowledgment in the ecosystem that these full-stack frameworks or meta-frameworks are the conduit by which developers either pick up or get exposed to new features, or don't. Another example of this is Google's product Aurora, where they wanted to improve the speed of all websites on the web, which is a noble lofty goal, one that obviously fits in their corporate objectives because the faster the web is, the better it competes and the more money everyone makes. But they've tried a variety of tactics like Core Web Vitals influencing search rank by how fast your site is. One of the most highly leveraged ways they realized they could do it is they went to the meta-frameworks and they said, hey, you've got to improve these problems that your JavaScript-heavy websites are creating.
00:32:31 - Ishan Anand
It's going to be a collision course. Collision course is actually what my co-host on the JavaScript Jam podcast proper used to describe it as. He's like, the whole developer ecosystem is doing these JavaScript-heavy frameworks, and Google on the other hand is saying these sites have too much JavaScript, they're too slow. And I think over the last 12 months what we've seen is the result of that collision course, which is Google coming in and contributing to frameworks like Next and having a fund to pay for improvements to other frameworks to solve those problems. Again, the frameworks are the instrument of demand. That is the thesis. And so getting back to why I raised the question, when we see Begin say, hey, they had an infrastructure framework, and now we are going to have a new version of the company and a new framework that goes along with it, it feels very much like you need to succeed through a framework that you control. And it goes back to the question that you asked, which is we often debate: do we need a framework of our own, or do we need to just work the best with all the other frameworks out there?
00:33:39 - Ishan Anand
Because that takes work. You don't always know what's coming. You have to constantly watch what's coming down the pipeline. As an example, Next has this feature, incremental static generation. We were, I think, one of the first outside of Vercel to support that. I think we were the first outside of them to support it with the proper caching. So I'll stop, since I've been talking for a while. We're almost halfway past. We should probably... Yeah, go ahead, Anthony.
00:34:08 - Anthony Campolo
Scott's time. Scott's time.
00:34:10 - Theo
Yeah.
00:34:14 - Ishan Anand
Oh, Scott's time.
00:34:16 - Scott Steinlage
Welcome to Scott's time.
00:34:20 - Ishan Anand
The whole hour is Scott's time.
00:34:25 - Scott Steinlage
Thank you, everybody, so much for showing up today. Greatly appreciate it. Welcome to JavaScript Jam Live, where you talk about everything and anything, JavaScript jam, JavaScript jamming, and web development. As you heard from the conversation, there's been lots of great talk going on here today. Love it. Lots of great people in the audience here as well. By the way, if you're in the audience out there listening in, we love it when you participate. In fact, that's when we get the best conversations going on up here, when you guys do participate. So feel free to raise your hands, or request, shall I say, to come up and speak, and we'll be more than happy to oblige and bring you up. In fact, we encourage it. So whether you have a question or you just want to state your opinion, feel free. I know I saw Kyle there putting some hearts up, some hands up, in agreement with some things. That would be a great time if you really want to say something. Hey man, come on up, request it, we'll bring you on.
00:35:27 - Anthony Campolo
He also had a suggestion for a topic: Heroku, whether Heroku is dead, to get into.
00:35:34 - Scott Steinlage
Yeah, yeah, yeah, Kyle. Oh, yeah, for that, for sure. So, yeah, absolutely. Thank you all so much for joining us today.
00:35:43 - Anthony Campolo
And by the way, if you do
00:35:44 - Scott Steinlage
get value from those people speaking up here on the stage, and those that come up from the audience, please feel free to click on their face and follow them because if you're getting value from them here, you're probably going to get value from them in other places. Awesome. By the way, every Wednesday, 12 p.m. Pacific Standard Time is when we do JavaScript Jam Live. We love it if you join us. And hey, you know, we wouldn't mind as well. All right, back to you guys.
00:36:14 - Ishan Anand
Yeah, one secret of the station break is that it gives me... We do this at noon time, right? It's lunchtime in the Pacific time zone. So that's the one time I know I can actually get a bite in as I'm eating my lunch. But I like the topic about Heroku because something that I put on the cutting room floor to talk about, but we never got to last week, was Heroku got rid of their free plans. There was a whole Twitter thread, I think must have been two or three months ago, about is Heroku dead? So I have a number of thoughts there, but I'd love to open it up to the audience and see what folks think on that question. Is Heroku dead, or is it alive?
00:37:04 - Anthony Campolo
Also, welcome Danny to the stage. I think that Heroku was kind of stagnating for a while in terms of appealing to the hobby dev or startup crowd that had picked it up in the first place. It was purchased by Salesforce, and now it's in a place where I think they want to... I think this is what Theo said. It's not about pushing more people to pay money, it's about losing less money. So by getting rid of the free tier, you get rid of a massive amount of people who are using it but not paying for it, and also just people trying to run crypto mining bots, all sorts of stuff like that. Having a free tier is actually an extremely hard and complicated thing to offer. I know this as someone who works at a company that spent a very long time having to implement a free thing. So yeah, I mean, it just shows kind of a change in priorities. I don't know if it means they're necessarily dead, but they're dead in the sense that I will not use it or recommend it to people who are looking for a quick, easy way to spin up a database or a server.
00:38:11 - Ishan Anand
Sorry, you will or you won't recommend it?
00:38:13 - Anthony Campolo
I will not. Yeah. Because there's now lots of options like Railway and Render and Fly, ways to spin up things that are going to be either cheaper or a comparable price, but a much better product because they're more modern and they are continuing to build and do things faster and better. So yeah, I see better options, especially now that it no longer has the advantage of just being straight-up free.
00:38:43 - Danny
I think it also comes down to the audience, right? I worked at Heroku, and a lot of what you experienced there was a little bit different as things were evolving. For example, the Rails community, they still use Heroku. There are lots of communities that definitely still use it. I think it's just not as common in the JavaScript ecosystem for sure.
00:39:07 - Anthony Campolo
And do you think those communities will be... how do those communities feel about the change in price then? I'd be curious.
00:39:15 - Danny
Honestly, yeah, it's been a while since I've touched base over there. But at the time Vercel had come out and I was still consulting for them, it didn't seem to really affect anybody that was Laravel-based, more legacy-focused, or on Rails. They were still definitely... that's the heavy majority of where Heroku's user base was. Even in the beginning, Node only really started showing up during the real education phase of the JavaScript ecosystem as front-end started to become more popular, specifically around Angular and React. But it didn't last long, because as soon as solutions like Vercel came out, people started to move away from it because the "now deploy" path was less in the educational path than it is in other ecosystems. Even if you go anywhere to learn Rails, they're going to start you off on Heroku. But I don't know about pricing changes and how they feel about it, though. That's a good question.
00:40:14 - Ishan Anand
Looks like we got Kyle up on the stage. Kyle, is there anything you want to add?
00:40:19 - Kyle
Hey, yeah, not really, to be honest. I was DMing Anthony when y'all were speaking earlier, still speaking about all the different platforms, and I wanted to make sure that we talked about Heroku because I thought it would be an interesting addition. Bringing this back in time a little bit, earlier we were talking about how Vercel is very targeted.
00:40:41 - Anthony Campolo
Right.
00:40:42 - Kyle
And how Netlify is a little less targeted. So I kind of wanted to bring up, I don't know that anyone loved Heroku, to be quite honest, but I'm not entirely sure why, because honestly I think it kind of fills this gap. The only thing with Heroku was it was quite expensive, and now without a free plan, it's very expensive.
00:41:02 - Ishan Anand
Oh, I think Heroku was loved. There's the topic of people who build dev tools. I feel like Heroku comes up a lot in the background, and the question is... I just added a link to the JavaScript Jam announcement for this thing. I don't know if Scott, you can post it there. But there's a thread that I found from April, and the question was, legit curious on people's views, was Heroku a huge success or failure? There are a lot of dev influencers with some interesting takes. So swyx, for example, replied saying the number of pitches which are essentially Heroku for X make it an unparalleled success in dev tools. Other people venture that given what it was sold for and the amount of influence it could have had, it could have gone for more, which is a very VC way of looking at it. There's even a Heroku board member who replies in, and he has a great kind of sentiment there. It's a huge success as a cultural movement and demonstrated how to think about the cloud abstraction.
00:42:24 - Ishan Anand
And the business became far bigger than most people thought it would. But the legacy as a catalyst for creating the whole venture-backed startup movement is immense. Which kind of mirrors what my take was back when this thread happened and I replied back in. I said my take was their greatest success was it gave them the cash and credit to start Heavybit, which catalyzed the whole dev tools space. If you compare the inflation-adjusted exit to the portfolio valuation, it's a bigger success than the individual company. This is where I said it's like if the Velvet Underground, when they broke up, they went and started Factory Records after they broke up.
00:43:06 - Anthony Campolo
That's an amazing reference. So few people will understand.
00:43:11 - Ishan Anand
Yeah.
00:43:12 - Anthony Campolo
But I want to give Kyle a chance to speak. He's got a hand up.
00:43:14 - Ishan Anand
Yeah, go ahead.
00:43:15 - Kyle
Oh no, I appreciate it. Thanks for sharing all that. What I was going to say was Heroku was loved. I shouldn't have said it like that. What I think I should have said was Heroku was infinitely popular with mostly, I guess, beginner tutorials and lots of open source and stuff. And I think a lot of it centered around the fact that it was free.
00:43:41 - Anthony Campolo
Redwood used it as its database of choice for a while.
00:43:43 - Theo
Yeah.
00:43:44 - Kyle
Yeah. And I'm assuming you were a paid user, right?
00:43:48 - Anthony Campolo
No. So we had a tutorial where basically we would walk you through an end-to-end thing. At the end we'd be like, now go spin up a database with Heroku. You can do it for free.
00:43:58 - Kyle
Totally.
00:43:59 - Ishan Anand
Yeah.
00:43:59 - Kyle
And I work at CircleCI, so I've written a bunch of tutorials that are the same. I have to go through now and update a bunch of tutorials, and I don't even know what I'm exactly going to tell people to switch to other than AWS right now. I could go deeper into that, but my question is why do you think, and maybe you don't agree, that maybe Heroku never really felt like it made the transition into enterprise? It had this goal of converting free customers into paid customers, and I don't feel like that happened.
00:44:33 - Ishan Anand
I completely agree with you. Let me see if I'll venture my thoughts. I don't have a good solid explanation, but we'd often talk about this actually as the Heroku problem, which is you have a really easy-to-use abstraction. That easy-to-use abstraction that gets rid of a lot of issues tends to do a really good job catering to a particular segment of users. Very often it's a solo or beginner user or somebody doing something on the side. When you get to a certain sense of scale, the premium you pay for that may not be worth it, where it might actually be better to go to something like AWS, where there's a higher overhead but the cost structure makes more sense potentially. That may be one reason why. But actually I raised that in a reaction to an article from RedMonk and I asked a question. I'll put the link in the reply to this. I put it on Twitter. I said, for all the value we place on a great developer experience, why did AWS take off, yet the more DX-focused Heroku's growth stalled?
00:45:55 - Ishan Anand
It's exactly the same question you asked. So I'm curious to hear what other views are.
00:45:59 - Danny
Yeah. So in my perspective, as we went through the phases, when we really started to dive into why AWS was excelling and Heroku was not, it was the lack of ops-focused culture. We were more focused on the engineering crowd than the ops team, and the ops team was going over to other cloud platforms which were more ops-centric and had a lot more freedom and availability. I feel like that was kind of one of the mistakes for Heroku. They focused so much on the engineering crowd and making things easy and deployable, but they didn't focus enough on freedom of choice as well as the ability to just change up how you do things within your deployment workflows. But that's kind of my perspective after the fact. Definitely during the time I was there, there was never mention of ops and why ops would be a heavy influence between choice of platform. And that definitely came down to a key decision-making point, why you would choose Heroku over AWS and so on and so forth.
00:46:59 - Theo
But go ahead.
00:47:05 - Brontify
Multi-container orchestration in Heroku is a pain in the butt.
00:47:12 - Danny
Oh yeah, 100%.
00:47:15 - Kyle
Can we even do it?
00:47:18 - Danny
I don't believe you can.
00:47:20 - Kyle
That's a really good point right there. And I wonder if... okay, so ideas are bubbling. Apologies for ranting. This makes no sense, so it's all good. But you know, it kind of feels like what took the place of Heroku slowly is all of these serverless frameworks, right? Especially when, and this is very recent, but when AWS added containerized serverless, whatever they call it, serverless containers, I mean that's all you really need. And we said it earlier, dealing with Amazon's UX is a disaster, but it gets you on the quote right platform with a similar kind of style. And then there's also Serverless Framework, the open source framework. Also fantastic.
00:48:04 - Anthony Campolo
Yeah, this is a super interesting point because when I was working on Redwood, and this is still playing out in real time, they built it just for serverless and then eventually got to the point where enough people were using it and were like, hey, this serverless stuff doesn't quite work well enough. We need to run it in a container or a server. And so it's existed kind of in that middle space between the two. I've seen this play out over like two years, and it's both that it's become easier to run containers, and it's become actually possible to run containers in Lambda functions. It's also become possible to run containerized versions of Lambda functions. So the two have become almost imperceptible from each other, as long as the infrastructure layer and the frameworks kind of do it for you. The biggest thing is, is the cold start an issue or not? And if the cold start is an issue for you, you can't run it on just a serverless thing. So the DX of Docker had to get good enough to give the same DX as a serverless function, but then also remove the cold start.
00:49:08 - Anthony Campolo
And you should check out Flightcontrol. Flightcontrol is basically how do you build a Heroku on top of AWS.
00:49:16 - Brontify
Yeah, I kind of always go back, well, I don't know about always, but often, to swyx's article on the end of localhost and remote development. You just got me real hot and heavy over the subject of internal developer platforms. Building your own container-based... you're kind of creating your own containerized environment to do development in, and it's very similar to creating your own container for a Lambda function, so custom Lambdas. I think custom remote env and custom Lambdas are definitely a space where that is really ripe. We have out-of-the-box Lambdas you can hit on Vercel. You can do Python and JavaScript and maybe even more languages, maybe even Go and run, I don't know, but I know you can do Python and JavaScript. You just boom, you've got your serverless function out of the box. But what if you want to embed some other... what I would call it, what I would call something like a custom Lambda, or a Lambda in general, would be like a headless worker node of Kubernetes.
00:50:26 - Brontify
So Kubernetes is just like containers with a head on it, which is a control plane, meaning something that orchestrates these things and makes it go automatic. So take off the automatic part and you just have headless Kubernetes, or Docker, or containers in a Lambda, or just Lambda, or serverless, or whatever. So anyway, that's all I got to say right now.
00:50:51 - Ishan Anand
Who do you think the... getting back to what Daniel was saying, which is really a question of personas and product-market fit rephrased as product-persona fit, who do you think the customer typically would be for what you're describing there? It doesn't sound like something that a full-stack developer would go for. It feels more ops-focused. Sorry, go ahead.
00:51:19 - Brontify
Yeah, yeah, I would just say power users. Power users. Someone like, I don't know, maybe Theo. If you can hook him up with a custom runtime for his serverless functions, he might want to use that. I don't know, someone really, really powerful. Like a power user in terms of developers, I would say.
00:51:39 - Danny
And I mean, the other factor would be the size of the company using the solution. Theo in a small startup, absolutely. Or when he's scaling a company up, he might be the engineer, the power-user IC, that can definitely get the experience to do what's required. But at the larger scale, the engineer would never make that choice, especially if it's in an unproven environment. It just wouldn't happen.
00:52:07 - Ishan Anand
Yeah. And actually I'm going to look for it. I'll put it in the Twitter thread. But this is exactly what Theo's talk was at the Composability Summit. We should just post that video. I'll find it and see if I can put it on here. But it was basically the argument, I think he used GraphQL and tRPC, and he was saying, look, at a certain team size, this is the right tool, and then at a certain other team size, it flips. And those drive your decision-making on tooling as well.
00:52:43 - Scott Steinlage
Go ahead, Kyle. What's up, man?
00:52:46 - Kyle
You know, so on the topic of power users and stuff, you know who I think we could look at as an example of this? I suppose we forget, as web developers, or whatever you want to call us, that we have a lot of tools that are very specific to us, but not every developer out there actually follows a lot of these paradigms, and they do a lot of their own weird custom stuff. In particular, game developers. Game developers are notoriously bad at ops and CI/CD, but they still do it. They just do it differently than we do. A lot of the time they're using Jenkins, but on top of that, or even alongside that, they are running entirely custom scripts that were built for their specific workflow. I've always toyed around with the idea that, I'm not allowed to say this out loud because I work for Circle, but I feel like you could get a lot done with some fairly simple containers that are tailored for your project or your organization.
00:53:59 - Ishan Anand
I guess the question then is, who does that tailoring?
00:54:04 - Kyle
Yeah, that's valid. I mean, within the organization, I'm not entirely sure. I had a cool conversation, unfortunately it wasn't recorded or anything, it was private, but I had a cool conversation with... can't even remember his name, someone who does the DevOps for Fortnite, actually. And we started having a little conversation about CI/CD. I didn't get into who was setting it up, but I learned that over the years they have completely built their own tooling on top of stuff. I mean, like, Brona... I can't say your name, man.
00:54:37 - Anthony Campolo
How we're supposed to say your name, I never know.
00:54:39 - Scott Steinlage
I bet it's bro-nifty.
00:54:41 - Anthony Campolo
That's it.
00:54:42 - Brontify
Jacob snaps at me, or anyone, if they pronounce my name as anything other than Brontify. So I guess it's Brontify so I don't get in trouble with Jacob.
00:54:51 - Anthony Campolo
That's not even how it's spelled, though.
00:54:59 - Ishan Anand
Scott, is there a limit to three links you can share? I'm trying to link...
00:55:04 - Scott Steinlage
Oh, really?
00:55:05 - Ishan Anand
Theo's talk, but maybe as co-host I can't do it.
00:55:10 - Scott Steinlage
Did you tweet it? I'll go find it.
00:55:12 - Ishan Anand
Oh, you know what? If I tweet it as a reply, maybe I'll do that. This was exactly what Theo's... I'll do it right now. There, I just tweeted it. All right, in the thread.
00:55:37 - Anthony Campolo
All right.
00:55:38 - Scott Steinlage
Yeah, I see. I'll put it up there. I don't know. Let's see.
00:55:43 - Ishan Anand
Nope, it has it added. Okay, great. So that's in there. That question in the middle of his talk, he has a nice graph that I really like that shows different technologies at what team size, to illustrate that point. So let's see. I think we only have... Oh man, you know, I think, Anthony, you've often said we need to extend this by more. I'm sitting here, I have a hard stop at three minutes. We only got to two of the topics that we planned, which is great because we actually had audience topics. So I love that more than what we had planned. But I'm going to have to bow out. I don't know if Scott or anybody else who's on the speaker panel can stay on longer, but Scott, do you want to take us out otherwise?
00:56:38 - Scott Steinlage
Yeah. All right, well, thank you all so much for joining us today. Greatly appreciate everybody's time and everybody speaking up here. If you're not following us yet, JavaScript Jam, please do so and join us again next Wednesday, 12 p.m. Pacific Standard Time. As always, we love hearing from you guys. Kyle, thanks for coming in, man. First time I think we've seen you in here.
00:57:01 - Anthony Campolo
Maybe.
00:57:02 - Scott Steinlage
Maybe I'm wrong, but yeah, we'd love to hear from you again next week. Brontify as always, thanks, dude. Anthony, Daniel, Ishan, of course, and everybody else out there saving the world, thanks, dude, for listening in. Yeah, appreciate everybody here.
00:57:25 - Ishan Anand
And if you didn't speak this time, please do next time. We want it as audience-driven as possible.
00:57:32 - Scott Steinlage
Absolutely. Makes it more fun. All right, y'all, I think that calls it for today. But until next time, see you later. Peace out.