JavaScript Package Registry and React 19
A discussion on JavaScript’s new package registry, React 19’s upcoming features, and core web vitals, alongside community insights on performance and AI.
Episode Description
Anthony and Ishan discuss Google's Core Web Vitals INP metric switch, JSR as a potential NPM competitor, React 19's compiler, and AI's impact on developers.
Episode Summary
This episode of JavaScript Jam covers three major stories from the newsletter. The conversation begins with an in-depth look at Google's upcoming switch from First Input Delay to Interaction to Next Paint (INP) as a Core Web Vital metric, with Ishan explaining why FID was easy to game and how INP better captures real interactivity across an entire page session. He walks through the differences between lab testing via Lighthouse and real user monitoring, illustrating how they can diverge and why developers should start with field data before diagnosing issues. The discussion also touches on the challenges of A/B testing performance without introducing measurement artifacts. From there, the hosts examine JSR, Deno's new TypeScript-first package registry aimed at competing with NPM, framing the challenge through the lens of network effects and ecosystem lock-in that has historically slowed adoption of Node alternatives. The React 19 segment focuses on the long-awaited React Compiler for automatic memoization and the new Actions API for server-side mutations, with both hosts noting the significance for the React Server Components migration. The episode closes with audience participation, a discussion about whether open-source developers should be compensated for AI training on their code, and a brief mention of Edgio's new AI integration examples.
Chapters
00:00:00 - Introduction and Newsletter Preview
Anthony and Ishan welcome the audience to JavaScript Jam Live, their biweekly Twitter Space where they discuss the JavaScript newsletter and take questions from listeners. They describe the show's open-mic format and encourage audience participation throughout the session.
After introductions, the hosts compare notes on which newsletter stories they found most compelling. While Anthony chose JSR and React 19 as the featured stories, Ishan highlights Core Web Vitals, kirimase.dev, QWIK innovations, and Redwood JS 7 as items he would have spotlighted. This divergence sets up the episode's agenda and leads them to start with the most time-sensitive topic: Google's imminent Core Web Vitals metric change.
00:06:00 - Core Web Vitals and the INP Metric Switch
Ishan explains why Core Web Vitals matter for businesses, noting that Google organic search drives roughly half of many e-commerce sites' traffic and that ranking positions follow a power law distribution. He clarifies that Core Web Vitals are user experience metrics rather than pure performance metrics, and that they serve as a tiebreaker in search rankings alongside content quality.
The discussion then focuses on the shift from First Input Delay to Interaction to Next Paint. Ishan breaks down why FID was a flawed metric — it only measured the first interaction, didn't check whether the browser actually responded, and was easily gamed with techniques like loading spinners. He uses the bartender analogy from another podcast to illustrate FID's limitations, explaining how INP improves on this by measuring interactivity across the entire page lifecycle and including the time to paint after each interaction.
00:09:24 - Lab Testing vs. Real User Monitoring
Anthony asks whether INP moves the industry closer to better lab-based metrics, prompting Ishan to explain the fundamental difference between Lighthouse simulations and real user monitoring. He shares a compelling example from COVID-era state vaccine pages where Lighthouse scores and actual field data told completely different stories, demonstrating how user demographics, device types, and geographic server placement all affect real-world performance.
Ishan walks through how to use PageSpeed Insights effectively, recommending developers start with the field data section at the top before looking at Lighthouse diagnostics below. He explains the distinction between origin-level and URL-level Core Vitals data and notes that developers should identify which specific metric is failing before attempting optimizations, comparing it to diagnosing a problem before performing surgery.
00:20:50 - Optimization Strategies and A/B Testing Performance
Anthony references optimization strategies from a previous article, including reducing excessive JavaScript, breaking up long tasks, using web workers, and minimizing complex layouts. Ishan agrees these are sound approaches but emphasizes that the first step should always be examining real user data rather than jumping straight into Lighthouse-driven fixes.
The conversation shifts to A/B testing performance changes, where Ishan explains why traditional client-side A/B testing actually hurts performance by adding JavaScript overhead, and why server-side testing introduces cache management headaches. He describes how Edgio's platform solves this by preserving cache keys across experiment variants and automatically connecting the experimentation system to their RUM tools, enabling teams to confidently test and deploy performance improvements.
00:33:02 - Audience Introductions and JSR Discussion
The hosts invite audience members to join the conversation, welcoming Jason Cline back and meeting Jules, a game developer working with a browser-based 3D engine built in JavaScript and TypeScript. Jules shares his enthusiasm for listening and learning, setting the stage for his later contributions to the discussion.
Anthony introduces JSR as Deno's TypeScript-first package registry and potential NPM competitor. Ishan frames the challenge through network effects theory, referencing the NFX blog post about different types of network effects. He observes that Deno's history of walking back its original "no Node compatibility" stance demonstrates how powerful NPM's ecosystem lock-in really is, and draws parallels to efforts like UNJS and Hono that have gained less traction than expected in moving JavaScript beyond Node-specific APIs.
00:44:00 - React 19, the Compiler, and Server Components
Anthony introduces React 19's headline feature — the React Compiler for automatic memoization — tracing its origins back to 2017. Ishan explains the basic principle of memoization as caching computation results and acknowledges the enormous engineering challenge of making it work reliably across millions of diverse React codebases, noting that even a small percentage of edge-case failures would affect many developers.
The discussion extends to React 19's Actions API for server-side mutations, which Anthony connects to Redwood JS's migration from GraphQL to React Server Components. He candidly shares that despite following RSC since its December 2020 announcement, the Redwood community still faces significant challenges in migrating existing GraphQL-based applications, highlighting the fundamental paradigm shift involved and the code mod tooling that will be needed.
00:53:33 - NPM Unbundling, AI Ethics, and Closing
Jason shares a link about the debate over unbundling NPM from Node, which the hosts see as potentially enabling greater interoperability between Node, Deno, and other runtimes. Anthony mentions Edgio's new AI integration examples with LangChain, Llama Index, and Mistral that JavaScript developers can deploy quickly.
Jason raises the question of whether open-source developers should be compensated when their code is used to train AI models, comparing it to the ongoing New York Times lawsuit against OpenAI. The hosts explore different angles — Anthony suggests microtransactions and crypto as theoretical solutions, while Ishan notes the legal complexity of machines doing what humans have always done with information. Jules teases his company's upcoming game jam before the hosts close out, encouraging listeners to subscribe to the newsletter and check out past episodes.
Transcript
00:01:22 - Anthony Campolo
All right. Welcome to JavaScript Jam. What's up, Ishan?
00:01:34 - Ishan Anand
There we go. Can you hear me?
00:01:35 - Anthony Campolo
There you go. I can hear you now.
00:01:39 - Ishan Anand
Let me retweet this, or repost it as it's now being called.
00:01:45 - Anthony Campolo
Oh, yes, yes, yes.
00:01:47 - Ishan Anand
Oh, hang on. Give me a second. I need to switch my connectivity.
00:01:51 - Anthony Campolo
Are you on your phone or your computer?
00:01:54 - Ishan Anand
I am on my phone. Yeah, I've forgotten that you can now join by desktop.
00:01:59 - Anthony Campolo
I know. I'm still using my phone just as a force of habit. Been doing this too long, man. Too long to change now.
00:02:07 - Ishan Anand
I remember the old days.
00:02:10 - Anthony Campolo
I remember Clubhouse.
00:02:12 - Ishan Anand
Yeah, exactly. Hang on just a second.
00:02:16 - Anthony Campolo
Yeah, take your time.
00:02:16 - Ishan Anand
It had to be iOS only.
00:02:18 - Anthony Campolo
Yeah. I'll give us a little intro while you go. Welcome, everyone, to JavaScript Jam, where we talk about the JavaScript news of the week. We had a double feature in our newsletter this week for stories of the week. Both of them I'm very interested to talk to Ishan about. I think they're pretty exciting projects. We got JSR, the first ever serious competitor, in my opinion, to NPM, and we also have React 19 coming at you. Feels like just five years ago React 18 came out, you know, so they're probably due for one, I would say. But yeah, let me go ahead and share those on the doobly doo.
00:03:08 - Ishan Anand
Yeah, while I kick us off, welcome everyone to JavaScript Jam. We sometimes call this JavaScript Jam Live. JavaScript Jam is sometimes a YouTube channel, sometimes a podcast, sometimes a Twitter Space, and all of the above we call JavaScript Jam Live, the twice-a-month conversation we have on X. Oh, it's also a newsletter, which, by the way, if you've not subscribed, go to javascriptjam.com and hit the subscribe button. But Live is our chance to get closer to the audience, so to speak. And we often discuss what's in that newsletter, which Anthony is going to post on the Jumbotron, but also anything the audience wants to talk about. We very much view this as an open mic. Anything that's JavaScript or web development related is on topic. The newsletter, which Anthony has done a great job with, is designed to inform and also stimulate conversation. But some of my favorite conversations happen because somebody came, raised their hand, and said, "I want to talk about X. This is what I'm seeing on my Twitter feed." And then sometimes we don't even have the answer, and somebody else in the audience is able to answer. So those have been some of my favorites.
00:04:23 - Ishan Anand
So don't be shy. Feel free to hit the request button. We're happy to bring any of you on stage. And with that, I should introduce myself. My name is Ishan Anand. I'm the VP of the applications platform here at Edgio, and I am Anthony
00:04:40 - Anthony Campolo
Campolo, developer advocate here at Edgio.
00:04:47 - Ishan Anand
You did mention those are the features, but one of the things I liked, by the way, about having you do the newsletter is you pick different things to highlight than I would. There are some great things in there, but the things that I would have put as features are slightly different.
00:05:04 - Anthony Campolo
Actually, I'd be curious to hear what those are then.
00:05:07 - Ishan Anand
You want to start with those? Yeah, we can start with those. It sounds like you were dying to talk about JSR, which is really important, and React 19. We can talk about React 19 because that was on my list as well. But the other things that were on my list that you had were kirimase.dev, which is like trying to build Ruby on Rails, the Node.js trailer, I remember when Node came out, I have, let's call it, contrarian opinions about that. I thought the QWIK innovations were really interesting and fascinating. I want to get your opinion on RedwoodJS 7. So those are the things that I thought. Oh, and Core Web Vitals was the most pressing and important thing to me because that's like a freight train coming at the web right now in basically two weeks, March 12.
00:06:00 - Anthony Campolo
What are you referring to in terms of Core Web Vitals?
00:06:03 - Ishan Anand
So Google is switching the Core Web Vitals from these three metrics. They're swapping one of those metrics out.
00:06:12 - Anthony Campolo
So yeah, INP, right?
00:06:14 - Ishan Anand
Yeah, they're switching.
00:06:15 - Anthony Campolo
Yeah. I mean, that was a headline like three months ago or something in the newsletter specifically, so that's why I wouldn't have felt the need to include it in this week's. But did that switch happen now?
00:06:28 - Ishan Anand
That happens in two weeks. You're absolutely right. We did cover it back then, and I...
00:06:32 - Anthony Campolo
Because we're that far ahead of the game.
00:06:35 - Ishan Anand
Yeah, exactly. Well, it's worth it. Let's start with that.
00:06:39 - Anthony Campolo
Let's talk about that.
00:06:41 - Ishan Anand
Yeah, it's a great one. First of all, this is an announcement that's been a year coming. Google told us a year ago it was coming, and most people probably put off worrying about it. So why is this even important for most companies? For a lot of companies, especially e-commerce companies, Google is, if not your number one, in your top three sources of traffic. Wolfgang Digital did a study, and they found that Google organic traffic was something like 50% of a lot of e-commerce companies' traffic. So the traffic that Google sends you is hugely important. And as a result, your position on the SERP, or search engine results page, right, those blue links, is hugely important. It's actually a power law. So when you go from 1 to 2 to 3, you actually might lose a quarter of the traffic. So number one can get something like four times as much traffic as the one below, or 30% to basically double, depending on the industry and the search term. So it's hugely important that you have the best possible search engine rank that you can.
00:07:51 - Ishan Anand
And what Google has said is one of the new factors that they rolled out a few years ago is this thing called Core Web Vitals, which rates how fast your website is. And since we're on audio, you can't see me putting "fast" in air quotes, because these are user experience metrics, they're not performance metrics. People often say that Google is ranking your site by how fast it is, but not all three of the metrics are actually speed metrics. And so if your site is faster and passing these thresholds for these three metrics, then if there's a ranking tie, the faster one will win. And Google has said, to be fair, that the quality of the content is usually a stronger ranking factor than the speed. But this is why this means huge amounts of money for folks. And they took one of those metrics, which is called First Input Delay, which is a metric I've never liked. I didn't like the one they had before, which was TTI, or Time to Interactive. I can go on my rant about that, or I can point you to my YouTube video where I walk through an example of a very fast site that TTI says is slow.
00:08:55 - Ishan Anand
And they're replacing First Input Delay with another metric called INP, Interaction to Next Paint. And I can get into briefly what those mean, but the key difference is those are radically different metrics. So much so that you could be passing Core Web Vitals right now, and you could be failing it starting on March 12 simply because by this new metric you're failing, because it measures something completely different.
00:09:24 - Anthony Campolo
Yeah, and this is super interesting because you and I for years now have been having this conversation about Core Web Vitals and Lighthouse, and which of the things they measure are kind of the best way to really test the speed of a site. And you've been a big advocate of things like RUM, real user monitoring, as a kind of more realistic benchmark. Do you feel like this gets us closer to a more useful metric that can be done in a lab kind of environment? Is that kind of the goal here?
00:09:55 - Ishan Anand
I don't think that's the goal here. Let me back up and explain for the audience the difference for anybody who's listening. So a test like Lighthouse is a simulated test, or a lab test. You load up a webpage in your browser, you run Lighthouse on it, and it's very consistent. You can try it the next day. It's the same machine. Hopefully you're not running a bunch of other things in the background. And it should be very, very repeatable. But it only tests your site's performance in the conditions that you tested it under. You know, if you're on your desktop with a great connection, you're effectively testing it there. And it can emulate what a mobile user might experience, but it doesn't emulate what your mobile users actually experience. Real user monitoring measures what's actually happening on the page. Every time somebody views your page, a bunch of little performance data is being captured and being sent back to some server and aggregated together. And I'd be remiss if I didn't say that Edgio has a free RUM library built into our platform that does support INP as well, so that you can measure that.
00:11:02 - Ishan Anand
The reason why your lab and RUM data don't always line up is because the profile of your users might not be the same as how you tested in Lighthouse. So a great example of this was actually during COVID, and somebody went and did a performance study of every state's COVID response page. This was for the vaccine rollout. And they tested them all with Lighthouse, and they were like, I can't remember, but something like 70% of them didn't pass. And then I went, well, let's look at the RUM data. Let's look at the Core Web Vitals. And it turns out a bunch of them actually passed. In fact, there was one where the Lighthouse score was red and another where they were green across two different states, but the RUM data showed that they both were passing. This can happen because you might have a different set of demographics of users in terms of iPhones versus Android, which tend to be slower, that might visit your site. You could have different-size viewports, which might affect how your LCP, or Largest Contentful Paint, shows up. What the largest item on the page is can change.
00:12:09 - Ishan Anand
If the size of your screen changes, that can change your LCP score, which is another of the Core Web Vitals. It could be all your users are in one state and you hosted your website across the country in U.S. East, Virginia, and you're, I don't know, in the state of Oregon, when you should have done it in the Oregon data center. And so all those requests have to go further, and you might be a contractor sitting on the East Coast and thinking it's fine. So there's a lot of reasons that can happen. I think the change from FID, First Input Delay, to INP was about something else. The problem with First Input Delay, as is implied by the name, is that it only captures the very first interaction. And in fact, it doesn't even capture what you would think it captures.
00:12:58 - Anthony Campolo
So couldn't you say, though, just to play devil's advocate, couldn't you say the first interaction is extremely important?
00:13:06 - Ishan Anand
You can. The problem is it's easy to get wrong or to fool. So this is something actually in the podcast that you linked to they talked about, and something I've talked about a lot. Sometimes the easiest way to hack Core Web Vitals is to just put a loading spinner as your first loading thing, and then...
00:13:25 - Anthony Campolo
Right, because then it seemingly just loads a whole page and then it's there. But really, I think you told me also, like, you could just give a kind of white screen and have it kind of register that and then think that's the first page. So you're tricking it.
00:13:40 - Ishan Anand
All sorts of people come up with newer and newer hacks, and they sometimes work around it. But in the case of First Input Delay, a great example is especially with Next.js sites, which are server-side rendered. First you get the server-side render, so you see the UI, and then it has to hydrate. And if somebody clicks on a button, because the page is server-side rendered, you can see it, and there could be a button there, but the JavaScript hasn't been connected to it because the page is unhydrated. And if all that JavaScript is downloading, it has or hasn't even run yet, you can click on it and nothing will happen. But First Input Delay will say you're done, because the way First Input Delay works, it just looks for the first interaction on the page and it says, could you have responded to that? It doesn't even measure if you did respond to it.
00:14:28 - Anthony Campolo
Interesting. So if you were to add an island or something, which is one of the problems that's meant to solve, would that not really affect your First Input Delay?
00:14:38 - Ishan Anand
Say that again. If you added an island.
00:14:40 - Anthony Campolo
Yeah, because the point of an island with this first-interaction issue is that you want to just load the single button so that someone could click that button, but you don't have to worry about all the interactivity down the page.
00:14:53 - Ishan Anand
Yes. If you isolate that to an island, then all that island's JavaScript could load. But to First Input Delay, that actually might be worse. Just having a button that is nonfunctional is fine to First Input Delay. It's the idea that FID implicitly is a poor measurement of what they're trying to capture, which is interactivity.
00:15:13 - Anthony Campolo
I think I understand now. Yeah.
00:15:14 - Ishan Anand
Right. So there's actually a great analogy on the JavaScript Jabber podcast, which I really loved, which is: imagine you go into a bar and it's really busy, and so it takes you a while to ask for a drink, but then it may take them a while to get you the drink and bring it back. And all First Input Delay measures is, how long did it take you to place your order to the bartender? Now, the bartender could give it to you immediately, or he could get a bunch of other orders and get busy and not give it to you for a while. But it just measures how long it took you to be able to give your order. And so what happens, to make that concrete inside the browser, is if there's another piece of JavaScript running when somebody clicks, and it takes longer than 50 milliseconds for that JavaScript to finish so the click handler can run, then it says you're being slow. If it has to wait longer than that amount of time, that's effectively First Input Delay. And one of the problems here is it's very dependent on when the user clicks.
00:16:16 - Ishan Anand
Imagine you've got two big pieces of JavaScript that need to execute. If the user clicks in between those two pieces and there's no JavaScript running, then it will seem fine to First Input Delay. You could have responded even if you didn't, because that JavaScript hadn't loaded the second piece. But to First Input Delay, it's okay. So it's really, really subject to a lot of vagaries. And in practice, a lot of sites don't have trouble passing First Input Delay. In our experience, it's actually one of the least likely to have problems, even if you think of the site as being slow, because the first input actually tends to, for a variety of reasons, as measured by RUM, be fine. What INP tries to do is say, well, over the lifetime of the page, the entire session, how interactive does this page feel? It's a much better sense of, is this page usable? That loading spinner isn't necessarily going to show up if, after the loading spinner is done, everything else comes on and the site's taking a while to paint.
00:17:20 - Ishan Anand
Like, the whole process of taking the click and responding and having a paint happen afterward is now part of the measurement, and it's actually measuring it for the entire lifetime of the page. It's looking at the whole page. In some cases it will throw out outliers for really, really long occasional requests. But it's basically trying to capture, over the whole lifetime of the page, every time the user clicks, do we get a paint very quickly back? Whereas First Input Delay only looked at the very first click and didn't even bother to look at how long it took to paint. So I think it's a much better sense of interaction. I think that's what the change is here. I mean, the real goal of Core Web Vitals is, the web went through this, I don't want to call it an identity crisis, over the last decade and a half, maybe two decades, of mobile, where we had to compete with native applications, and native applications are competing with the web on device, and those experiences are fast and compelling. And we've been trying to find a way for the web to compete with that. And nobody is more incentivized.
00:18:34 - Ishan Anand
Even though Google owns Android, so much of their business comes from the web. They want the web to feel as good as native, and it's trying to get that experience bar. That's why you have a set of metrics about three different things that aren't really performance metrics. They're actually about user experience. The first one is, how fast does it load? Your native app loads very quickly. That's covered by LCP. The second one is, how fast does it take to interact with? How fast does it take to respond when I'm playing with it? Native apps are notoriously a lot faster. The last one is why you have Cumulative Layout Shift. Historically, when you'd load a web page, lots of people would not put the height and width on images, and the browser wouldn't know how big that image would be, so it would put a placeholder and then it would download the image and really know how big it was. And so web pages have a habit, as different things come in and load, of jumping all around the place. Native apps never did that. For the most part, they don't.
00:19:33 - Ishan Anand
It's possible to end up with that situation. And so when you look at those three metrics, really I view it as trying to make the web compete with native on mobile. That, to me, was the impetus, and this is just refining that to better capture it. My soapbox. Yeah.
00:19:52 - Anthony Campolo
Yeah, that's cool. A couple follow-up things. This was almost a year ago now. I posted the original article where we talked about this back in May, and I had linked to a guide that split optimization strategies into two buckets that can cause poor INP. One was excessive JavaScript, so they recommended things like refining long tasks, reducing input delay, evaluating your scripts, and utilizing a web worker. They did say here to use Partytown. The other bucket was slow rendering, where you want to avoid complex layouts, reduce your CSS style calculations that you can do now with all your fancy CSS, keep your DOM a reasonable size, and look at your client-side rendering of HTML. Do those sound like still-good strategies based on what you know about this metric, or are there other things you would want our listeners to know about?
00:20:50 - Ishan Anand
No, I think those are good strategies. I think the first thing I always say is, actually, the number one thing is people run Lighthouse, and I would say first look at your Core Web Vitals or look at your RUM data before you do anything else.
00:21:03 - Anthony Campolo
What do you mean by that? Look at Core Web Vitals instead of Lighthouse? Because I thought Lighthouse showed you your Core Web Vitals.
00:21:10 - Ishan Anand
Okay, Lighthouse. So there's PageSpeed Insights. I think that's what they still call it. Let me go to the website. So PageSpeed Insights will show you both your Core Web Vitals and your Lighthouse score. So it'll show you both lab and field. And it used to actually give you a number at the top, and that was Lighthouse. And then right underneath it, it gave you the field data. So it was really, really confusing in their layout. And so that's what I mean. Lighthouse is either something you run on your computer or you go to PageSpeed Insights, which will run it for you. But when you type a URL into PageSpeed Insights, the part at the top now is just the field data. And it'll say "Core Web Vitals Assessment" and it'll give you your Core Web Vitals. And then below that it says "Diagnose performance issues," and that will spin as it's running the lab test and give you those four numbers inside the circles that tell you how well you're performing according to their simulation. And those two may or may not be aligned.
00:22:19 - Ishan Anand
And so that's why I say, now I can tell people what I couldn't before: just start at the top of PageSpeed Insights and work your way down. And if everything at the top is green, then you don't have to worry as much about things down below. And if the things at the top are not green, focus on the ones that are red. Like, if your Cumulative Layout Shift is your problem, then it's unlikely shrinking the size of your JavaScript is going to help at all with that. And so you need to look at where you're failing first in Core Web Vitals before you go into Lighthouse. To diagnose a problem, you have to know what the problem is before you go in and try and do surgery on the site. Yeah, go ahead.
00:22:57 - Anthony Campolo
Are you talking about the tab where it says, discover what your real users are experiencing?
00:23:01 - Ishan Anand
Exactly, yeah.
00:23:02 - Anthony Campolo
Okay, so for mine, I just tried my own website. It says no data. The Chrome User Experience Report does not have sufficient real-world speed data for this page. So I just get a single number. This is why I was really confused what you were saying. I've never gotten two numbers from PageSpeed Insights.
00:23:17 - Ishan Anand
Okay, so type in, I don't know, like Amazon.com, right? Anything really big, and you'll get two numbers, or two sets of numbers. Interesting. The other thing you'll notice...
00:23:28 - Anthony Campolo
Oh, wow, this looks very different.
00:23:31 - Ishan Anand
Yeah, exactly. So this is what your real users are experiencing. And then actually at the upper right, directly to the right of where it says "Discover what your real users are experiencing," it says "This origin" and then "This URL." And so one is for your Core Web Vitals across the whole domain, and the other one is for the Core Web Vitals for that particular URL. So if you just type in Amazon.com, it defaults to This URL right now, so it's just for the homepage. But if you want to know the whole of your website, or whatever website you're looking at, hit Origin and it will give you the entire website.
00:24:10 - Anthony Campolo
Yeah, and there's an interesting thing here, just since we're already talking about INP. When I do that, when I switch from This URL to Origin, it gives a little warning next to INP and says, "In rare cases like this, the histogram data may not reflect the 75th percentile number. The 75th percentile is always used to assess if the metric is passing." So I guess that's just kind of saying statistical artifacts can affect your score.
00:24:34 - Ishan Anand
Yeah, I should dig into that. So I know that INP trims outliers. That might be what that artifact is referring to. I've encountered situations where Core Web Vitals differ from what the RUM data says for weird, esoteric reasons. So, for example, the browser, as it records Core Web Vitals data, has information across frame boundaries that are on different domains. But that's hidden from your RUM tools. So when we built our RUM product, we were testing it and noticed that there was this discrepancy, and we sent the example to them, and they said that's the reason. But this one right here, I don't know the specific details. It could be a statistical artifact. I'll have to dig into that one. I'm seeing that right now when I look at Amazon, but that's a good question. But I'm not surprised. In the aggregate, there can be a slight difference. But I did do a crash course in Core Web Vitals for React developers back in, oh, it was 2021, and I should put that on the Jumbotron. Let me see. I'll put it up here.
00:25:48 - Anthony Campolo
Yeah, I'm also looking at, I feel like we had an article on the Edgio blog that was going to come out about this. I just googled INP and Edgio, and I found an article from 2022 that talks about it a little bit, but I'm not sure if that article's gone live yet.
00:26:07 - Ishan Anand
It looks like it hasn't, but we do have one that's coming out because INP is obviously going to be very topical, and I just put it on the Jumbotron. So I gave this crash course at React Day New York. The parts about LCP and CLS still apply, but obviously it covered FID, First Input Delay, which is no longer relevant. But actually, the most valuable part, I feel, is the beginning of the class, the first half of the video.
00:26:34 - Anthony Campolo
It's not up on the Jumbotron, by the way.
00:26:36 - Ishan Anand
No, it's not. I replied to the message. So let's see.
00:26:40 - Anthony Campolo
So wherever that is, then you have to click the share. Oh, do you reply to something else?
00:26:48 - Ishan Anand
I replied to something else. I know what I'm doing. I'm going to...
00:26:55 - Anthony Campolo
I mean, you could just share it. If you tweeted it anywhere, you can just share it on the Jumbotron, regardless of whether it's in the... Hold on, I'm just going to go to your replies. Yeah, I see now.
00:27:08 - Ishan Anand
You see it now.
00:27:09 - Anthony Campolo
Okay, I got it.
00:27:10 - Ishan Anand
So.
00:27:11 - Anthony Campolo
Oh, because you replied to the [unclear]. There we go.
00:27:15 - Ishan Anand
That's probably why. So I'd just say that the first part of it is still valid, and it's about the strategy for optimizing your site that you should follow. So there's a whole workflow: start with your own data, look at the problems that you've got, try to reproduce those in Lighthouse inside the lab. And then the other key point that's really important is you can't just roll out your change, because Lighthouse and Core Web Vitals don't always line up. You need to test to make sure that things change. In fact, the ideal thing is to do an A/B test, because you might have different traffic during different time periods, so you want to split your traffic between your fix and your original and then see that the Core Web Vitals are actually better. And so there I lay out how you'd actually do that workflow. And that ability to split your traffic is also something that's nontrivial in a lot of platforms, but something we make easier in Edgio specifically. So you can A/B test performance, because regular A/B testing actually hurts performance, but we do it in a way that doesn't do that.
00:28:21 - Anthony Campolo
Why? Why does that hurt performance?
00:28:24 - Ishan Anand
Well, regular A/B testing usually runs client-side. It usually uses some JavaScript, and so if it happens client-side, it means you're running more JavaScript, so it's going to slow down your page in the browser in order to change the DOM. And usually one of them is the control experiment, and that has no JavaScript running to change the DOM, and the second one will run JavaScript to change the DOM, and you'll do things like blanking the screen till the DOM change has taken effect. So your change, whatever your variant is, is actually going to be slightly slower to load. So it's not a true test of performance, it's a test of usability. And in some cases I've seen that blinking actually add hundreds of milliseconds. The other way you do it is you test it server-side. But if you test it server-side, most people don't preserve their cache. And so what happens is you're turning off caching for both pages in order to have two different variants, and it becomes hard to manage. And so what we've built into our system is a very easy way to say, here's a variant, and it will make sure it preserves the cache key and fragments it according to the A/B test variant that's actually taking place inside the system.
00:29:35 - Ishan Anand
So basically the edge is talking to the thing that's controlling the experiment, making sure that it sorts the results appropriately. And then you go into our RUM tool and you no longer have to configure the RUM tool. It already knows what your experiments are and you can see the results. So basically all those pieces talk to each other where normally you'd have to wire them up together.
00:29:52 - Anthony Campolo
When you say most people don't preserve their cache, do you mean most people running their code on the server or most people browsing in their browser?
00:30:01 - Ishan Anand
Ah, good question. I mean on the server. Most people who do an A/B test server-side, they'll usually not preserve it on the cache.
00:30:09 - Anthony Campolo
Gotcha. Yeah, I know most people in their browser, their cache goes back 10 years.
00:30:15 - Ishan Anand
When you're running on the server, you need to make sure you clear the cache in the right way. There's a lot of management headache. So if you clear maybe just a particular page, you need to clear both versions of it. You need to make sure that if you make a change to your A/B testing that you've changed your cache keys appropriately, and yada yada. So it's just a lot of management and workflow overhead. So it makes it harder. So we had a customer who said, we now do A/B tests and canary deploys on Fridays. It's just now so much easier. We're happy to roll it out. We know if there's a problem we can turn one off and we don't have to worry about it. Makes things a lot easier. So you know how, like, some people...
00:30:54 - Anthony Campolo
Like some people, they'll be like, one day I'll take a year-long vacation and I'll study X and finally learn how it works. For me, that's like how to set the cache correctly, because I was broken by the Jamstack. I was like, why would I need to cache? My site doesn't change.
00:31:11 - Ishan Anand
You know, it's funny, somebody tweeted out, I think it was, who was it? Somebody tweeted out, like, is CDN caching still a thing?
00:31:23 - Anthony Campolo
It is for me, baby.
00:31:25 - Ishan Anand
It got renamed to Jamstack. Jamstack certainly simplifies it.
00:31:31 - Anthony Campolo
I mean, it did until it didn't. Once they introduced all these acronyms, all of a sudden you had to think about caching. So that was kind of when I think a lot of people and I started checking out of the Jamstack.
00:31:45 - Ishan Anand
Well, this is when I gave my talk. I called it the Jamstack identity crisis, because what does it mean when you've got serverless in Jamstack? And my own answer to that is that the real value of Jamstack is not about static, it's about bringing data to the edge and then making the rest of the infrastructure exposed to developers in a frontend-friendly way. So basically what ISR does is it changes a bunch of things with caching that you could do yourself, but it's exposing a JavaScript API, a React API for it, that makes it easy as a JavaScript developer to configure the rest of your stack without having to think about it. ISR is something we were one of the first, after Next, to support because we thought it was really important to make it very easy for developers to configure the cache. And even before ISR, one of the things we support is something we called EdgeJS, which allows you to specify the cache directly in your JavaScript code. So it wasn't sitting in VCL or some other thing that you had to manage. Once again, it's like, let's take all this infrastructure and just expose it up to the frontend developer who's in the best place to make decisions about what's cacheable and what's not because they're controlling the experience.
00:32:57 - Ishan Anand
But I think we're going off on a tangent. We should take a station break.
00:33:02 - Anthony Campolo
Yeah, I was just going to say that. You're reading my mind. This is our halfway point. So we just want to encourage both of you out there, Jason and Jules, if you want to come up and talk, you are welcome to. I sent out an invite to Jason when he first joined. I don't know if you saw that or not, but if you guys want to join the conversation, and you've both been listening to us yabber away, you're more than welcome to. Yeah, we love making this interactive. We love having other people be part of the conversation, but otherwise we'll probably transition into talking about JSR. Oh, looks like we got Jason actually.
00:33:43 - Ishan Anand
Howdy.
00:33:44 - Jason Cline
How's it going?
00:33:45 - Ishan Anand
Howdy.
00:33:46 - Anthony Campolo
Going good, man. Happy to hear your voice again. How's life?
00:33:49 - Jason Cline
Yeah, this time slot has been a little busy for me for the last month, so I haven't been able to join. But yeah, it's good to be back.
00:33:57 - Anthony Campolo
Hey, we got Jules up here also. I'm not sure we've ever met before. You want to introduce yourself and let us know who you are and where you're coming from?
00:34:06 - Jules
Can you guys hear me okay?
00:34:07 - Anthony Campolo
Yeah, crystal clear.
00:34:09 - Jules
I just want to say it's been so gigabrain listening to you guys chat. So much of it is over my head. I'm definitely a pleb in this space, but it's been nice to listen to you.
00:34:20 - Jules
Quick little intro. My name is Jules.
00:34:23 - Jules
I am interested in game dev most recently because of a company I work for, a browser-based 3D engine that's largely built in JavaScript and TypeScript. It's kind of how I found you guys. So just here to absorb and learn and make some connections. But outside of that, I've always been building tools for creators and thinking on how to unlock the builder in everybody. So really, again, just stoked to be here and listening, and we'll have to run it back and Google 80% of the things that you said. But I wanted to take the opportunity to say what's up, and I'll pipe down from here.
00:35:01 - Anthony Campolo
Well, yeah, and I mean I feel the same way listening to Ishan talk, so don't even worry.
00:35:07 - Ishan Anand
We just happen to be on performance, which was my huge, huge
00:35:12 - Anthony Campolo
nerd topic for him.
00:35:13 - Ishan Anand
Yeah, we go off on that. I mean, honestly, TypeScript is something I have never used day to day. I've programmed in typed languages, but if we go into TypeScript, I'm just as much...
00:35:28 - Anthony Campolo
Well, this is a perfect transition.
00:35:30 - Ishan Anand
Yeah.
00:35:30 - Anthony Campolo
Because this is one of the things that JSR has, a couple kind of headline features. So this is going to be Deno's attempt at an npm. And I was kind of going back and forth whether to make this a story of the week, because it's probably, today, not that significant, but it has the potential to be significant if it picks up. And that's kind of the everlasting story of Deno, is this is going to be a really big deal if people actually start using it en masse. Which, Deno's gotten some pickup, definitely gotten pickup from some pretty significant companies like Netlify and Supabase. So I think there is a case to be made for running Deno in production these days. But part of the original Deno dream was that it can kind of get us away from Node and all of its stuff, which includes things like your package.json, includes things like npm. And as that Deno vision has been playing out, they've kind of compromised on a lot of those things. You can actually run your Node modules now in Deno.
00:36:40 - Anthony Campolo
A lot of the Node APIs have been kind of backported, but I felt that a lot of people's issues with Node are actually issues with npm. And I think there's a very serious argument to be made for the necessity of alternatives to NPM because of what a crazy attack vector it is, as this single place where everyone's writing code. Not only is everyone writing code, but beginner developers who have no idea what they're doing are running code. And it doesn't have good security defaults. And this is something that we've known for a while. That's one of the things that interests me about it. And the hook to get people in, though, is like, hey, this is going to be a TypeScript-first registry, which, not really sure what exactly that means, but maybe it checks your types in some sort of deployment strategy when you're putting your modules up or something. But anyway, this is JSR. What have you heard about this, Ishan?
00:37:55 - Ishan Anand
You know, honestly, it wasn't really on my radar as much, even though it turns out it was at the Seattle JS conference, so it was local to me in 2023. I unfortunately couldn't make that, but I kind of align with you that it could be big. I look at what Deno has done. What's the way to say it? It's made the right architectural modifications. One of the interview questions I used to ask, or I still ask actually, is let's walk through something you built, right? And at the end I'm like, okay, now what would you do differently? And this is literally what the Deno team keeps doing on everything that involves Node and the whole ecosystem. But to me, the lesson of crawling out of that ivory tower and inching back toward things that have Node compatibility is just a demonstration of how much lock-in there is in the existing ecosystem of Node. There's a great blog post from this VC firm, NFX, about different types of network effects. We think of those as being in social networks, but they point out there can be all sorts of different kinds of...
00:39:14 - Ishan Anand
You can look at everything really as a network effect.
00:39:17 - Anthony Campolo
Network effects manual 16 network effects and counting.
00:39:21 - Ishan Anand
Yeah, exactly. It's a great one. And actually I wanted to write a blog post for a while that was looking at the JavaScript ecosystem as social networks through that lens. You see that in frameworks, you see that in simple APIs.
00:39:35 - Anthony Campolo
Is this like Metcalfe's Law and stuff like that?
00:39:38 - Ishan Anand
It's similar to, yeah, it's very similar to Metcalfe's Law. Metcalfe's Law is a networking principle. It says the more people on the network...
00:39:44 - Anthony Campolo
Yeah, the more people on the network, the more valuable it gets because you get more connective nodes in between. So you imagine a circle of nodes and as they connect to each other, the kind of middle part becomes denser and denser with those connective lines. It's like the visual image that's always associated with it.
00:40:02 - Ishan Anand
The key observation is the usefulness of the network grows faster than the number of people. So adding people grows because each one adds exponentially more through all the number of possible interconnects, and this one...
00:40:15 - Anthony Campolo
connects to an idea like the tipping point. You're a Gladwellian out there.
00:40:19 - Ishan Anand
Exactly. And so a good example of this is some other folks in our industry, I'll call them edge platforms, have, like we do, an edge functions runtime, but that runtime is not Node because Node has cold starts. It also doesn't have the same isolation guarantees you would like for security and a variety of other things. And so we and a variety of our peers are building these non-Node environments, and what ends up happening is people bring their code that, shall we say, is legacy and assumes Node, and they're like, well, it's server-side JavaScript, so it must be Node. And then they expect various parts of the Node API to be there, and they're not. And so there was a movement, I think we talked about this two or three weeks ago, but there was a movement amongst the frameworks to start supporting non-Node environments. So like unjs from the Nuxt team, which was, okay, build to this API, which is very minimal exposure of the Node API, and then your servers that you build in that framework can run anywhere. But that movement has kind of lost a little steam, and it's going to take longer than I expected to emerge.
00:41:38 - Anthony Campolo
What's interesting is, actually, I think Deno had less to do with that, and more these edge runtimes seem to. And getting people onto standard JavaScript seems to be what I've seen pushing it. Hono is a good example of this, Hono.js, where they're like, okay, we're going to make this just based on standard client-side JavaScript kind of APIs, and then whether you're Node, Deno, or Bun, you need to figure those out, which I think is an interesting strategy.
00:42:05 - Ishan Anand
Yeah, so Hono is to me like unjs. But I guess the point I'm coming to is the fact that those have not gotten the pickup I expected a few years ago. Back when we did our composability summit, we had the Nuxt folks talking about it, and I expected more pickup than I've seen in the last few years. And so I think it's a demonstration of how much, I know there's some gnashing of teeth with the way Deno has tried to backward-support Node and then this as a kind of replacement for npm. They look like all the smart decisions, but I'll be interested to see if it lands, because I've seen lots of things architecturally that make sense, and then you kind of have to walk back to be compatible with the social network that is npm. And you're right, they basically looked at it and said, you know, the problem may not be Node as much as it's also npm. Let's solve that problem too. And kudos for being bold like that. But I'll be curious to see what traction it gets, given that the system is an unstated social network. That's my thought, so sorry.
00:43:12 - Anthony Campolo
Yeah, yeah. I would imagine that people coming from other language ecosystems would probably even at the time would probably have looked at your prediction and been like, yeah, right, man. Like it took Python a decade, you think we're gonna get there like two years?
00:43:28 - Ishan Anand
You know, I think that was also the time that Hooks was the only thing that has radically been taken up by an ecosystem, and that was only within React. That's probably the best example you can think of.
00:43:43 - Anthony Campolo
Yeah, that's true. But I will say, when I was in my boot camp, it would have been probably year three of when Hooks was out, and they taught us both, so we still had to learn class components, which is actually way worse than just not teaching us class components at all.
00:44:00 - Ishan Anand
Oh yeah, I can see that, like, here's one way and then here's another way, and, you know...
00:44:05 - Anthony Campolo
Instead of having one way, you kind of figure out you have two ways and you don't understand either of them.
00:44:11 - Ishan Anand
Yeah, I think to me that speaks to they felt they needed to talk to it because it was clear it was a freight train that everyone was getting on.
00:44:20 - Anthony Campolo
But at the same time, knowing that you would hit probably legacy codebases where you'd have to deal with classes, which is the idea behind having to teach it. Yeah. So let's transition into React. We're running short on time here. I called it React 19, the one with the compiler, because this reminds me of It's Always Sunny in Philadelphia. They always have "The One with the Blank" as the episode names. React Compiler is allegedly going to be a pretty big deal, I think. I think you could probably find the earliest video about this, it goes back to 2017, I believe, when it was first announced as being a thing. Yeah, "Taming the Metalanguage," I think, is where they talked about that. But yeah, it's going to be something that is important enough that there have already been other frameworks built to deal with this issue. We've talked about Million.js quite a bit and how that's meant to address some of these things. And the idea is excessive re-renders, because React has this model where every time it needs to update state, it throws the whole DOM away and re-renders.
00:45:45 - Anthony Campolo
And so this can be kind of costly, and this could be a waste. So React Compiler is meant to address that by automating memoization, which would be huge. This is going to be huge for someone like me who never really learned how to properly do memoization, if I'm going to be completely honest. This is probably my role, being more of a dev advocate who tends to build simpler demos to show people how to spin stuff up and less about deep performance optimization. So you, Ishan, probably know a lot more about memoization than me.
00:46:26 - Ishan Anand
Well, I mean, the basic principle is every time you calculate something, if you know the end result of the calculation is going to be the same, you should save that calculation, what it depends on, what its inputs are, and save the output. And any time you see a request for the same inputs, send the same outputs. It's really like caching in your execution code. It's just hard to do that and keep track of all the things that might be changing and what externalities there might be out there. I agree this would be a huge lift. You should not have to think about this in most cases. I think this is long overdue. I agree it'll be huge when it comes out. I'm just waiting. I think it'll be great. They obviously have to make assumptions, and you have to understand JavaScript is so flexible a language, it can make this hard to do. The rules of React even say in the post, we had to basically assume certain things about the rules of the language and the rules of React in order to make it work. What I think is hard is you do this.
00:47:37 - Ishan Anand
It's one of those demos where you're like, wow, this was really great. But then if you're going to try to make it work for all the edge cases, imagine you're React and you're deploying this. I have so much respect for the team, even though it's taken them so long, because I can imagine it sounds like a great thing in principle, but then you actually deploy it to all the millions of people who use React and they're going to run into edge cases, and it's like, okay, which of these can we handle automatically as much as possible? Because even if it doesn't work for 5% of people, they'll be loud. So you want to minimize that as much as possible. So I hope they get it out soon. I'm really excited for it. I think it'll be really, really, really valuable for the performance of websites. It'll be interesting to see, with this, what the impact is for the performance of React sites in general. So you obviously have probably seen these comparisons that compare React versus Astro versus QWIK versus Solid, and look, Solid and Astro generally are really fast.
00:48:44 - Ishan Anand
Astro, I suppose, is kind of a meta-framework, so it depends what you're running on top of it. And React has had some issues. React has a very large surface area. It'll be interesting to see if we're able to tell with React 19 using memoization, and then you don't even know if they've turned it on. But I think it'll be very useful and very valuable. When I first saw the talk, I was like, oh, this? Yeah, you absolutely should be doing this. And part of this problem it kind of fixes, we were talking about Hooks. Hooks emphasized a lot more purely functional components, and by doing that it became more necessary occasionally to do memoization than you had to before. So I feel like that's the part that is kind of overdue. Like when we rolled out more pure functional components as a way of doing things, we needed to have given folks a way that still did rendering as efficiently as possible when those inputs weren't changing.
00:49:48 - Anthony Campolo
Yeah, yeah. I want to talk about another aspect of this blog post, Actions. And then after, I actually saw Jason shared a link that I think was relevant to our last discussion that I would like to get into. But just real quick, Actions, to me, actually could be even a bigger deal if you're not someone who tends to run into a lot of memoization problems, because this is going to allow you to do server-side mutations, which you also wanted to hear a bit about. Redwood V7, we're in this migration from our current GraphQL kind of setup to a React Server Components setup, and GraphQL is what gives you mutations. So this has been a huge question for me, like how are we going to do actions? And this essentially answers it. It's going to be built in specifically to the library, and it's going to basically give everyone else the form experience that Redwood has already had because we have all these CLI generators that create components based on your schema, which was based on your model. And then you have all of your validation, top to bottom, back to your database.
00:51:01 - Anthony Campolo
So there's always been a very, very nice form experience for Redwood. And then Remix, I know, also built out this whole form abstraction that people really liked. So this could be a pretty important addition in terms of, if you're not already migrating to React Server Components, this might be the last piece that can allow you to do it.
00:51:22 - Ishan Anand
You know, I'd love to actually do the segue to that. What are your thoughts on, you know, Redwood 7? I saw the announcement, and for those who don't know, Anthony is on the Redwood team. What are your thoughts on Redwood 7, and what's it like to support server components? I know you guys have started adopting it.
00:51:48 - Anthony Campolo
Yeah, well, I'll also say that I'm technically what you would call core team alumni now because I don't really keep up with it as much as I should or would like to. I made a goal for 2024 to get back into the community, which is still kind of pending. But the main thing I would say is that actually we allow you to use Fragments now, which is pretty cool, which is a GraphQL thing. But it's hard, because if you're going to be switching to React Server Components, it just doesn't make sense to keep doing GraphQL. To me, there's a fundamental paradigm shift that's happening here, and you really have to decide which one you want to do, whether you want to do GraphQL or whether you want to go all in on server components. And it's a lot of code to rewrite if you want to migrate your app. I think once Redwood gets all this stuff working, there's going to be another six months of hardcore codemod capabilities we're going to have to build in to really make this feasible. When they first talked about React Server Components back in 2020, it was December 2020.
00:53:09 - Anthony Campolo
I remember this very vividly. Chris and I went and did a whole podcast about it when the first blog post dropped. And I remember saying, I have no idea how Redwood's going to deal with this, at the time. And here we are over three years later, and I still don't have a lot of good answers to those questions. So it's probably a pretty bearish response, but it's the honest one.
00:53:33 - Ishan Anand
Okay, that makes sense. I mean, it's a huge change. I think other than Next, which leaned very heavily into it, all the frameworks are basically trying to figure out how they adapt to it. Is there anything else? We're coming up at the top of the hour. Is there anything else we didn't get to when you were gathering the newsletter that fell on the cutting-room floor, or anything else that you...
00:54:01 - Anthony Campolo
thought, well, I wanted to... Jason, do you want to talk about that article you shared?
00:54:06 - Ishan Anand
Oh, yeah, no, I don't really have...
00:54:10 - Jason Cline
Not too much specific to share. When you guys were talking about the alternate package registries and all the conversation going on in that space, at the same time there's apparently some drama between Node itself and NPM about whether NPM is going to continue to be shipped with Node, or are they going to be more laissez-faire and let developers choose. And it looks like Myles from npm, Myles Borins from NPM, kind of had an on-the-record statement about it. So I thought that was interesting.
00:54:44 - Anthony Campolo
Yeah, yeah, no, this is super interesting because it's about unbundling NPM from Node, which I think would make a lot of sense, because then maybe one day Node could use JSR, and that would allow more synergies between the different ecosystems and the different frameworks and make things more interoperable. Because I think that's pretty cool. I think that would be pretty cool if this happened. I have no idea if this will happen or not. I have no internal knowledge of the core team dynamics of Node. I'm just reading the tea leaves like everyone else. But Deno has been working to support Node. It could be cool if Node worked to support Deno in that kind of respect.
00:55:29 - Ishan Anand
That'll be really interesting. Looks like, looking at that article, they're going to put it to a vote. Too contentious to make a decision. And the earliest anything would happen is April 2024. That's not too far away. When was this written? How did I miss this?
00:55:50 - Jason Cline
This is like last week.
00:55:51 - Ishan Anand
Oh, wasn't it?
00:55:51 - Anthony Campolo
Yeah, this is pretty recently. Yeah.
00:55:54 - Ishan Anand
Okay. Yeah, that'll be really interesting. I'll be curious to see where that lands. I agree basically with what you said, Anthony. I don't think I really have anything to add to that.
00:56:10 - Anthony Campolo
Awesome. Yeah. And you were asking about other things left on the cutting-room floor. There were not, but we definitely should mention I have built out some AI examples for Edgio that I would definitely like to share with people. And if you're someone who is just a JavaScript dev who knows how to use Next.js or even just vanilla React, this is something that you could deploy right now in 30 seconds and get your own kind of LLM interface up and running. This is something I put a lot of work into in January, and I'm really proud of. So I wanted to take a second to highlight that we have examples from LangChain, LlamaIndex, and Mistral. So all the cool kids on the block, if you know about the AI game, those are the cool kids.
00:57:00 - Ishan Anand
Yeah, no, that's a great shout-out. I'll just put it in the audio for those who aren't there. You can go to docs.edg.io, and then in the left-hand navigation you will see something that says AI integrations. So if you're listening to the recording after this and not seeing the Jumbotron, that's...
00:57:23 - Anthony Campolo
how you get there.
00:57:24 - Ishan Anand
And definitely check it out, give it a whirl, send either us or Anthony directly any thoughts or comments. Really excited to have those integrations because I think it makes it a lot easier to utilize and orchestrate all the complexity that comes with taking an API like OpenAI's interface and actually making it useful. So there's a lot of work that needs to go into that, and this will hopefully make it a lot simpler for folks.
00:57:51 - Anthony Campolo
Awesome. So as we're coming to close it out, we always give our guests the ability to promote some stuff if they want. Jules, did you want to speak a little bit about OnCyber, whatever your game thing is, if you were still at the keyboard? Looks like Nick Taylor just jumped in just for the end. Or Jason, if you have anything you want to promote?
00:58:19 - Jason Cline
I don't have anything I want to promote publicly, but the thing that's been on my mind lately is, what's the developer community's position on all these big entities scraping up all of their code and shoving it into their language models to maybe potentially eventually replace us, or replace some of us?
00:58:41 - Anthony Campolo
Accelerate, accelerate, accelerate.
00:58:45 - Jason Cline
It's the acceleration-versus-decel movement. I suppose you could simplify it to that, but I guess it's not a matter of to do it or not to do it. But should all of us open-source contributors be compensated in some way as we accelerate our way to the singularity? Are we all going to get paid while money still means something?
00:59:09 - Anthony Campolo
Yeah, I mean, my thoughts on this, I think of it the same way I think about books and news articles and all that kind of stuff, and music. I would love to get $10 every time someone streams my demo from 2013, but I don't think that's going to happen. I don't know if it's even feasible to compensate people in any way unless we had microtransactions, maybe. The funny thing is all these problems that exist in AI are all solved by crypto, but all the people who have all these problems are all people who hate crypto. So they're never going to realize that. That's a huge side tangent. But I think having models that can significantly improve your ability to code is enough compensation for me. Even though I'm paying 20 bucks, I would pay 100 bucks for ChatGPT because it is that useful for me as a productive tool. So yeah, it's one of those things. It would be nice if the government could pay us all living wages that we could just live on, whatever, you know. But I'm not sure if these things are really feasible. So that's kind of my thought.
01:00:18 - Ishan Anand
Yeah.
01:00:18 - Jason Cline
Because, I mean, you can't go more than a day or two without a news story about creative people either getting screwed over or maybe getting a licensing deal. Reddit's rumored to have a licensing deal, or maybe that's happened now, for all their content. So content is going to be super valuable. And then I'm thinking about that, like, what's probably pound for pound the most valuable content on the planet today? And it's got to be source code. So what is the value of a New York Times article versus the value of some JavaScript code sitting in a GitHub repository? And so it's just something I've been thinking about, and are there developers just like, hey, yeah...
01:01:09 - Ishan Anand
we'll catch on
01:01:09 - Jason Cline
To the next thing, and we'll be able to ride the wave and we won't be harmed by it, or we'll only benefit, there's only benefits for us as developers with this coming AI revolution. But what about all the work that we've already done? So again, that's right. I don't have any answers there, but it's just kind of the thing that's been bouncing around in my head.
01:01:30 - Anthony Campolo
Yeah, I mean, I think that you will be able to replace most journalists before programmers because someone still has to program the bot in some respect, even if it's a giant, giant foundation model. And the question of are you saying code being the most valuable? Like a New York Times writer would certainly insist that their articles are the most valuable because they're holding truth to power and things like that. So yeah, everyone thinks their content is the most important.
01:02:02 - Ishan Anand
Code is the most valuable, yeah, yeah, yeah. I was just speaking purely from an
01:02:06 - Jason Cline
economic point, purely capitalistic standpoint. Not on terms of humanistic or other values.
01:02:13 - Ishan Anand
But yes, I mean, even with code, I would say you take an article that gets a million views and code in a repo that no one has downloaded, the brand and the interaction could be the most valuable thing. It's a really hard thing to argue, but I understand where you're coming from. One is functional in a particular, very rational way. And I also don't know if we're going to replace the journalists before we replace the coders. I think both will get AI-enhanced and supercharged. But it's worth noting that there is a lawsuit, I think, against Codex. I don't know.
01:02:55 - Anthony Campolo
It's against open AI. But are we talking about the New York Times or are you talking about a different one?
01:03:01 - Ishan Anand
There's one for when Copilot came out for the GitHub copilot. I don't know where that stands.
01:03:08 - Anthony Campolo
Okay. Because the OpenAI one is the one with The New York Times, the one that people are saying could go to the Supreme Court. So that's the one that's going to actually set policy.
01:03:17 - Ishan Anand
That's the most famous one. And that one, I think, is a little problematic because in that case, from what I recall, it was directly regurgitating. I view that as a bug. It's not designed to do that. It shouldn't in theory. The tricky slippery slope here is, what is illegal about a machine doing that that a person could do, right? You could imagine a person in theory doing that and doing a variety of things that people say, like it's reading 20 articles and summarizing them. We ask people to do that all the time. And the existing copyright law says certain things like you can't copyright an idea. You can copyright a certain instantiation of it. I agree it's a tricky issue we'll have to figure out. I have many thoughts here, but I don't think we have enough time, and it's a very important and tricky issue. But I can see a lot of the sides here on this one.
01:04:21 - Jules
That'll have to be next week's topic, so we'll have to unpack. There's a big blue ocean there between some of the centralized engines and some of the open-source engines. And I do think that there's a solve out there, and it's interesting. It's going to be really curious to see what develops, but I'll slightly shill a little game.
01:04:38 - Anthony Campolo
No, please do. Absolutely do.
01:04:40 - Jules
We're hosting a little game jam. It's a very early, halfway closed, halfway open beta project. It kicks off this weekend. Got 1500 bucks in prizes. But outside of that, I'd love to connect with all of you because I learned a ton and pick your brains a little bit on what you're building. And I'll definitely be here next week. Thanks for having me.
01:04:57 - Anthony Campolo
Awesome, man. Yeah, we do this every other week, so we'll be back in two weeks, and it's great to have you. The DMs on JavaScript Jam are always open. My own account, AJC Webdev, is always open. It's very cool to have a game dev here because that's actually a perspective we don't get a lot of. So we love talking to developers working in all sorts of stuff. But I think with that, do you want to close it out?
01:05:21 - Ishan Anand
Well, thank you everyone for attending JavaScript Jam. If you got any value from anyone here on the stage, click on their face and follow them. Do subscribe to the newsletter that Anthony puts out. Go to javascriptjam.com and click on the newsletter. You can see the past issues. We only send it out every other week, so we're not going to spam your inbox. And then while you're there, check out some of the YouTube videos and past podcast episodes we've had, the creators of Vite, SolidJS, and a variety of JavaScript luminaries in past video podcasts that are worth checking out as well. And with that, thank you everyone, and we'll see you in two weeks.
01:06:04 - Anthony Campolo
Catch you on the next one.