Living on the Edge

Episode Description

Anthony Campolo explains edge computing, JavaScript runtime portability, and how Edgio's platform tackles performance challenges for modern web applications.

Episode Summary

In this episode of PodRocket, Anthony Campolo joins host Paul to break down the concept of edge computing and how it shapes modern web development. Anthony explains that the edge is fundamentally about moving compute closer to users through distributed global networks, then positions Edgio within the broader ecosystem as an enterprise-grade deployment platform that combines the developer experience of Jamstack providers with deeper infrastructure capabilities, including zero cold-start edge configuration powered by native varnish. The conversation moves into the tension between pushing code to the edge and the reality that JavaScript runtimes are not interoperable, tracing the history from Node to Cloudflare Workers to Deno and the emerging WinterCG effort to create portable, standards-compliant runtimes. Anthony highlights frameworks like Hono JS that already target multiple runtimes as evidence of a meaningful shift away from Node-specific APIs. The discussion then pivots to Edgio's video streaming roots, its merger of three legacy companies, and the importance of real user monitoring over synthetic Lighthouse tests for genuinely understanding site performance. Anthony closes by cautioning against "performance theater" and urging developers to build benchmarking and AB testing into their workflows rather than trusting framework marketing claims at face value.

Chapters

00:00:00 - What Is the Edge and Where Does Edgio Fit?

Anthony Campolo opens by illustrating how running JavaScript is far less portable than most developers assume, setting the stage for a conversation about edge computing. Paul introduces the episode's focus on the edge as a universal concept and Edgio as a specific platform within that space, and Anthony defines the edge as distributing compute closer to users through global CDN networks to minimize latency.

Anthony then maps Edgio against the broader cloud landscape, comparing it to a server-first alternative to Jamstack providers like Netlify or Vercel. He explains that Edgio combines the polish of a git-synced dashboard with enterprise-scale infrastructure you never need to migrate away from, drawing a parallel to Cloudflare combined with Cloudflare Pages but with deeper access to security and networking layers.

00:05:15 - Deploying and Architecting for the Edge

The conversation shifts to what it actually looks like to deploy on Edgio, with Anthony explaining that developers can target specific regions or simply push to the CDN without worrying about origin versus edge routing. Paul raises a key misconception around database placement, and Anthony responds by distinguishing between running server rendering at the edge versus caching rendered output there, noting that Edgio supports both edge-native and traditional single-origin databases.

Anthony highlights one of Edgio's standout technical features: its edge configuration layer runs on native varnish with zero cold starts, unlike isolate-based approaches that require spin-up time. This segues into a broader point about the current JavaScript ecosystem's emphasis on performance-first architecture, with frameworks like Solid and Qwik designing for small bundles and fast parsing from the ground up rather than optimizing after the fact.

00:10:15 - The JavaScript Runtime Portability Problem

Paul asks whether edge optimization creates vendor lock-in, and Anthony traces his own journey researching how to run RedwoodJS on Cloudflare Workers, only to discover that Workers don't run Node. He walks through the fragmented landscape of V8, Deno, JavaScriptCore, and how the WinterCG consortium is working toward a standards-compliant, portable edge runtime built on web-native APIs rather than Node-specific ones.

The discussion highlights concrete progress toward portability, with Anthony pointing to frameworks like Hono JS and Hat Tip that already target Cloudflare Workers, Deno, and Bun simultaneously. Both speakers agree that the shift away from Node APIs toward universal runtimes is one of the most significant transitions happening in JavaScript development, though they acknowledge it remains a work in progress with no single standard yet fully adopted.

00:16:39 - Framework Consolidation and the Shift Away from Node

Anthony elaborates on the interplay between framework authors and deployment platforms, arguing that once every platform can run every framework, the community can identify shared patterns and divergences. He emphasizes the value of frameworks that are not platform-specific and platforms that are not framework-specific, noting that Edgio's documentation includes guides for virtually every major framework.

The conversation touches on the emerging landscape of partial hydration, React Server Components, islands architecture, and resumability as competing strategies for shipping less JavaScript. Anthony offers his own heuristic — Astro for sites, Qwik for apps — while warning that fragmentation could become confusing. He suggests that React Server Components could unify the ecosystem if adopted broadly across React frameworks, which might then influence non-React frameworks to follow a similar model.

00:21:46 - Video Streaming, Real User Monitoring, and Performance Theater

Paul asks what's next for Edgio, and Anthony reveals the platform's deep roots in video streaming, explaining that Edgio formed from the merger of Layer Zero, Limelight, and Edgecast — making it one of the largest video streaming platforms globally, supporting sites like Dailymotion and Rumble. This heritage means developers can integrate video delivery alongside traditional web application deployment without needing third-party tools.

Anthony then pivots to real user monitoring versus synthetic Lighthouse testing, arguing that RUM provides empirical performance data from actual users rather than scores from a simulated environment. He coins the term "performance theater" to describe the habit of swapping frameworks based on reputation rather than benchmarking, and stresses that developers need to build AB testing and monitoring into their core workflow. He closes by directing listeners to Edgio's documentation, his personal blog, the FSJAM podcast, and the weekly JavaScript Jam Twitter Spaces.

Transcript

00:00:00 - Anthony Campolo

You go down this whole rabbit hole of what's the difference between V8 and Node, then you learn about Deno, then you learn about JavaScriptCore, and then you realize that, okay, JavaScript code ain't just JavaScript code. Running JavaScript code is something that many different people have done in many different ways, building on many different pieces of technology that is not very portable.

00:00:29 - Paul

Hi there, and welcome to PodRocket, a podcast brought to you by LogRocket. LogRocket combines session replay, error tracking, and product analytics to help software teams solve user-reported issues, find those issues faster, and improve conversion and adoption. Get a free trial at logrocket.com today. Today we have a special guest with us who has been on our podcast multiple times already, so he's a seasoned interviewee and a supporter of the show. Please welcome Anthony Campolo. He's the host of FSJAM. You might listen to it where they go over the latest trends in full-stack development. Today we're going to be diving into the edge. It might seem like a mysterious something to some, but it really is a universal backbone that powers the experience of the internet that we know today. Welcome to the podcast, Anthony. Excited to have you.

00:01:19 - Anthony Campolo

Hey Paul, thanks for having me back. It's great to be here.

00:01:22 - Paul

Last time we talked, we were talking about Web3 and nodes and serving a data layer. I guess today the topic of conversation is quite similar. We're talking about the edge. For people who are coming to this podcast wanting to learn what the edge is, can you give an analogy or comparison that might help wrap their heads around it?

00:01:42 - Anthony Campolo

Yeah, sure. This is a common term you're hearing a lot, and it's becoming baked into the way we do our serverless functions. You may be hearing about serverless edge functions these days. We're using "edge" in a similar way, where the edge is about getting the compute closer to the user. The way you usually do this is by having some sort of distributed global CDN or multiple server farms all around the world. So wherever your user is, they have low latency to get the data. Edgio is a CDN, and we have pretty much one of the largest networks, right up there with things like Akamai, and it's really well integrated with the ISPs. So for us, it's a way to really optimize performance at that last mile to the user.

00:02:41 - Paul

And I think it's important to note we are going to be talking about Edgio today. That's the focal point of the technology that we're going to be talking about. But we introduced the podcast in general as talking about the edge, and the edge is a pretty universal concept at the abstraction layer in technology. Edgio is where you're at right now, Anthony. So is Edgio an edge provider? Is that the correct way to summarize it?

00:03:06 - Anthony Campolo

Yeah. So let me try and fit this into the broader ecosystem. People who listen to this show are probably familiar with AWS, GCP, Azure. Those are your layer-one clouds that are the base infrastructure. Then you have things like Netlify or Vercel or Flightcontrol even that build higher-level abstractions on top. Edgio is, first off, many different things. It's kind of a streaming platform and deployment platform at the same time. So let's separate those two and talk just about the application deployment platform. I think of it as giving you a Jamstack kind of experience in terms of how you have a really nice dashboard, you sync to a Git repo, you can push assets, but it's really made for enterprise and for large-scale, really big apps and websites that are going to be shipping millions of pages. If you were to imagine a Netlify or a Vercel, but instead of being static-first it's server-first, so you can build static assets and push those up as well, but really it's going to assume you actually have a server to start with. That's why it can be a similar development experience to one of these other Jamstack providers.

00:04:24 - Anthony Campolo

But the idea is that you don't really ever need to migrate off, because you'll see this a lot where people will grow to a certain extent and then they'll be like, "Oh, now I gotta migrate to AWS." But with Edgio, you're already on a network that can scale with you. The closest thing I would probably compare it to is it's a bit like working with Cloudflare combined with Cloudflare Pages, because Cloudflare Pages would be the equivalent of Edgio Sites and Edgio applications. Then you also have the security and networking layer there as well, which is the stuff that usually is handled for you with things like Netlify or Vercel. So it's a little bit deeper into the stack, hopefully without introducing too much extra complexity, but it is giving you extra capabilities.

00:05:15 - Paul

So when somebody makes a deployment on Edgio, is this a deployment, at a very high level, I can think of as replicated globally where it's geographically close to users and I can have control over a server-side rendered environment? And a little bit deeper into the stack, is this sort of a unique value that Edgio is offering versus just a Netlify deploy?

00:05:37 - Anthony Campolo

So it's going to give you different staging environments, and then you'll be able to deploy to specific regions if you want to. Or if you want to just deploy it to the CDN itself, then you can do that as well. For the most part, when you're working with it, you're not going to have to think too much about regions. I think you can probably fine-tune that type of stuff if you need to, but for the most part you're able to just work with it and not have to really worry about when is this thing going to be on the edge, when is this thing going to be at my origin server, and you can assume that's going to be handled for you.

00:06:16 - Paul

Right on. So what do you think are some of the most common misconceptions about architecting software on the edge? If somebody were to reach for Edgio today and they want to start building a very fast application that is content-first, one that might stand out to me is if your application database, maybe you don't have replicated RDSs everywhere, you have one central app database that could be a geographical bottleneck. I'm curious, how does Edgio help developers with that, and what are some other misconceptions when architecting?

00:06:48 - Anthony Campolo

Yeah, there's definitely a trend right now to try and push as much stuff to the edge as possible, with things like Fly.io being the logical conclusion of this, where it's like, let's run a Docker container at the edge, which also gives you a really nice, simple mental model. But that's not really what you want to do unless you really are buying into that whole container lifestyle. It's more so figuring out where the actual server rendering happens, and does that need to happen on the edge or not? Because that could be one case where you don't want to have to run this code every time at the edge. If you could just run it once and then push the results of that to your edge CDN, that's where I think the deployment platform can really come in and help here. Developers want to have the benefits of the edge without having to necessarily think about how they need to architect their application and at what point that handoff happens. So with Edgio, they do have a storage kind of API, but for the most part you'll be running a database kind of wherever.

00:08:00 - Anthony Campolo

So if you want to have one of these more edge-native databases, you can do that, or you can work with a traditional single-origin-server kind of database, and then that is going to hook into your edge application. With the edge application, you will have conventions with a route file where you can set cache headers and manage edge configuration. So we have the ability to do similar things you do with Cloudflare Workers or now stuff we see with Netlify Edge Handlers, where you'll change headers or reroute traffic or do that kind of stuff. That is where you can run configuration kind of code on the edge. But what's cool with Edgio, and what does make it unique, is it's not using isolates. It's not having a spin-up. There's no cold start. It runs on native Varnish, like actually just straight-up machine code. I don't really know anything about Varnish. That's the thing I know CDN people talk about as the fastest way to do stuff: just run in Varnish. So that's the underlying thing that it's working with.

00:09:06 - Paul

So very minimal. If you're saying no cold-start times with some of the features that Edgio offers us, is this something that you find persisting across the board with Edgio's offerings? Is this something that you would traditionally find a cold start for and you don't have that on the Edgio side?

00:09:23 - Anthony Campolo

That's really the idea. We're very, very heavily focused on performance, and this is one of the things that made me really interested in working for the company and getting involved in it. Because I think we're in this kind of zeitgeist moment in JavaScript where a lot of frameworks are realizing how important performance is and how they think about performance from the beginning. You have so many new frameworks now, either Solid or Qwik or, on the server side, Bun, that are saying, "Hey, we need to actually architect for performance from the very beginning and then benchmark every single part along the way." We can't just make a nice developer experience, build this app, and then once you have the app be like, "Okay, how do we optimize this thing?" Because we're realizing now that kind of puts you in a pickle, right?

00:10:15 - Paul

And when you find yourself in that pickle, do you find that pushing things to the edge, like a networking-layer misconception, is very common? Like the solution people say, "Oh, I'm a developer. It works fine on my local." But when you actually put it out in the wild, that's when one little 10% lag on one step for every re-render causes a giant lag over time. Is this really the crux of the problem, you think?

00:10:40 - Anthony Campolo

That's not what I'm referring to right now. That's a big part of how the edge helps performance. But what I'm talking about right now with the frameworks is the single-page-application problem and the large-bundle problem, and the things that partial hydration and resumability are meant to fix, because those are issues where there's just too much code. You can connect and get that code to them really quickly, but then that means they get a bunch of code really fast that then takes a long time for their device to parse. That doesn't help anything. This is why I say you've got to think about this thing holistically. There's so many steps along the chain. There's the application itself, there's how that gets delivered, then there's how it functions on the device. So we're saying, okay, if the framework can give us a small bundle, we will get that to the user instantly. That's how you get this really snappy experience, which is what you need for things like e-commerce.

00:11:39 - Paul

Do you feel like when you want to design an application to be edge-performant and you're doing this balancing act of I don't want to ship too much code at the beginning, but I don't want to not have a rich user experience, or I don't want stale buttons because I'm waiting for hydration to take... You know, you're playing this balancing game with a bunch of levers, and the way you optimize that can be framework-specific or it can be vendor-specific, like for AWS. That's a classic trope, classic problem. Do you feel like the way we're designing applications now is very vendor-lock-in heavy for edge optimizations? Because in the end you're relying on proprietary hardware that is deployed in a proprietary way, that is finely tuned and optimized, with an API you really have to lean into. Do you find there's a lot of vendor lock-in because if you're moving from Cloudflare or Fastly back over to Edgio, vice versa, or does it matter more in the architecting at the beginning?

00:12:36 - Anthony Campolo

I think we're in a better place now than we've ever been. This is something that I've been tracking for a while, and that personal interest of mine with Redwood, because there was a time back in like 2021 when I was researching how to get Redwood to run on the edge, because Redwood is a monolithic GraphQL server. Having that be a cold-start bottleneck was a huge issue for the framework. So it made a lot of sense to say, "Hey, if we can get this thing on a Cloudflare Worker, that is going to almost eliminate this entire issue, which is affecting every single person who's building these apps." Then you realize, wait a second, Cloudflare Workers don't run Node. I thought it ran V8, though. Then you go down this whole rabbit hole of what's the difference between V8 and Node, then you learn about Deno, then you learn about JavaScriptCore, and then you realize that, okay, JavaScript code ain't just JavaScript code. Running JavaScript code is something that many different people have done in many different ways, building on many different pieces of technology that is not very portable. However, now we realize that this is an issue that we need to really solve, and there's more collaboration happening between groups like Cloudflare and Deno, who have the WinterCG group, the web [unclear] interoperable consortium, something like that.

00:13:59 - Anthony Campolo

I forget the exact terminology, but that is about creating this runtime that is just standard JavaScript, ECMA-compliant kind of code, and uses web-native APIs and can hopefully become more portable. Not really sure how Edgio will fit into that kind of mission, because we're running Node and then, as I said, we have our own kind of specific configuration thing for configuring the CDN. So it would be interesting to see what's going to happen once things like Bun and Deno and Cloudflare Workers start to become more interchangeable. I'm actually seeing this with frameworks now. There are frameworks now that are being built to run on any of those. It's portable between Cloudflare Workers, Deno, and Bun. There's one in particular that I can look up, but I think that this is going to become hopefully an actual real thing where you can start porting from one runtime to the other. We're not quite there yet, but there's

00:15:06 - Paul

a lot of movement, and if we have one universal runtime, that sort of breaks down some silos between being able to take one piece of your stack and have it on one provider versus have it on another provider, which is really nice. You don't want vendor lock-in, which is one thing I love about Flightcontrol. Flightcontrol really almost defines a base set of interactions and pieces of hardware that an efficiently delivered modern web application needs to have. You can take that in or out of AWS in a lot of different ways, those same concepts.

00:15:39 - Anthony Campolo

Yeah, Hono JS is the one I was thinking of. And then there's another one called HatTip. So H-O-N-O, honojs.dev. It's a web framework for Cloudflare Workers, Deno, Bun, and others. So yeah, I think this is pretty cool because what it does is it assumes everyone wants to work with an API that's going to be similar to Express or Koa or Cloudflare Workers. So it kind of tries to mash all those together into something that is similar to what we've been writing, but either is standards-compliant or will just be transformed into something that's standards-compliant with a kind of lightweight library wrapper around it. I'm seeing a lot of these projects right now. I think Worktop was one that used to be out a while ago that was doing a similar thing. So I definitely recommend people check these kinds of things out, because I think this is a very big shift that we're right on the cusp of.

00:16:39 - Paul

And just to summarize, Anthony, the cusp, the shift that we're entering right now is how we're deploying our applications.

00:16:48 - Anthony Campolo

That's the topic. Leaving behind Node APIs, hopefully, is the shift I'm referring to specifically, because that is the thing that everyone has been writing their stuff on: Node APIs. And then if you can run a Node server anywhere, that's great, but that can't be run on the edge, because then you get the cold-start issue. So that is the thing that we're trying to fix right now with this universal edge runtime kind of thing.

00:17:12 - Paul

And it's really exciting to see frameworks come out, such as Astro, as an example, where you can run on one runtime or another runtime. There are applications that are making themselves multi-runtime. But to have that universal runtime is, yeah, I guess, still has to be seen. But it's coming.

00:17:32 - Anthony Campolo

Yeah, it partly just comes down to the framework authors and the deployment providers themselves all figuring out: once every deployment platform figures out how to run every framework, then everyone can look at the sum total of all this stuff and be like, okay, here's the commonalities between all this, here's the thing that everyone's doing kind of differently. That's what's been, I think, really good about both having deployment platforms that are not framework-specific and having frameworks that are not platform-specific. So that seems to be also a big trend that I'm very happy to see, because I like just trying out lots of different things and combining different pieces of tech. So if you go to Edgio's docs, you'll see a guide for pretty much every single framework you can possibly think of.

00:18:18 - Paul

And since we're talking about user experience and having the best loading time for your website and the best content delivery on the edge, right before we get into some other features of Edgio, I'm just going to take a quick pause here to remind listeners that this podcast, PodRocket, is brought to you by LogRocket. LogRocket can help you understand exactly how your users are experiencing their user experience. You can keep track of sessions, errors, product analytics, frustration indicators. Algorithms and AI surface the most impactful issues affecting your users, so you can spend more time building a great product rather than hunting through your tools. So solve user-reported issues, find those issues faster, and improve your conversion and adoption today with LogRocket. Stepping back into Edgio specifically and the edge to improve your user experience, one thing that I thought was really neat is the streaming offerings that Edgio has, because streaming is something that naturally goes hand in hand with the edge. You're talking about fast-updating content, and you can push content out to the globe quite easily, but doing that quickly all the time can become expensive.

00:19:28 - Paul

So how does Edgio begin to tackle this problem, Anthony, and what do you think are some of the most compelling use cases or conversation starters for the value that streaming has within the ecosystem?

00:19:39 - Anthony Campolo

So the first thing we need to clarify is we're not talking about HTTP streaming here. This is actually video streaming. The history of how Edgio came together helps explain what's happening here. Edgio is actually a new company made up of three very old companies. Most of the things we've been talking about right now, the Edgio applications, the deployment part of it, the site's performance and security part of it, that is what used to be called Layer0. Layer0 was this suite of tools, and they combined with Limelight and then Edgecast. Those three companies have come together, and they were more focused on video content. So we support sites like Dailymotion or Rumble, which is an up-and-coming YouTube competitor. We're at least either the first- or second-largest video streaming platform in the world. That is what makes it definitely unique from most of these other kinds of platforms, which can hook into some sort of storage. But video is such a specific kind of problem unto itself. That is why if you go to, you know, you'll see these different kinds of products. You'll see that we have the performance, sites, and security suite, but we also have the media delivery and Open Edge suite.

00:21:09 - Anthony Campolo

So those can all be combined into whatever kind of application you want to create. If you want to bring in video stuff, you can do that. But if you want to still build just a regular old blog or e-commerce site, you can do that. So it's going back to what I said, where this is not something you would ever need to migrate off of. No matter what you want to build, what kind of application or experience you want to create, it's all there for you. You don't necessarily have to dive into it all immediately, but it's not something where you're like, okay, I have this nice deployment platform, but then when I want X, Y, and Z, I need to integrate tool X, Y, and Z. I guess it's all there.

00:21:46 - Paul

What do you think is an area that Edgio is currently working on and developing in that you think tackles some problems or offerings maybe that some other providers have, that you think might open up the door for some applications? That Edgio may not be the first stop that people think of, that, oh, these features are coming out, it's going to enable more people onto the platform. What's in the works right now?

00:22:11 - Anthony Campolo

Yeah, I think having a really well-integrated experience in terms of how you actually test and tune and record performance. Because what a lot of people right now, and I think especially a lot of beginning web developers, are taught is you create a website, once it works, you run it through Lighthouse or a similar tool, you look at the scores it gives you, you get the advice it gives you, and then you change the stuff it tells you to change until the numbers go up. Once the numbers go up, then you dust your hands off like, all right, I did it, the site's performant. That's not really the whole story a lot of the time, because any type of measurement is only going to measure what it's measuring, and there are actually things outside of Lighthouse that are going to be happening in an application that might not be getting captured. So you can have all 100s while still having a slow user experience. If you are having to do super-slow page transitions and things like that, the real thing you want is RUM, real user monitoring, which doesn't run a synthetic test.

00:23:20 - Anthony Campolo

Because that's the other important thing about Lighthouse. It's testing certain things, which gives it certain biases in terms of what it's scoring you on. But then it's actually not like running the site and having a user use it and then telling you what the performance is. It's running it in a fictional kind of environment where it's testing things out and seeing what the results are. For the most part, this works. It helps you optimize, and it helps you make your website better and faster. But it's not exactly the same as the experience an actual user will have if they just go and use your website. What you want to do to get that is just have them use your website, and then you record how long it takes for stuff to happen, and that's your thing. So it's actual, empirical data versus a rationalist method. You're actually going to gather data that tells you how fast or slow your site is. I remember the first time I learned this as a thing, I was like, why is that this weird obscure thing that almost no one I know is using?

00:24:19 - Anthony Campolo

That seems like the thing we should all be using. Lighthouse should be kind of a nice extra thing you can use. To me, it seems totally flipped around.

00:24:27 - Paul

So do you feel like Edgio is going to help developers and teams step into that testing space a little easier, since we're talking about what's new and upcoming?

00:24:37 - Anthony Campolo

Well, not so much. The capabilities are already there. So it's very easy to get a script in. You have a tab in your dashboard specifically for this. The thing that I want to help people with is just explaining both the value of this and then creating content around showing how to do it. Because I feel like this should be more of a core skill that web developers have: how do you actually install these scripts onto your site to really monitor the performance, and then how do you run A/B tests to see what the changes you're implementing, what the downstream effects are of that? So that's the type of stuff that's already in there and you can do, but the whole platform itself, there's a lot of different things you can do. So I really want to help draw that story out for users with the content I'll be creating and just showing how this is what's going to help us get out of this. Going back to the single-page-application problem, as we get more comfortable building these workflows into our normal development environment, we're going to continue to get more and better visibility into all of the different aspects of our site's performance and all the different ways we can tweak it and change it.

00:25:54 - Anthony Campolo

And which things are actually going to be moving the needle and which are just things you're doing that don't actually make it faster. There's this term, like security theater, like performance theater. It's like, oh, I changed from this framework to this framework, so now it's faster. Well, did you benchmark it? Is it faster? Do you actually know it's faster? Have you just been told this framework's faster?

00:26:15 - Paul

You know, my follow-up question to this was: do you feel, Anthony, very strongly about there being like a common silver bullet? I don't even want to call it a silver bullet, but like a common area of, we can call it misconception, when people are trying to tackle this problem. One you just mentioned right here is relying on the words of others, which is like this framework says it's faster, so if I use it, it's going to be faster. Well, no. I mean, it depends on how your application's architected, and there's a lot of other factors to look at. But do you, Anthony, have any uncommon opinions about this topic that you obviously are very excited about? You're going to be making content on it for people, like a core skill that kind of flies by people.

00:27:02 - Anthony Campolo

Yeah. And that's why I would say there is no silver bullet for performance. When you hear this whole "it depends" thing when it comes to engineering, this is an area where it depends so heavily on so many things, both your use case and what you're trying to do and what tech you're using. So that's why for me it's more about what are the mental models we need to get to be able to start to understand what does it depend on. Because when you have a new framework that comes out and says this is more performant, that can be true, but it's going to be more performant in a specific way. Just because it's going to be more performant for 90% of use cases, it might be less performant for 10% of use cases. You need to know which one of those you're in. So sometimes you can migrate to a quote-unquote faster framework and make your application slower if you understand what that framework is doing. That's why everyone now is trying to understand basically what's partial hydration, what's React Server Components, and what is islands? How does all this stuff relate to each other, and what is going to be the best approach, and how is that going to work into the DX?

00:28:14 - Anthony Campolo

So that really needs to be worked out on the framework level, and then once that's worked out, all the deployment platforms can figure out how to make that really nice and easy. The thing I worry about is that we're not going to pick an approach, or we're just going to have all these different ways of shipping different amounts of JavaScript, and that's going to be extremely confusing for people, and already is. So I'm hoping to see more consolidation around that. But this is the blessing and the curse of open source JavaScript, is that it's a free-for-all. It's a dancing landscape. It's a great term. Orta taught me that. There is no centrally planned thing where we can all say, okay, this is what we want to optimize on. Let's create a five-year plan, optimize on this metric, where everyone's going their own way and hopefully one will rise to the top, or some will be good for certain use cases, some will be good for others. Something I've been saying is that I'm bringing back the, they used to say Svelte is for sites, React is for apps.

00:29:16 - Anthony Campolo

I've been saying Astro is for sites, Qwik is for apps. Because I think those both represent like Astro is the new kind of static site generator with a little bit of interactivity, whereas Qwik is the new super interactive but still performant kind of tool. And then you have things like Solid, which kind of sits in both those camps. Then React Server Components now is finally getting some attention, and that is the one that could have the biggest impact on the overall ecosystem. Because if all of the React frameworks move to React Server Components, then all the other frameworks might then be like, okay, this seems like kind of the model we're all going with. But if only Next goes to React Server Components and all the other React frameworks don't, then there'll be less of an incentive for non-React frameworks to adopt a similar server-component-type model.

00:30:08 - Paul

Yeah, it's good. I mean, it's the leader of the group, essentially. Anthony, if people wanted to hop into Edgio today, if they were in the user interface for the first time and they wanted to deploy a site, what are some of the immediate first sections or buttons or names that people might see, just to make sure they're in the right spot?

00:30:34 - Anthony Campolo

Yeah, so go to Edgio docs and check out just the basics or the Sites feature in particular. I think that's probably the easiest one to get set up. If you go to Sites and then Frameworks, you can find a template for any of your favorite frameworks. We have some that we consider quote-unquote tier-one support, which means they're being consistently updated with the new versions and getting the new features. So these are essentially Nuxt and React proper. That will probably expand at a certain point. But then we also have templates for every other framework you can think of. They may or may not be on the latest hotness. We're probably still on Astro 1 and not Astro 2, for example, but there's a good guide and template for each of those. Then you'll learn how to use the Edge CLI. It's a really nice experience. And if you happen to have your own framework you're building for whatever reason, you can actually use our connectors. You can actually build your own framework connector as well, which is really easy to do. I kind of did a little bit of that with Redwood back in the day.

00:31:39 - Anthony Campolo

So yeah, I would say check out that, check out the Sites, and then once you start kind of building that out, you can start checking out the performance and security features and all that other stuff.

00:31:48 - Paul

And Anthony, if people wanted to hear more from you, like we said at the beginning of the podcast, you've been on two other episodes with us here at PodRocket. Where do people follow you, on your Twitter or other postings?

00:32:01 - Anthony Campolo

Yeah, my handle is ajcwebdev all across the internet. I even have an ajcwebdev.com blog now built on Astro. And yeah, I'm on Twitter, I'm on GitHub, I'm on Twitch, and I love talking about this stuff. And FSJAM is my podcast where we cover all of these frameworks. I've interviewed a lot of the framework authors. And I definitely need to mention JavaScript Jam. This is something that was already being run by the community team at Edgio when I joined. It was actually one of the things that got me interested in the company, because I'd been going to these weekly Twitter Spaces they'd been doing. They've been doing them so long, they used to be Clubhouse, but now they're Twitter Spaces. Every Wednesday at 12 PM Pacific, we either have an open mic where we talk about JavaScript news in the last week, or we have a specific guest and we interview them about whatever they're working on. I really enjoy those because it is like a live podcast recording where you get these great guests, but anyone in the audience can come up and ask a question and become part of the podcast.

00:33:05 - Anthony Campolo

And then we have a weekly newsletter where a lot of the material we talk about is sourced from.

00:33:10 - Paul

So all that is at javascriptjam.com. Anthony, thank you for your time. And for people who want to hear more, you can go check out Anthony's podcast, FSJAM, hear more about the latest and greatest in the JavaScript ecosystem, and definitely check out the other two episodes at PodRocket. Thank you for your time, Anthony. It was a pleasure.

00:33:31 - Anthony Campolo

Yeah, thanks Paul. Always fun getting to be back on PodRocket.